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 :(
The taskbar being available everywhere is the only "absolute" improvement (potential improvement, depending on whether overloading the bottom edge causes problems or not) here though, because the taskbar is a very powerful tool and there was nothing like it available for modern apps (or rather for use across the whole system) before.
All the other stuff (title bar, context menu, etc.) might be welcomed by some/many users for its familiarity and semi-consistency with desktop, and I'm not putting that down - it might be enough to make them the right thing to do. But IMO they're not really inherently any better for the mouse - they just have a different, overall comparable, set of pros and cons.
Take the context menu for example - it has the downside of messing with multiselect. One of the nice things about the original Windows 8 input design is that it did finally introduce a simple, consistent unified model for selection, multiselection and commanding, all done with right-click. Right-click anywhere for global commands, right-click on an object to select it and show its commands (and global commands), right-click on multiple objects to select all of them and show relevant batch commands (and global commands). No need for cruft like double-click or Ctrl-click (that, even after decades, are still confusing to/not understood by a large swath of users). Conceptually a much better model. (There are other advantages of the app bar which I won't get into right now)
Of course as many people have pointed out, the implementation in Windows 8.0/8.1.0 required extra mouse travel from the selected objects to the app bar (and back again), which is definitely a real disadvantage. But I think there are better ways of solving this problem without sacrificing the advantages of the new model. For example, the Office "floatie" toolbar that appears near the cursor when you select text etc. in Office 2007+ seems like it could fit the bill. It's made available directly when the selection changes (no need for separate explicit selection, multiselection and commanding actions), requires little mouse travel, but is designed to be inobtrusive so you can ignore it when not relevant.