The first day back in the office is always a difficult one. I finally managed something on this holiday that I never quite managed before: I didn't check email, not even once, while I was gone. I'm one of those always-connected people, so just disconnecting my iPhone from Exchange was a big deal. It was probably easier to stay disconnected since I started my holiday in Yosemite: there was no cell access of any sort, let alone a data connection, so I couldn't even sneak in and look at it. That established the precedent, and I didn't check email for the rest of the trip.
Getting back into the office today, I had 99 unread emails in my main inbox. I use server-side rules to filter my incoming mail into various folders, so the only stuff that ends up in my main inbox is the stuff that's addressed directly to me. So on one hand, I'm happy that my mail filters did a lot of work for me and I have a great idea of what actually needs my attention. On the other hand: that's 99 mails that actually need me to do something with them. Eeeep!
Today is all about catching up. If I'm really lucky, I'll even finish my presentation for my talk at the San José State University student chapter of the Human Factors and Ergonomics Society on Wednesday night.
Ever since our announcement last week that we're bringing the Ribbon to the Mac, I've been following various online forums to see what the response has been. I think I could characterise it in three groups:
For those of you who aren't aware, Office 2007 for Windows brought a new UI to many applications in the suite. It's called the Fluent interface, and the single most distinguishing characteristic of it is the Ribbon. Office 2007 did away with all of their menus, and replace them with a band across the top of the applications. The goal was to improve discoverability. Office 2007 has a lot of features available, sometimes buried deep in the menus and contextual menus, and the team often received requests for features that had been in the suite for years.
In Office:Mac 2008, we tried a different approach: the Elements Gallery. Our goal was also to improve discoverability, but along very specific lines: we wanted to make it easier for you to find the features needed to create great-looking documents. I wrote a lot about the Elements Gallery at the time; evolution at work is a good overview of what we wanted to accomplish and how we set about doing it, as well as why our approach differed from that of the Windows Office team.
Office 2010 for Windows has extended the Ribbon. Every Windows Office application has the Ribbon now (including Outlook, which had previously had the Ribbon in certain views but not all of them). The applications that already had the Ribbon made some tweaks to better improve the experience, as well as support new features.
As we began our work on Office:Mac 2011, we had to make decisions about what the next generation of the Elements Gallery should look like. We made some great strides forward in improving discoverability, but there were still some improvements to be made. As we looked at our colleagues on the Windows Office team and considered what they had learned through their Ribbon work, we decided that we could do the Ribbon in a Mac way that works for our users.
Our single most important decision for the MacRibbon is that we're still going to be a good Mac citizen. Our menus, not to mention the standard toolbar, stay. We knew that one concern that our users have is the availability of vertical screen real estate. As such, we quickly made the decision that our MacRibbon should be collapsible. If you're using the MacRibbon, then you've got easy access to our features; if you're not, then you can collapse it to get it out of your way. If you're feeling particularly minimalistic, you can collapse the standard toolbar too, leaving you with every pixel on your screen below the menu bar to dedicate to your document.
One of the questions that we get asked about the MacRibbon is why it takes up vertical screen real estate at all. It's about how people work. If you're on a widescreen monitor, windows off to the side have the "out of sight, out of mind" problem. You're so focused on your content that's right in front of you that you don't look the few inches over to your right to see what's happening in the Toolbox. Moving the same features out of the Formatting Palette or Toolbox and into the Ribbon has drastically increased their discoverability, and makes it easier for you to get your work done.
My team has done hundreds of hours of usability studies that focus on the MacRibbon across the suite, an effort spearheaded by one of my research colleagues. At each step of the way, we've made changes to the MacRibbon based on our research findings, and conducted additional research to determine whether our new design met its goals. We've had really positive feedback about this. I just wrapped up an Outlook:Mac study where one participant told me that he felt like he was getting the best of both worlds: the goodness of Outlook done in a way that fits right in to the rest of his Mac experience.
Our friends at Macworld have posted some screenshots of Word 2011 in their article Microsoft announces Office for Mac 2011. Take a look at those to start to get a feeling for what you'll see in Office 2011. We'll be sharing more information, including more screenshots, as we get closer to the launch of Office 2011. In the interim, feel free to leave comments with any questions that you might have.
I know, I know, Macworld Expo was last week, and I should have written this up earlier. I had every intent of taking a break on Thursday after my shift in the booth and my talk, but it just didn't end up happening that way. Forgive me: the show was awesome, and I'm only now recovered enough to be able to write complete sentences.
Now, on to the top Office:Mac questions that I fielded this week at Macworld Expo:
When is the next version of Office coming out? It's coming late this year, in time for your holiday shopping pleasure.
And what's it called? It's named Office for Mac 2011.
Office 2011? But I thought you said it's coming out this year ... Think of our naming kinda like how car models get named. If it comes out in the first half of the year, it gets labelled with that year; if it comes out in the second half of the year, then it gets labelled with the next year.
What's in it? We haven't announced all of the features in Office:Mac 2011 yet, but here's some of what we are sharing ...
Outlook on my Mac? Yes. We announced last year that we're bringing Outlook to your Mac, and we've added some details at Macworld Expo. Here's everything we're sharing so far about Outlook:
When will you tell us more about Office 2011? Look for us to post more to our blog, Mac Mojo, in the upcoming months as we get closer to launch.
There's more details available in our press release, and there's a screenshot of Word 2011 in a blog post on Mac Mojo. Got more questions? Leave 'em in the comments!
John Gruber of Daring Fireball wrote about the Macworld Expo prelude yesterday, and how the absence of Apple will impact it. As he rightfully points out, there's a lot of content at the show that doesn't come from Apple themselves. There's lots of other companies there that have things to share, and what they're showing is often at least as interesting as what Apple is doing.
I've got to be honest and say that this part of his post annoyed me:
To me, though, the reason to walk the show floor has always been about the small companies — often the really small ones. The ones where the employees manning the booth are the engineers and designers who made the product they're promoting.
This implies that it's only the indies who have their own people working the show floor. That's just not true. This is my fifth Macworld Expo as a MacBU employee, and each year I've spent at least a couple of days working in the booth and answering questions. Every year, our product team staffs that booth. We get some help from our MVPs because they've got experience that we don't (I've certainly never written a 300+ page book in Word like John McGhie has, and I don't have the kind of Exchange experience that Paul Robichaux does), and we hire a couple of temps to help direct people to the right member of the product team. The vast majority of the people working in our booth are us, the product team. We learn a lot about our users by working in the booth, which is why I've said that Macworld Expo rocks for software developers. We care deeply about the platform, and we want to do the right thing, and yes: we go to Macworld and let you talk to the people who are the engineers and designers who made the product they're promoting.
Go visit the indies too: I do this every year, and it's certainly one of my favourite parts of the show to see what the other Mac developers are up to. But don't skip us because you think we've just hired glossy booth babes to try to convince you to buy our apps. Bring your questions, bring your requests, and talk to the people who are going to go back to their offices in Mountain View and Redmond to deliver the products that you use every day.
Update Tuesday is here, and it brings a security update for Office:Mac 2004. Full details are in the knowledge base article for the update, and you can download it.
I haven't posted my Macworld schedule yet!
Thursday, noon-3pm: booth duty. Tell me what you like about our apps, tell me what you don't like, get some help with a problem, or anything else that might come to mind. We're on the main aisle near the main stage, so we won't be hard to find at all.
Thursday, 4:30-6pm: My hotly-anticipated (if only by me) talk about administrating Macs in Exchange 2007 or 2003. Bill Smith, one of our awesome Entourage MVPs, is co-headlining.
Thursday night: super-sekrit event.
Thursday night, later: Cirque du Mac, the party put on by the folks at The Mac Observer.
Friday, 2-6pm: Back in the booth!
Friday night: dinner with the MVPs.
Friday night, later: Macworld Blast.
Want to help us make Mactopia better? We're conducting in-person interviews at Macworld 2010. In exchange for an hour of your time at the show, you'll get $100. If you're interested in participating, please fill out this questionnaire.
Speaking of participating, I still need corporate Messenger:Mac users in the Seattle area who would like to see what the next version of Messenger might be like. For more details, check out my earlier blog post. Please send this to any friends you have who use the corporate version of Messenger and are in the Seattle area!
Haven't registered for Macworld 2010 yet? Use priority code TWEETMW to get either a $15 Expo pass or 15% off any conference package.
If you are coming to Macworld, don't forget about my talk about administering Macs in Exchange on Thursday afternoon. I'll also be working in the Microsoft booth a couple of days; I'll post information about that soon. Swing by and say hi!
My colleagues on the Exchange 2010 team have announced new Exchange 2010 webcasts and videos. There's several of them which will be of interest to Exchange admins who have Mac users, so check 'em out.
I noticed that an old post of mine, the "Word 5.1 Plus Ten" phenomenon, was referenced in Lukas Mathis's manifesto about removing features.
He starts off the article by quoting Kathy Sierra saying that her books have fewer topics than competing books but still outsell them. His solution for how to choose what features to remove is to gather usage data, and to remove features based on that data. Apparently he didn't read all of that post from Kathy, because she says later:
Give users what they actually want, not what they say they want.
Using usage data to decide which features to cut is fundamentally flawed. Usage data doesn't tell you why a feature isn't used. You're listening to people tell you what they do, but you're not listening to them tell you why they're doing it. Cutting features based on usage is giving users what you think they want based on what you think they're telling you. There are plenty of reasons that a feature might not get used, and removing the feature is not the only solution to the low-usage problem. There are many reasons that features might not get used, including the following:
In the last case, I agree: cut the feature. But in the first four cases, perhaps you need a scalpel instead of a sledgehammer.
Usage data is directional. It doesn't tell you what action to take, it tells you that there might be an action to take. If you assume that the feature isn't useful based on usage data, your decision-making process is fundamentally flawed, and you're not actually listening to your users.
If your usage numbers are low, you need to figure out why they're low. If your feature is a great one but you've hidden it in the interface, or if it would fit better with users' workflow elsewhere, then you have one problem to solve. If your feature doesn't quite do what users think it should do, then you have another problem to solve. If your feature is too hard to figure out, then you have a different problem to solve. One solution to each of these might be to remove the feature, but it might also be to improve the feature such that it meets the needs of your users.
If your feature is useful but in limited circumstances, then you either need to make those circumstances less limited or accept that this feature is narrow in scope. For example, if I were to go look at Entourage usage data today, I bet you that the usage of the Out of Office feature would be relatively low. Is that a problem? Not at all. I know that Out of Office is needed only infrequently. After all, I get three weeks of vacation per year, and I rarely manage to take more than one (this is, of course, my fault), so I don't use the Out of Office feature that often. Does that mean we should remove it? Of course not. It's immensely useful when it's needed. There might be some improvements to be made to it -- for example, maybe "out of office" isn't the best name for it, maybe it should be "vacation" or something else. That might improve its usage numbers, but it's certainly not going to make it one of the top-used features in the application. It's still going to be a feature that's limited in scope, and that's perfectly okay.
I thought Mathis's piece was especially telling when he brought up the iMovie example. iMovie '09 removed features that had been available in iMovie '08 and earlier. Apple continued to make iMovie '08 available to users, which Mathis says "allowed Apple to add features users needed" to iMovie '09. I'm not sure that I see the point of taking the engineering expense of removing features (after all, removing features involves both development and test work) only to again incur the engineering expense of adding them back to the application. There are times it has to happen (to wit, our decision to remove VBA from Office 2008 and then bring it back in the next version of Office), but this is an expensive decision that has a lot of painful ramifications both for you and for your users. It's certainly not something to do based on a flawed decision-making process.
Office:Mac does collect usage data. I wrote a post about it for Mac Mojo called we are watching you soon after the release of Office:Mac 2008. Usage data is one input into our decision-making process, but it's only one of them. Usage data tells us where we might want to wield our scalpels, but it doesn't tell us to amputate the whole leg.