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


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

    , brian.​shapiro wrote


    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.

  • C#/XAML vs. WinJS/HTML

    felix is correct on all counts.

    Brandon Paddock, author of my favorite Twitter client and a former Windows shell developer, just made a nice post with his take on the various UI and programming models available on Win8 and other platforms.

  • Microsoft on the threshold of deleting 'appalling' Windows 8 software

    I know you're trolling, but http://msdn.microsoft.com/en-us/library/windows/apps/hh465424.aspx

    I'd say the new UI is more consistent / organized than the desktop has been for a while, at least (which isn't saying much).

  • Microsoft on the threshold of deleting 'appalling' Windows 8 software

    Personally instead of adding the ability to run modern apps on the desktop I'd rather they added more of the capabilities of the desktop world, like (opt-in) floating windows and an (optional, perhaps on by default on larger screens) persistent taskbar/sidebar, to the modern UI. Then we could be on a path to a single unified mode for most people instead of bifurcating things further.