Windows Phone 7 UX, Part 1: Usability

Introduction

This is the first in what will hopefully be a series of posts discussing the user experience (UX) of the new Windows 7 Phone platform.  Windows Phone 7, the successor to Windows Mobile, is the all-new mobile platform that Microsoft unveiled at this year’s Mobile Wireless Congress.  Well, it’s mostly new.  The basic UX has actually been around for a while now in Microsoft’s Zune media player.  Oddly, to me at least, is that most of the people I’ve talked to seem to really like this UX.  They call it “highly innovative” and “refreshingly different”.  Well, it’s different, that’s for sure.  Innovative?  Well, it was pretty innovative when it was first unveiled on the Zune, but I’m not sure simply carrying the same concepts over to a different platform qualifies as innovation.  Nevertheless, people seem to like it.  Maybe that’s because they’ve used a Zune before, and they liked the Zune’s UX.  Well, great—they should.  I think the Zune UX is great.  For a Zune.  My problem is this: a smart phone is not a Zune.  It seems obvious to me that smart phones and media players are two completely different beasts, and yet, somehow, this idea seems to have eluded the Windows Phone team.  They have taken UX paradigms that were designed for a media player and carried them over—largely unchanged—to their new smart phone platform with the expectation that they would be just as appropriate in their new home.  In this series, I will explore why I believe this expectation to be, well, wrong.  I’ll start by highlighting some of the usability issues that I see.

Motivation

As a Microsoft platform developer, I would very much like to see the next Microsoft mobile platform succeed.  As a highly opinionated person, I have many thoughts about what is wrong with the Windows 7 UX.  As someone with more background in human-computer interaction than your average developer, I’m slightly more qualified than a doorstop to offer constructive criticism about UX design and usability issues, and perhaps even to offer up some suggestions for improvement.  As someone who likes to feel useful (and hates to be bored), I figure I should put the aforementioned qualities to use and do some blogging on the subject.

That said, please bear the following in mind: I am not a UX expert.  I am not a designer.  I am not a Microsoft insider, nor do I have access to any information about changes to the WP7 UX that are already in the works.  WP7 has not been released, and it’s entirely possible that some of the issues I describe here have already been fixed in internal builds.  You have absolutely no reason to believe that I know what I’m talking about.  So, if you choose to read on, and you find yourself agreeing with some of my points, then great.  If you read my post and decide that I’m a clueless idiot instead, then that’s great too.  At least you’ll have been exposed to an opposing point of view.

OK, this is your last chance to bail.  Ready?  Here we go.  And remember, everything form here on out is my opinion, backed only by five years of experience in UX development and a few HCI classes in college.

Smart Phones Are Not Media Players

If I could distill all of all of WP7’s usability issues down to one fundamental design error, it would be the assumption that a UX designed for a media player is appropriate for a smart phone.  Why?  Because they are completely different types of devices.  They have different target audiences, and those audiences have very different sets of expectations.  And when I say “audience”, I am of course referring to myself, as I am not qualified to speak on behalf of anyone else.

So what do I expect from a media player?  Well, I expect it to play media.  Music and videos, that kind of stuff.  Maybe it has a clock so I can tell how many hours I’ve wasted watching American Psycho over and over again.  The Zune UX exposes these capabilities to me in a sensible and elegant way.  The list-based menus are simple and easy to navigate.  The media hubs let me quickly browse and select the media that I want to play.  The large fonts don’t strain my eyes, despite the small screen, and the white-on-black color scheme ensures that I can read the screen even in direct sunlight.  Hell, the thing even plays games!  Talk about a sweet bonus.  And that’s exactly what it is—a bonus.  Let’s face it: most people aren’t going to buy the Zune as a gaming device.  They’re going to buy it as a media player, though they may choose it over another media player because it plays games.  If the device’s primary purpose is to play media, then we don’t need an overly complicated UX.  We need menus, lists, or tiles to browse our media.  We need some playback controls, and for music we expect some album art and a few details about the track that’s currently playing.  For video, we just need full-screen playback.  We don’t really need any additional UX facilities for games, as most games provide their own UX, and the XNA framework gives them everything else they need.  So that’s it—not a whole lot, right?  And it can all be navigated easily with an iPod-style rotary dial.  Win!

So what about smart phones?  They’re media players too, or at least most of them are.  But they’re also a lot of other things.  They’re web browsers and notepads.  They’re organizers and news readers.  They’re voice recorders, cameras, and camcorders.  They add, subtract, and convert units for us.  They’re our personal connection to the world of social networking.  We carry them with us everywhere, and we use them to look up anything or anyone, whether we’re at home, riding the subway, or standing in line for a movie.  We use them to send mail, trade stocks, and cheat at trivia.  Hell, they do so much for us that they almost sound like computers.  Actually, that’s exactly what they sound like: itty-bitty computers.  True, we don’t use them to write code, design skyscrapers, or compose symphonies (at least most of us don’t), but they do a lot of the other things computers do for us, and they do it whilst fitting snugly into our pockets.  And they make phone calls!  No, really!  That’s pretty freakin’ amazing when you stop to think about it, isn’t it?

Alright, we get it—a smart phones isn’t a Zune.  So what?  Well, with different uses (and heftier price tags) come a different set of expectations.  For one, I expect the same kind of rich user experience that I get from my PC.  What exactly do I mean by a “rich” UX?  Let me elaborate.

The Problem of UX Fidelity

Let’s start by laying down a few core requirements for a smart phone UX:

• A smart phone can only accept primary input via touch manipulation.
• It cannot require a stylus, “thumbpad”-style controls, or any other input device.
• Any auxiliary input must come from internal sensors that are either autonomous or manipulated by altering the device’s orientation.

Satisfying this requirement is probably the single hardest part of smart phone UX development.  Happily, all the big players have nailed it.  The iPhone, Android, and WP7 all sport first-class touch-based input, but with varying tradeoffs.  Each platform had to make certain sacrifices in order to accept input from our big ol' clumsy fingers.  This is where things start to fall apart for WP7.  Whereas Apple managed to strike a near-perfect balance between UX fidelity and ease of interaction, WP7 simply sacrificed too much (I cannot speak to Android).  WP7’s core UX paradigms, borrowed from the smaller and less capable Zune, were simply not designed to provide the type of high-fidelity experience that I expect from a smart phone.  There’s no “one thing” wrong with it, but there are plenty of little things.  Let’s start with the most obvious…

What’s Up With the Huge Fonts?

 If your first reaction to the WP7 UX was, “WTF is up with the huge text?”, then you are not alone.  If you haven’t yet seen WP7 in action, please refer to the screenshot to the right.  What’s the first thing you notice?  For me, it’s the ridiculously oversized header.  The next thing I notice is that the header appears to run off the side of the screen.  In fact, this is exactly what is happening, though it is less obvious in this screen than in others.  Can you tell what the header says just by looking at it?  “Music [something]”.  Well, great, what’s the “something”?  Sorry, but I’m not telling you.  I’m going to make you scroll for it.  And with that, I introduce Strobel’s 1st Commandment of UX Design:

Thou shalt not require unnecessary scrolling.

Oh yeah, they blew that one big time, and in a whole lot of places.  If you want to read the entire header, you have to scroll for it.  But why?  Why must we scroll?  There’s plenty of padding around the menu already, so it’s not because they ran out of space.  They’re trying to look slick, and trying to look slick at the expense of usability equals big fail.  In this screen, the header’s font size could have easily been bumped down such that the entire header fits.  They could have even bumped it down less and displayed it on two lines, and it still would have fit.  Better still, they could drop the header altogether and replace it with a subtle backdrop with some music notes and a video reel etched into it—the kind of thing you’d see in Windows Media Center.  That would certainly add some life to this otherwise sterile screen.

Menu Screens?  Really?

Something which irks me about WP7, which most people probably wouldn’t even think about, is that it introduces the concept of menu screens.  Take the Zune screen above.  They’ve dedicated an entire screen to a menu with six options, and in so doing, they have introduced another navigation point.  Upon entering the Zune application, I can’t immediately do anything useful—I have to go through this menu first.  At this point, you may be thinking, “Big frakkin’ deal.  Suck it up, you pansy!”  Admittedly, it’s not exactly a major issue.  Like I said before, there aren’t a lot of major issues with the WP7 UX, but there are many minor issues, and when you add them all up, WP7 starts to feel pretty clumsy.  The more issues we can eliminate, the closer we get to outshining the competition—and let’s face it, it takes some serious effort to outshine Apple in UX design.

Let’s see if we can get rid of this extra screen, shall we?  We begin by assessing why the screen exists in the first place.  I would surmise that this screen is actually an artifact.  It, or something close to it, existed on the Zune.  Given that the WP7 media application is based on the Zune, it’s likely that the developers’ first instincts were to model their UX after the Zune’s.  And that would be a mistake.  It’s actually one of the most common mistakes people make when porting anything from one platform to another, be it code or a UI.  There are a lot of usability issues to consider when developing a user interface, and it’s very easy to overlook this fact when you’re using an existing application as a model, as opposed to starting from scratch.  This menu made perfect sense on the Zune.  It also makes sense for Windows Media Center, which features a similar menu screen.  Why does it make sense?  Because, with the Zune, the user cannot select arbitrary UI elements on the screen.  She is limited to two simple commands: she can move the selection to the next element or the previous element.  Even though she can scroll quickly through a menu using the rotary dial, she is really just performing a rapid sequence of “down” or “up” commands.  The same goes for Windows Media Center, in which menus must be operable via the up/down/right/left buttons on a remote control.

Now, consider a smart phone.  The user can tap UI elements anywhere on the screen at any time.  Even on this screen, the user can simply tap any of the menu items without scrolling through the list.  So why have the list?  Why waste an entire screen on a menu with verbose text labels?  Why not simply replace the list-based menus with a row of icons along the bottom or left edge of the screen?  Then, when the application is loaded, it could jump straight to the last screen the user had open: music, videos, etc.  There are plenty of other ways this application could be redesigned—my suggestion is only one example.  However, a row of icons does provide the additional advantage of reducing the number of localized strings.  Moreover, it avoids the possibility that menu items will extend beyond the edge of the screen when translated into more verbose languages like German.

Too Many Screens, and They’re Poorly Organized

Menu screens aren’t the only demons hampering navigation in WP7.  There are other cases where the user will be entering data on a screen, will be dispatched to a different screen to make a selection, and then be sent back.  This is a common enough workflow in a UX world where we have only one “window”, and plenty of cases where it’s unavoidable.  But there are some cases where it’s unnecessary.  For instance, the screen for creating a new appointment in the Calendar application includes fields for time and date.  When I click either of these fields, I am sent to another screen with a giant date- or time-picker.  I make my selection and am sent back.  Sounds pretty sensible, right?  Sure, it’s sensible; but it’s not ideal.  Let’s take a look at the screen layouts:

Ignoring the “larger” issue of the extra screen (pun intended), there are some easily-corrected usability issues with the current implementation.  The more time I spend in the date-picker screen, the more likely I am to forget which field I clicked on to get there—or, more specifically, the position of that field on the screen.  When I click on the date field, its background flashes briefly to confirm which field triggered the transfer to another screen.  Upon returning, there is nothing to visually indicate to me which field had sent me to the date-picker, and I’m forced to reevaluate the screen to figure out where I left off.  True, this is a minor inconvenience, but it could be easily eliminated by simply flashing the background of the date field again when I return.  In fact, this is the exact behavior of the iPhone.  The usability improvement is greater than one might expect, and it costs relatively little to implement.

If thou insisteth upon yanking me out of a screen, thou shalt remindeth me from whence I came.

There’s plenty of other problems with this workflow, though.  Let’s say I want to add an event to my calendar that spans the last week of August.  It’s currently April.  I click the “Start” date field and I get a standard “Month-Day-Year” date-picker.  Well, that’s no good; what I really need is a date-picker with a month calendar view.  Unfortunately, I don’t have the option of using a calendar view to select the start date.  Instead, I either have to do the math in my head to figure out what the correct dates are, or I have to cancel my new event, go back to the main calendar screen, switch to the month view, skip ahead to August, and check what the dates are for the last week.  If the date selection screen gave me the option of using a month calendar view instead, or just a month calendar by default, the process would be a lot easier.

EDIT: Somehow I completely overlooked the “day of the week” labels beneath the numbers in the “day” spinner.  Obviously, this reduces the pain of mentally computing the correct dates, though there are still reasons I might want a month calendar view.

OK, so I’ve figured out and selected the start date, and my phone rings.  I answer, talk for a few minutes, and hang up.  Or I’m distracted by any number of other things that are bound to happen in a busy office.  I pick up where I left off by clicking “Duration”.  From here I’m presented with a list of potential event durations, one of which allows me to specify a custom duration.  Here’s another screen I think we could eliminate.  I don’t know about you, but I’d say that at least 20-25% of the time, the predefined durations here aren’t going to cut it—I need to specify and end time (and/or date).  So I click “Custom”, and it sends me back to where I was.  Uh, okay.  Again, there’s nothing to remind me which field I’d clicked on, or that the layout has changed.  After re-reading the screen, I notice that the “Duration” field has been replaced with and “End” date field.  It turns out there’s also an “End” time field below it, though there’s nothing on the screen to indicate that to me.  More on this later.  I click the “End” date field and I get another date-picker:

Well, by now I’ve completely forgotten what my start date was.  Wouldn’t it be nice if I could see both the “Start” and “End” dates at the same time?  I get that functionality on my iPhone, and with my short attention span, I’m glad to have it:

See how much nicer this is?  How convenient it is?  Look what else they’ve done—they’ve merged the “Date” and “Time” selection into a single control.  And notice what it doesn’t have: a totally unnecessary screen for selecting a duration.  There’s still no calendar view, but what the iPhone does have is still better than what WP7 has.  The only thing it’s lacking is the ability to change the year without scrolling through all the months in between.  I tend to find this somewhat less objectionable, as I’m unlikely to be adding events that last more than a week or two, but it’s still a problem.  An optional month calendar view would eliminate this issue (hint, hint, Steve).

Panoramas: Slick, but in Need of Refinement

One of the “really cool” WP7 features that Microsoft has been touting is the “Panorama” control.  If you’ve seen any WP7 demos, you’ve almost certainly seen this in action.  The idea is that you have several screens arranged side-by-side that you can scroll through through continuously (when you scroll past the last screen, you scroll back into the first screen).  There are multiple layers to the panorama control, some of them panning at different “speeds”, which produces a really cool parallax effect. At first, I had a lot of problems with this design.  My biggest concern was that since the screens are in a fixed order, a user would often end up having to scroll through multiple screens to get to the one he or she wants.  Direct navigation, by contrast, would send the user directly to the desired screen with the touch of a button.  It turns out that this isn’t really a problem after all, and my apologies for being unduly harsh on the concept in some of my Twitter conversations.  Microsoft’s UX guidelines specifically state that a panorama should contain no more than four screens (and I trust Microsoft to adhere to this).  Since the panning behavior is circular, that means you will never be more than two swipes away from the screen you want.  Not so bad after all.

That said, there are a still a couple opportunities for refinement.  First, the headers.  Again, at 140pt, they’re way too big (though the effective size is equivalent to half that on a standard PC).  What’s worse, they scroll at a slower rate than the primary content.  Consequently, the user may have to scroll through *all* the screens in order to read the entire header.  I would suggest instead making the header fit on a single screen, and have it stay fixed whilst the other layers scroll.

I’ve also observed that the screen snapping seems a bit aggressive when panning between screens.  Granted, I have only been able to test the panorama out on the software emulator, using a mouse for input instead of multi-touch gestures, so the behavior on an actual touch device may be better.  On the emulator at least, the screens appear to begin snapping into place as soon as I cross the cross the midpoint between two screens.  Aside from detracting from the coolness of the parallax effect, I find the behavior generally awkward.   I think the awkwardness is exacerbated by the fact that some  views span multiple screens (note the album thumbnail gallery).  There is no snapping while panning through these wider views, but as soon as I reach the end, the snapping behavior kicks in again.  As a result, I find myself often panning a little too fast through the thumbnail gallery, and I accidentally end up snapping into the view that follows it.

I believe the panorama’s behavior could be refined to provide a more fluid experience.  What if, instead of snapping screens when the midpoint is crossed, the panorama continued “gliding”, decelerating as it goes.  Once the “speed” drops below a certain threshold, it then begins snapping to the appropriate screen—slowly drifting towards that screen, but accelerating as it goes to provide the “snapping” feedback.  The accelerated snapping affords the user a brief opportunity to intervene in the event that he or she accidentally scrolled too far—a soft nudge in the other direction snaps the desired screen.

One last oddity that I’ve noticed is that some applications appear to be using a panorama control where none is needed.  Remember that “Zune” menu we looked at earlier?  Well, look what happens when I scroll to see the rest of the header (screenshot to the right).  At first glance, it looks like there’s another page in the panorama.  At second glance, I think, “Wait a minute, that’s the same screen.”  At least it looks like the same screen.  Rather odd that I would be able to scroll from one screen back into itself.  Maybe I trigged some sort of “mode change”?  Nope, glancing at it a third time, I’m now confident that there’s only one screen here.  “Pretty strange behavior,” I think to myself.  This is unexpected behavior, and unexpected behavior is unintuitive behavior.  I think we can all agree that unintuitive behavior is bad.  As far as I can tell, the only reason for this behavior is the fact that the header is wide enough to fill two screens.  Since there is only one screen, it gets “cloned” to fill the void when the user scrolls to read the header.  Not only is this behavior strange and unexpected, but it exists only to accommodate another oddity: the ridiculously large header that fills two screens.  You’ve just introduced one usability problem for the sole purpose of supporting another.  Doesn’t make a lot of sense when you think about it that way, does it?

Zune Styling: The Weak Link

Possibly the most exciting aspect of WP7 development is that WP7 applications are built with Silverlight.  Hurray!  Finally, we can create rich, high-fidelity user experiences on mobile devices!  So what do they do?  They adopt UX styling that’s limited to simple white-on-black text, hard borders, and stencil-style icons.  Wait, what?  Are you serious?  Unfortunately, yes.

Suspend your disbelief for a moment and pretend that predominantly text-based monochromatic screens aren’t objectionable in and of themselves.  I’ll be writing a whole 'other blog post on the limitations of this design, so we’re going to simply gloss over that for now.  Simple, monochromatic color schemes are the new trend.  They’re in.  Booyah.  Unfortunately, even if this were true, they tend to encourage bad design decisions.  Let’s dig in and have a look, shall we?

Lack of Element Differentiation

The overly simplistic “Zune” styling leads to one issue that, in my opinion, trumps all others: lack of differentiation between UI elements.  What do I mean by this?  Two things, really:

1. Many UI elements look virtually identical but have different purposes and behaviors, with few or no visual hints as to what those purposes and behaviors are.
2. There are few ways (other than proximity and spacing) to visually differentiate between logical groups of controls.

The first issue is arguably the worse of the two.  Aside from the occasional text box or rectangular button, almost every UI element in WP7 is presented as a textual label.  Labels, which do nothing, look strikingly similar to menu items, list items, and link buttons, all of which do something, though not necessarily in the same way.  Some might take you  to a new screen, others might perform an operation locally.  Some may change the context of the current screen, clearing information I’ve already entered.  There aren’t a whole lot of visual cues to indicate what’s going to happen, if anything, when you invoke a control.  Each time, the user is left wondering, “Can I click this?  Does it do anything?  Is it going to send me to another screen, and if so, can I get back to where I am now without losing any of my work or digging through another set of screens?”  The design ends up placing an undue burden on the user to figure out an application’s functionality through trial and error, and that’s antithetical to the concept of “user-friendliness”.

Take the “New Event” calendar screen that we discussed earlier.  I didn’t know for certain what would happen when I clicked the “Start” date field, but I suspected a date picker would pop up where the on-screen keyboard usually appears.  I wouldn’t have expected to be sent to a new screen.  As it happens, I was wrong, and understandably so, as there were no visual hints to suggest what would happen.  Contrast that to the iPhone interface, where the right-facing chevron on the Start/End field group tells me that a touch will send me off to another screen.  Moreover, new screen slides in from the right, and when I finish making my selection, the old screen slides back in from the left, reaffirming that I have stepped back into the workflow right where I left off.  I have noticed no such transitions in WP7, though my laptop does not support hardware GPU acceleration in the emulator, so they may simply be disabled.

The problem of UI element differentiation (or lack thereof) is compounded in screens containing composite controls.  Take the screenshot to the right, for instance.  This screenshot comes from the “Agenda” view of the calendar application.  I currently have two events scheduled for today.  When I look at this view, I see what appear to be two composite controls, each consisting of the time at which the event occurs, the description of the event, and its duration.  I base this determination off the fact that I see two clusters, each containing three elements positioned closely together.  The two clusters are separated by a generous margin.  I decide I want to reschedule “Stuff” for tomorrow.  What is the most natural action that I’m likely to perform?  Statistically, I’m most likely to click on the most dominant element the cluster: the “2:00 PM” label.  This is the dominant element because of its large size relative to the others, as well as its greater color intensity.  But what happens when I click it?  Nothing.  Why?  Because the time label isn’t part of the composite control for the “Stuff” event.  It’s actually a header for all of the events that occur at 2:00 PM.  Logically, it makes sense: you could have overlapping events starting at the same time, and it seems redundant (and wasteful) to display multiple time labels.  It’s logical, but it’s not intuitive because the design is flawed.  The spacing between the time and description labels is the same as that which separates the description and duration labels, and there is generous spacing all around these elements.  If I want to view or edit the details of an event, I have to click on either of the (smaller) description or duration labels.  To me, this is not the behavior I expect based on the design of the screen.  It’s very unclear that the time labels are actually group headers, and it might not even occur to the average user unless he or she actually has multiple events scheduled at the same time.  Since that’s not a common occurrence, some users will be left wondering “What moron designed this screen, and why can’t I click on the big label thingy?"  Had the designers simply placed a thin horizontal line beneath each time label, it I would have initially thought, “oh, that’s a header.”  Alternatively, they could bump up the size of the description label, rotate the time label 90 degrees, shrink it down, and stick it in the left-hand gutter (with adequate padding between it and the event labels).  Either design would be far more intuitive to me.

Just one last thing, and then we’re done with this section.  Take a good look at the form to the right.  I recommend clicking on it to view the full-sized image.  How many fields are there?  If you answered “six” then you would be wrong; there are nine fields in this form.  (“I don’t know,” would have also been an acceptable answer.)  I could hardly blame anyone for thinking there were only six fields, however, as there is absolutely nothing to indicate that there are three more fields further down, hidden from view.  Nothing.  Nada.  In fact, there are “Done” and “Cancel” buttons at the bottom of the screen.  Such buttons usually mark the end of a form, giving the user reason to believe that there aren’t more fields.  As it happens, those buttons are actually static; they would remain in the same position while the user scrolls the main form area.  Unfortunately, if you’d never used this application before, you wouldn’t know that; there is nothing to suggest that those buttons aren’t part of the main form—no subtly different background, no horizontal separator.  Nothing.  Unless the user just happens to think, “Hmm, I should try scrolling down to see if there are any hidden fields down there,” they’re likely to just click “Done” and be on their way.  Contrast that to the iPhone screen above, in which fields are presented in “stacks”, with related fields being grouped together.  The stacks, with white backgrounds, contrast the background of the form, and the top and bottom elements in a stack have rounded corners.  These subtle design decisions help make sure the user knows whether there are more elements off-screen.  The “Done” and “Cancel” buttons are static, as in the WP7 screen, but they are visually differentiated from the scrollable form by being placed in a blue header bar.  They’re also located at the top of the screen to avoid unintentionally suggesting to the user that they mark the end of the form.

Let’s recap:  In the current design, off-screen fields are not easily discoverable.  In some cases, you’d have to work pretty hard to make them less undiscoverable.  Microsoft’s fixation with transparent controls atop an uninterrupted black background indirectly encourages designers to create screens where the relationships between UI elements are ambiguous.  There are few visual indicators to group related controls together, and even fewer indicators setting unrelated controls apart.  Individual controls suffer from a lack of differentiation, as well as visual hints as to their behavior.

Other Minor Gripes

Application Bar Menus

WP7 provides developers with the option to display an “application bar” at the bottom of the screen.  This bar may contain up to a few toolbar-style buttons, as well as a button which opens a menu.  I have plenty of little gripes about the application bar that I’ll cover in my next post.  For now, I have just one: when you open the menu, it opens below the application bar, pushing the bar further up.  I discovered this when adding a new contact to my contact list.  I brought up the menu, and the only option was “Delete”—nothing useful to me, so I went to close it.  As it happens, I was only half paying attention, and I just clicked where the menu button had been previously.  Since the application bar was pushed upwards, I ended up clicking on the “Delete” menu item instead.  I simply backed out of the confirmation dialog with no damage done, but the menu implementation breaks one of my cardinal rules of UX design:

Displacing an existing control to accommodate another control is bad; avoid doing this when possible.  Displacing a control temporarily to accommodate a transient control is even worse.  Displacing a control to accommodate a transient control is worse still when the former is used to dismiss the latter.  It is better for a transient control to temporarily eclipse a control than displace it, provided that the latter control is inoperable while the former is visible anyway.

Bit of a mouthful, isn’t it?  How could the implementation be changed such that it respects the restrictions above?  Simple: have the menu slide up from above the application bar.  This change avoids displacing any controls, so those restrictions are satisfied.  The menu would be temporarily eclipsing the contents of the screen, but this is acceptable because the user won’t be interacting with that screen while the menu is open; his or her next action will be to either dismiss the menu outright or select one of the menu items (thereby dismissing the menu).

The “Back” and “Search” Buttons

Oh boy.  Apparently somebody at Microsoft didn’t get the memo that hardware buttons are bad.  Why are they bad?  Because they’re static and are therefore incapable of displaying any contextual hints about their functionality.  I make an exception for the “Home” button—one typically wants a quick and reliable way to bail out of a misbehaving application, and the “Home” button fits the bill.  The “Home” button has another important characteristic as well: it always does something, and as far as I can tell, it also always does the same thing.  This is not true for the “Back” or “Search” buttons.

Depending on which application you’re in, the “Search” button may do different things.  Actually, it may do different things depending on which screen you’re in, even within the same application.  If I’m in my contacts list, it brings up a search box that lets me narrow down the list by typing in part of a person’s name.  Cool.  Let’s say I then click on a contact’s name, thus bringing up their profile.  If I hit the “Search” button now, I get yanked out of my application and dropped into a Bing search screen.  Not cool.  These are two fundamentally different behaviors, both triggered by pressing the exact same button, and there is absolutely nothing to tell me which behavior I should expect.  Fail.

And then there’s the “Back” button.  To be honest, I’m not quite sure what this one is supposed to do.  Well, I know what I expect a “Back” button to do; countless hours spent in web browsers have taught me one thing that when I click a “Back” button, it takes me back to the last page I visited.  Windows Explorer works the same way, as do various other Microsoft applications.  And yet this particular “Back” button has more ambiguous behaviors.  Half the time, it takes me from the current screen to the previous screen, exactly as I would expect it to.  Half the time, it does something unexpected.  Consider the following workflow:

1. I bring up the Home screen and click the little arrow to bring up the application list.
2. I click on the “Calendar” application, and it opens.
3. I bring up the Home screen again and call up the application list.
4. I click on the “Convert” application, and it opens.

Now I stop.  If I were to click the “Back” button now, where would it take me?  My experience tells me that it should take me back to the application list, because that’s the last screen I visited.  Where does it actually take me?  Back into the “Calendar” application.  WTF?  Well, that’s interesting… that’s the sort of behavior I would have expected from Windows Mobile 6.x.  But this isn’t Windows Mobile, nor does it look anything like Window Mobile.  In Window Mobile, I would have launched the “Convert” application from the “Start” menu, and I would have done so without leaving the “Calendar” application.  The “Convert” application would have then opened.  If I was working on a Windows Mobile device, and that device had a “Back” button, I would expect it to take me back to the “Calendar” application for two reasons:

1. The last screen I had open was the main screen in the “Calendar” application and
2. Windows Mobile supports multitasking.

Reason #2 is very important here.  Because Windows Mobile supports multitasking, I know that the “Calendar” application is still running, and the current screen for that application hasn’t changed since I left.  Windows Phone 7 does not support multitasking.  Once I open the “Convert” application, I expect the “Calendar” application to be gone.  Scratch that, I expect it to be gone the moment I leave the “Calendar” application for the home screen.  I believe it is incorrect for WP7 to behave like Windows Mobile because:

1. The home screen looks like any other screen.  Unlike the Windows Mobile “Start” menu, which clearly leaves my application running in the background (and I can see it running), I have no reason to believe anything is still running when I invoke the WP7 home screen.  This is doubly true in the scenario above, as clicking the arrow to bring up the application list appears to be sending me to yet another independent screen.
2. Windows Phone 7 does not support multitasking.  It seems very strange to me that backing out of an application should send me into another application that, as far as I knew, was no longer running.  Mimicking the behavior of a multi-tasking OS does not make sense.

So how does my the “Back” button work on my iPhone?  It doesn’t have one.  Why?  For one, it doesn’t make a lot of sense to have a hardware “Back” button, as the “Back” navigation command is not always appropriate.  Sometimes there is no “previous” screen to go to.  It’s better to display a software “Back” button when it’s appropriate.  And since it’s a software button, its content can be determined at runtime.  This makes it capable of displaying a contextual hint to tell me where it will take me.  Have a look at the main screen of the iPhone’s “Calendar” application:

See that button up in the top-left corner?  It’s pointing to the left, which tells me it’s going to take me back to a previous screen.  It also says “Calendars”, which tells me, “Hey!  If you click me, I’ll take you back to the calendar list!”  Now that’s a useful “Back” button.  Not all screens have such a button, of course, because sometimes there is no logical “predecessor” to the current screen.  On a WP7 device, the “Back” button is always there, and I’m usually afraid to press it because I’m don’t know where it would take me.

Wrap-Up

Well, that’s it for part one of the series.  Just over 6,600 words, and I’m really glad I can stop typing now :).  I want to dig a bit deeper into the limitations imposed by WP7’s “Zune” styling.  Hopefully I’ll have part two up within a week or so.  Thanks for reading, and please feel free to share some of your own experiences with WP7, in addition to any comments you may have about this post.  Have a great weekend!