It is ingenious, but OTOH "straightforward is better than clever" (an Office 2007 design principle that was not explicitly adopted for Win8, despite some of the same people being in charge). I'm somewhat ambivalent about these affordances and mechanisms - there are certainly a lot of complains about them, but I'm not sure there's a clearly superior alternative either.
Thanks for the explanation. That makes sense. In many contexts that would be advantageous. In regards to charms people have used infinite edge to justify how great the feature is and easy for users to access because of it (and by no means am I suggesting you are one of those people or that you even like the charms implementation). What they overlook is the mouse actions after the target has been hit and how easy it is to slide off the charms bar while moving up or down the bar which causes the bar to disappear. So again in the right context infinite edge makes sense.
Sliding off the charms isn't really a problem if you swoop around the corner in one smooth motion rather than stopping and waiting in the corner for a second. The momentum from moving to the corner will carry through and keep you pinned to the edge during the move up (exception: shared edges on multimonitor, which I still find to be somewhat awkward/unreliable even after the improvements in 8.0RP and 8.1).
I find the gesture to be fairly comfortable, efficient and enjoyable when done this way, but I think the real problem is the visuals and animations don't really guide users to the "right" way of performing the gesture and tend to make people think they need to wait in the corner until the charms hint appears.
BTW, it's interesting to remember this actually wasn't their first design for this mouse affordance. If you recall in the first Win8 Developer Preview the right-hand "hot corners" didn't exist, and the mouse way of using the charms was as a more compact "menu" that appeared in the lower left with the Start button. The main problem with that design I think was the excessive mouse travel it added to using any charm flyout (since they still appeared on the right) as well as being less consistent with the touch approach (not a big deal, but consistency here is a nice-to-have for ease of learning and comfort when going back and forth between input methods).
The CP design solved those problems but also introduced a couple of new problems. The first is the weak visual feedback as discussed above. The second is more subtle, but I think even more significant: by separating the mouse affordance for the charms (right corners) from the efficient and familiar mouse affordance for Start (lower left corner) access to core OS functions became scattered - there was no longer a single entry point for fundamental Windows controls as the charms were intended to be. I think complaints like "why is shutdown/restart in a charm?" would be less prevalent if Start were perceived as "belonging" to the charms and so the charms were perceived as the top-level starting point for finding Windows functions, rather than an add-on.
Personally, I'd consider going back to the DP design but just moving it from the lower-left to the lower-right corner. Of course this would mean moving the Start button to the lower-right as well ... would that freak people out? :)
Windows already steals the top edge for its immersive window management affordances so you don't actually lose anything there from changing the details of how they look/work with a mouse.
I don't really see novice vs. "power" users as the important dichotomy here. I see it as global vs. local optimization.
e.g., the example you gave, where taking a "just add a more prominent button" approach to discovery issues, where the pressure to make each individual thing more discoverable triggers a discoverability arms race that ends up making everything less discoverable and the system as a whole less usable - that eventually ends up detrimental to "power" users as well, they just have a higher threshold before it does. Conversely a capability cast as "only for power users" might turn out to be valuable to everyone if designed and implemented really well - it could just be that previous implementations had nonessential surface flaws that only "power" users were willing to work through.
I don't understand half of the bickering here. Even in Windows 7 and as far back as applicable, if I click the close button or choose to close the app from the taskbar, the application might not close immediately anyway:
- Some apps need to do extra processing
- Many apps ask for user input (e.g. asking if you want to save)
- Some apps ignore standard app close behavior *cough Excel* but instead close just the top MDI child
- Several apps don't actually quit but rather minimize to the system tray
For any of those cases, if you want to kill an app immediately, you need to use the Task Manager. And if an app isn't responding, you need to use the Task Manager. There are a host of reasons that the only way I can kill an app immediately is to do so via Task Manager.
So why do we suddenly need a separate mechanism to force kill metro apps? From my perspective, this isn't making it work like the standard desktop... it's making it something completely different.
The application should have control over how it should respond to a close request. Perhaps that's what is missing (but I haven't done much WinRT programming so I'll defer to people who know whether this capability exists currently).
Yeah, WinRT applications don't have control over how they respond to a close request, and this is very much intentional and done precisely to stop apps from exhibiting the obnoxious behaviors you listed. :)
I'm going to be obnoxious and repost my comment from a couple pages back as I think it's still pretty pertinent to the discussion:
I'd say as soon as you have a persistent taskbar (at least with the current Windows taskbar design, where it becomes unusable with too many apps open), and a prominent close button you've established the expectation of manual task management. That's a fair enough tradeoff for the power the taskbar gives you (though it might be interesting to try and design a new taskbar that didn't require this tradeoff - it would probably require separate sections for pinned and unpinned apps, since to scale to app usage > size of taskbar the unpinned section would have to be presented as a LIFO stack rather than a FIFO queue), but I really hope this won't eventually be the only mode available for "PC" form factors.
In general, I agree with Andy that you lose something valuable by doing this and that's a shame, but I'm not sure it's not a necessary tradeoff. But I definitely don't agree this makes store apps pointless - you still have the modern APIs, you still have the isolation, you still have the deterministic install/uninstall, you still have contract support, you still have ARM support, you even still have suspension and constrained backgrounding on minimize. And of course for device classes or users that don't have this setting checked you still have the full benefits (and drawbacks) of the app switching model that existed before.
I'm pretty sure many on the Windows design team would disagree with his characterization of the design goals.
I think the biggest wrong part is that the "consumption vs. productivity" thing was mostly about trying to reduce the scope of the scenarios the new UI would support in v1 (i.e., Windows 8.0) to make the project tractable (i.e., avoid another "Longhorn"). It wasn't really the intended end goal of the new UI in the long term - the idea was always that the scope of the new UI would gradually increase to support more scenarios, including productivity scenarios, until it eventually encompassed the overwhelming majority of usage for the overwhelming majority of users. We already saw some progress in that direction in Windows 8.1.
Also, "consumption vs. productivity" != "casual vs. power users". Not different groups of users, but different modes of operation, with many people doing both. The Windows group didn't really categorize people into casual and power users exactly, they had a concept of "enthusiasts vs. humans" which isn't quite the same thing and they didn't necessarily map it 1:1 to scenarios or features.
"That's not what happens with Alt-Tab, nor the Metro task switcher, so now you've introduced yet another inconsistency. Nor does it really make sense when a Metro app hasn't been foregrounded in a long time and therefore decides to resume as if launched from scratch (following the design guidelines) because you then get the weird behaviour of the app seeming to restart when you already had it "running""
Terminated/tombstoned apps do appear on the left edge switcher - you'll see them as a thumbnail of the splash screen. They don't appear in alt-tab though.
Anyway, I'd say as soon as you have a persistent taskbar (at least with the current Windows taskbar design, where it becomes unusable with too many apps open), and a prominent close button you've established the expectation of manual task management. That's a fair enough tradeoff for the power the taskbar gives you (though it might be interesting to try and design a new taskbar that didn't require this tradeoff - it would probably require separate sections for pinned and unpinned apps, since to scale to app usage > size of taskbar the unpinned section would have to be presented as a LIFO stack rather than a FIFO queue), but I really hope this won't eventually be the only mode available for "PC" form factors.
Your point about dragging tiles to the taskbar is true, although currently, dragging an item down to the bottom of the screen brings you into the semantic zoom mode, and it would disrupt this behavior, and maybe needlessly...
Have the devs reconfigured the semantic zoom trigger?
Drag down to zoom out and back into a group to zoom in is probably the coolest interaction in all of Windows so I'd really hate to see it go :(