20 Jan 2009 2224H

My experience working in Windows apps

Working in Windows apps is a bit different from working on the web. We deal more with modes and modelessness than the web does, and the kinds of widgets or controls we can apply is a bit more diverse, but the tools and general rules of thumb remain the same. 

The details are not important but essentially, in both cases, there is a workflow where a user explicitly engages a mode. In the first instance, the mode allows a user to start and stop a process and then the results are displayed back for the user to edit. But what if the user wanted to approve the results without editing? Would we display a modal dialog before edit mode? This was perceived to interrupt the user’s workflow. Instead we automatically saved the result before edit mode was engaged, system state was communicated back to the user, and then if the user so chose to edit they could do so, otherwise they could escape the mode. If the user chose to edit, that action would be a modify, system state would be communicated back to the user, resulting in a kind of edit-feedback loop until the user decided they’d gotten what they wanted and got the hell out of that mode. In this case, autosave helped us avoid a design nightmare: the user is not interested in dealing with a constant barrage of dialogs, but getting an accurate result so they can move on to their next task. 

In the second instance, we had a case where for an action involving tools, like in Photoshop with the tool palette, but for a tool where one has a number of ways of turning on the functionality. Well, the tools in the tool palette in Photoshop actually are a number of different modes, as it turns out. So too, when you use tools in the toolbar in Microsoft Office, you’re actually engaging different modes. These modes actually serve to help us before we become perpetual intermediate users by not letting us go too far astray. In the advanced mode, we start using modeless tools, that don’t require us to explicitly hit, say, the BOLD button to bold our text: instead, we might use a contextual menu to activate the function, or a keystroke, like Ctrl-B.

In this case, though, there was a problem where, with the best of intentions, the functionality was designed in a consistent manner, so that if you used the modeless method, the corresponding toolbar/palette feature would engage. This was fine for the modeless (and typically, they are intermediate and advanced) users, whose work was not slowed down, but not so for those who were still used to pushing buttons. For the button-pushers, this particular tool is applied repeatedly, serially, within a short period of time. But the problem was that after the user applied the tool, the button would click off, in order to be consistent with what was going on in the modeless method. This then forces the user to re-engage the mode by going back to the toolbar to press the button again, just to perform the next task with that tool, then it would click off, and they would have to repeat the whole thing over again. Very frustrating. So what we have decided to do is to disaggregate the functionality: if you use the modeless method, the tool button will not engage: this will suit the power user who didn’t need that anyway. If you use the modal method however, the tool button will stay engaged now until the user explicitly disengages the mode, thus allowing them to use the tool as much as they would like, which is to say, very much. 

Permanent link to My experience working in Windows apps

Filed under Interaction Design, Technology, User Experience, Work

Be the first to respond to "My experience working in Windows apps"

RSS feed for comments on this post. TrackBack URL

No responses yet.

And now it's your turn.

Fire your weapon, soldier. Just be careful of friendly fire. NAME & EMAIL required.

Your response