Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Discussions

contextfree` contextfree`
  • Windows 8.1 Update 1. Blurring the line between ​Metro/​Desktop ?

    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.

  • Windows 8.1 Update 1. Blurring the line between ​Metro/​Desktop ?

    , bondsbw wrote

    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. :)

  • Windows 8.1 Update 1. Blurring the line between ​Metro/​Desktop ?

    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.

  • An interesting perspective on Metro

    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.

  • WTF, I have to buy the start menu back?

    , DeathBy​VisualStudio wrote:

     I just hope that the mindset that produced the great stuff we've seen in W8.1 and W8.1U1 coming out of the Windows service pack group is spread throughout the Windows division.

    Neither of those came out of the Windows service pack group

  • Windows 8.1 Update 1. Blurring the line between ​Metro/​Desktop ?

    "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.

  • Windows 8.1 Update 1. Blurring the line between ​Metro/​Desktop ?

    , brian.​shapiro wrote

    *snip*

    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 :(

  • Windows 8.1 Update 1. Blurring the line between ​Metro/​Desktop ?

    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.

  • Sad News

    Incredibly smart people do incredibly stupid things ALL THE TIME, so Herbie's argument is deeply wrong as well as in questionable taste.

  • Problems with modal approaches to "fixing Windows 8"

    A bunch of people have suggested the current unified tablet/PC design we see in Windows 8 should be split into two strictly separated modes (of course, having two totally separate SKUs or OSs can be thought of as an even more extreme version of this). Recently some very nicely executed design mockups by Jay Machalani got a lot of attention an praise. Kudos to him for a great demonstration of the concept, but I have a couple of big problems with it:


    1. It breaks useful cross-mode windowing scenarios.

    Having a strict modal separation between the two windowing models breaks a bunch of IMO not terribly uncommon scenarios where mixing them in some way is useful.

    * Can't have a different mode on each monitor - if one is touch/a tablet and the other isn't, for example.

    * Can't snap an app beside the desktop and have the system automatically manage the use of the remaining space. There are actually some desktop apps that have hacked a custom implementation of this - OneNote for example - so I don't think it's a contrived scenario.

    * Sometimes I like to use the availability of desktop and immersive windows to express a "work versus play" (or, more precisely, "continuing part of ongoing persistent task versus transient digression") distinction. That way I can use the "transient/play" apps without worrying about them cluttering the taskbar, slowing down the PC, interfering with what I'm doing, etc. Modal separation breaks that.

    * Some apps just work better with one or the other windowing model - e.g., part of what I really like about Tweetium is how clicking on a link will automatically shrink the Tweetium window down to a narrow strip and open a browser window in the remaining space. That of course depends on the immersive windowing APIs. Other apps such as calculators or "sticky notes" work better in desktop windows. So it would be nice to have apps like this automatically open in the right kind of window, or at least allow the user to set this per-app, rather than requiring an obnoxious global mode switch that potentially messes with everything else.

    2. Desktop apps inherently clash with the immersive app model and UX.

    While running immersive apps in desktop windows seems like it could probably work well, I'm really leery of the reverse. There are a few potential problems with running desktop apps in immersive windows that I see:

    * Desktop apps can open multiple windows and draw outside of their window. Some apps (ab)use this quite a bit for dialogs, palette windows, etc. This could get pretty awkward to map to immersive windowing - do we put each in its own "strip"? Do we make each "strip" a little virtual desktop where the app can put additional windows? Do we try some mix of the two approaches, and if so, how does the OS decide which is which?


    * A goal of the immersive app model was that the user wouldn't have to worry about closing apps or which apps were/weren't running - indeed that the concept of "running apps" wouldn't exist for most users. The system UI was designed around that - no "X" to close, no taskbar to show what's open. But desktop apps can do anything in the background, so closing them and knowing what's running is important. And when you switch modes back into the desktop, which apps should even be kept open? Since "metro" mode blurs the lines between running and suspended apps, it's not clear.

    And if you can't run desktop apps in immersive windows, and in general have a 1:1 mapping of running system/app state between modes, you can't really have a pure modal separation - either the mode switch is made destructive and essentially becomes a reboot, or you're left with a bunch of hidden stuff "running in the other mode" which doesn't make any sense. Once you really start thinking through the ramifications of alternative models the current desktop-as-an-app model starts to seem pretty elegant in some ways IMO.