Via email, I was asked:
How do I set Entourage to be my default mail application?
There are two ways to do this:
If you find that some applications are still launching another mail app after you've done this, it probably means that the application isn't respecting the system settings. In that case, check out the offending application's preferences to see if they have a setting for which mail client to use.
I keep on getting variants of this question in email:
When is the next version of Office coming out?
As we announced at Macworld Expo this year, Office:Mac 2011 is coming out at the end of 2010, in time for your holiday shopping pleasure. I don't have an exact date to share yet, look for that information to come this fall.
The team is hard at work on getting it finished, and I can't wait until we can start sharing more about what's in it. When we do start sharing more, I'll post here (of course!), and you'll also see more about it in Mac Mojo.
I saw a tweet from @Microsoft which tells us that Microsoft tops social media use survey. The NetProspex Social Report lists the top 50 most social corporations in America (top 5: us, eBay, Amazon, Disney, and Google) and the Twitter 20 (top 5: us, Raytheon, Analog Devices, Disney, Kodak).
I'd be remiss if I didn't point out that you can find me on twitter here, and there's also @officeformac too. The former is me in all my unedited glory, which means that you'll see some stuff about Office:Mac and my worklife, but you'll also see me whinging about a DJ explaining who Courtney Love is. The latter is all Office, all the time.
Got this one via email:
what macs do you have?
Here in my office, I've got two Macs. One is a MacBook Pro with a 2.5 GHz Intel Core2Duo processor and 2 GB of RAM. It's pre-unibody, and now that the new MacBook Pros are out with the higher-resolution screens, I'm thinking that it's time to chat with my manager and beg for new hardware. My other Mac is a Mini, with 1.66 GHz Intel Core Duo -- that's right, the original Intel Mac Mini. That's probably in need of an update too. (For completeness, I'll also mention that I've got a mostly-unused HP desktop of unknown provenance that's running Win7.)
I've written up my Mac as a media centre earlier, which is pretty in-depth about how my Mini at home does some awesome stuff. Additionally, I bought a MacBook a couple of months ago, so it's the 2.26GHz Intel Core2Duo with 2 GB of RAM. This is my primary personal machine.
There's a couple of other Macs hanging around the house. My husband has a matching MacBook. We've got an older Mac Mini, the last generation of the PowerPC Minis, sitting in the closet right now. There's also an ancient lampshade iMac that lives in the study, and which is slowly dying. It freezes on occasion, and those occasions are getting more frequent.
I noticed a blog post over at Forbes today: getting hired by Microsoft sounds pretty sweet. He lists our awesome health insurance, membership at local health clubs, and the commuter buses that are available for our Puget Sound employees.
He's right: the benefits are pretty sweet. My health insurance is so far beyond awesome that there isn't a word in the English language that covers it. Here in the Bay, we don't get the cool commuter buses that they have in Puget Sound (after all, there's far fewer of us here), but we all get free CalTrain passes as well as Commuter Checks for other local transit systems, and a shuttle from the CalTrain station to campus.
Although I'm a big fan of our health insurance (I shudder when I think about how much my shoulder surgery in 2007 would have cost otherwise), my favourite benefit is the charitable contribution match. Microsoft matches charitable contributions (up to a max of $12k). Even better, if I donate my time, Microsoft matches that too, at a rate of $17 per hour.
Speaking of Microsoft benefits, my team has a few open positions right now. On the Microsoft Careers site, choose "Mac Office" from the Products list to see what we've got. Since we're running full steam ahead for our release of Office:Mac 2011 at the end of this year, we're not doing a lot of hiring right now, but we do have a handful available.
One of my colleagues did an interview with Tech Night Owl about Office:Mac 2011 and Messenger:Mac. There's lots of good stuff in there -- cross-platform collaboration, using the Office Web Apps on your Mac, how to co-author documents, audio/video suport in Messenger:Mac, and Outlook. You can download this episode of the podcast here.
My colleagues over on the Exchange team are hard at work on the first Service Pack for Exchange 2010. They've shared some details in their blog post Yes Virginia, there is an Exchange Server 2010 SP1, which includes some details about Outlook Web Access (OWA).
There's been plenty of work that's gone into OWA. There's a bunch of UI and performance improvements. SP1 allows you to add Web-Ready Document Viewing of IRM-protected documents as well -- and that's in all supported browsers, so that's ready to use for Mac users on Safari and Firefox.
If you're interested in seeing OWA in SP1, Steve Goodman has posted some screenshots in his blog post A quick look at Outlook Web App improvements coming in Exchange 2010 SP1.
I said in an earlier post that usability testing is not beta testing. The line between beta and usability can get blurred when someone like 37 Signals tells you that you should test in the wild instead of doing a usability study. Here's what they say about it:
Formal usability testing is too stiff. Lab settings don't reflect reality. If you stand over someone's shoulder, you'll get some idea of what's working or not but people generally don't perform well in front of a camera. When someone else is watching, people are especially careful not to make mistakes — yet mistakes are exactly what you're looking for.
This paragraph shows a fundamental misunderstanding of the value of usability testing, plus overstates the value of beta testing for finding user experience issues. They're absolutely right that formal usability testing can be too stiff, and that there's a potential bias built into the system because people are more likely to be hyper-aware of what they're doing. That doesn't mean that it's without value -- after all, if someone is hyper-aware of what they're doing, and they still stumble, then this means that you've definitely got an issue that needs to be addressed.
Relying solely on a beta for finding user experience issues is fraught with danger. By the time you hit beta, you're pretty much locked down. You've made all of the decisions about what's going into your product, not to mention what workflows you're going to support and what scenarios you're going to optimise for . If you wait until beta to gather user feedback, and you learn during your beta that some of your early assumptions were wrong, your options are limited: either go out the door with a product that you now know doesn't meet user needs because you've already committed to it, or you change direction at a very late date (which likely means that you have to delay your release). In either case, you've wasted a lot of time and resources on something that won't be accepted by your intended users.
Much of my research happens long before beta, and one of its goals is to reduce the risk that the software won't meet its goals. My research happens early enough in the cycle that we can go back to the drawing board and fix issues long before they're in code. I iterate on important features to make sure that we've really nailed it -- in this release, this is underscored by the number of hours that my team has spent in the lab with the MacRibbon.
Relying solely on a beta for finding user experience issues means that you're also relying on the user to report issues, and be able to articulate the issues that they're experiencing. When a user experiences an issue in the lab, there is something there observing what is happening. There are plenty of times when the user experiences a problem and doesn't even notice it themselves; it's only later when you ask about it that they reflect back on the experience and recall that they had an issue. In the moment, they were so focused on doing what they wanted to do that they just moved past it as quickly as possible. Skip usability testing, and you miss out on issues like that.
Last year, I conducted a usability test for an important group of features in one of our applications. If you were to simply look at my data, the study went well: the participants were able to do everything that I asked them to do. The process was complex, but they were able to tell me what was happening at every step along the way. On paper, the study went well, and everyone said that they were satisfied with their experience. But as I observed the study, I knew that there was a big problem. While all of the participants said and did all the right things, they weren't comfortable with it. They said one thing, and their body language and tone told me something entirely different. They understood the complex process, but they weren't comfortable with it. We went back to the drawing board, tweaked some things, and then did another usability study with our new design. This time, their words matched their body language. We never would have caught that if we were just relying on self-reported information.
This isn't to say that there aren't user experience issues that can be uncovered during beta. In the usability lab, I get data about usability, but I don't get data about usage -- that is, I learn how users initially react to something and what happens over the course of a couple of hours as they use it, but I don't learn how users react to something over an extended period of time. I monitor our betas to determine what kind of usage issues exist, and my team also conducts plenty of research throughout the software lifecycle to learn more about usage issues.
Standard usability testing is not, and should not be, the only method that you use to capture user feedback. It's one method of many. It has its strengths and weaknesses. Assuming that its weaknesses mean that it's useless is short-sighted and dangerous.
While all of the decisions have probably been made by the time your application is in beta, that doesn't actually mean that they've all been implemented by the time you're in beta. It's beta because there's still work to be done. Work that tends to happen late in the game includes icons, since you don't want to waste resources on putting a lot of polish on icons that might or might not actually make it into the final product, and you don't want to have to keep on going back to your icon designers and saying, "oops, we need another one".