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`
  • 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.

  • David Sobeski : Trust, Users and The Developer Division

    @bondsbw: They're reluctant to do that because, at least originally, putting an app in an immersive window was meant to carry a "promise" that the app would suspend/resume, be sandboxed, etc. and so users can learn to trust them in a way they currently don't trust desktop apps. Allowing desktop apps in those windows holds the danger of breaking that promise and trust.

  • Take a look at what you can make with Word

    @giovanni: The Word team proper doesn't really work on these tools, though. There's a Graphics and Visualizations team that develops the drawing and charting components used in all of Office, the individual app teams use their stuff.

  • David Sobeski : Trust, Users and The Developer Division

     @bondsbw: Problem is all of those names imply things they'd prefer not to imply:

    "Surface OS" implies it's just for Surface

    "Tablet OS" implies it's just for tablets (they want/ed it to eventually go on laptops etc. as well) and sort of implies x86 Windows isn't for tablets

    "Modern OS", while the most accurate in terms of what they hop/ed RT would eventually become, is sort of an implied dis of x86 Windows as not being modern

    Naming it with two meaningless characters was actually deliberate since it's a way to avoid pinning it down to any specific purpose.

    But the real problem with RT is that its true purpose - to have a version of Windows that's less susceptible to malware and "winrot" - is inherently difficult for Microsoft to market as long as they're still selling x86 Windows. If it were Google they could do an ad campaign lampooning IE getting a million unwanted toolbars, etc., but Microsoft can't really do this. And this problem affects the naming as well.