Engineering Windows 7

Welcome to our blog dedicated to the engineering of Microsoft Windows 7

Designing Aero Snap

Designing Aero Snap

  • Comments 76

Here’s a behind the scenes look at the design of the Aero Snap feature in Windows 7.  We thought it would be fun to take a look at the overall design process of the feature and the tools and techniques used.  This feature poses a unique design challenge in that you just use the feature without any user-interface specifically to invoke it.  As with all features this is a collaboration across all of our engineering disciplines.  For this post, Stephan Hoefnagels, a Senior UX designer, presents the design perspective.  --Steven (P.S., keep an eye out on the Microsoft MIX conference this week!)

In Managing Windows windows and Follow-up: Managing Windows windows we talked about, and you shared, some interesting window management scenarios that we might address in Windows 7. We also touched on some data around typical configurations, as well as goals that guide our thinking in this area.

In this post we’d like to have a closer look at the Aero Snap feature that many of you have already been able to experience in our PDC builds, and of course the Beta. We’ll briefly describe the feature itself, but mostly we’d like to invite you to take a behind-the-scenes peek at our design process so far, and share our iterations, challenges and considerations.

Goals and scenarios

As we explained more in depth in our previous post, our top goal for the Aero Snap feature is to provide you with an effortless way to position your windows the way you want them. We want to reduce the number of clicks and precise movements needed to perform common activities. In a general sense, we want you to be able to manage your windows with confidence and create a feeling of power and control. This is something we touched on in our post on the Windows 7 taskbar as well, and really a theme that weaves through much of our new desktop experience.

Before we look at how we address our goals in the design, a quick note. In the scenarios below you’ll notice sequences of interactions that are fully written out. Sequences like: select the window, click the caption button, and then resize the window. Looking at interactions at this level of detail makes for somewhat awkward reading. These individual steps are so small, and so frequent, that for most of us they normally barely register. Why not simply gloss over some of those details? Well, we spell out sequences of events this way to force us to be consciously aware of the amount of “overhead” that is sometimes involved to get to the task at hand. It forces us to realize what we normally might not. Also, besides providing insight in the problems, it provides us with the right level of detail to consider our solutions.

Now, let’s look at the design!

Side-by-side windows

As many of you mentioned, doing a drag drop operation from one window to another is sometimes a pain. Windows tend to overlap and to get them positioned right can require a lot of fine mouse movement. Oftentimes the steps are as follows: select a window, resize it appropriately, and position it on the screen so that enough of it shows for it to be a meaningful drag or drop target. Then repeat the same actions with the other window. Similarly, comparing content in two windows requires a lot of mouse clicks, resize actions, careful arrangement, window switches, and a fair amount of mouse mileage.

With Aero Snap you can grab a window and move your mouse to the edge of the screen and the window will resize to fill half the screen. Repeat with the other window. Now with two easy motions you have a setup that makes both of these scenarios much easier to accomplish!

Put windows side-by-side with Aero Snap by moving the cursor to the edge of the screen (left to right, top to bottom)

Put windows side-by-side with Aero Snap by moving the cursor to the edge of the screen (left to right, top to bottom)

Vertical maximized windows

We know our users love the maximized window state. Many love it so much that they maximize all of their windows and never even run in any other state! However, with screens increasing in resolution and widescreen layout becoming more prevalent, the maximized window state can lose some of its appeal in certain cases. E-mail is an example. Reading long lines of text across the screen is not ideal. Your eye simply cannot track a line all the way across. Web browsing is another example. Content will sometimes not fill the entire width of the screen, leaving a lot of unused white space on the side.

Now, with Aero Snap you can you can maximize a window in the vertical direction only. When you resize a window to the top of the screen, it will also resize all the way to the bottom. Great for reading long blog posts!

Vertically maximize a window with Aero Snap by resizing the window to the edge of the screen

Vertically maximize a window with Aero Snap by resizing the window to the edge of the screen

Moving maximized windows from screen to screen

We realize there are a few multi-mon users out there, especially amongst the readers of this blog ;-). Ever wanted an easier way to move a maximized window to another screen? A way that’s quicker than clicking the restore caption button, moving the mouse to the title bar, dragging the window over, and finally clicking the maximized caption button again? With Aero Snap you can simply drag a maximized window down, move it over and snap it to the top, all in one gesture. Finally!

Arranging windows on laptops

Arranging windows on a desktop PC can sometimes involve excessive fiddling, fine mouse movements and lots of mouse mileage, as touched on above. On laptops this situation is further exacerbated by the lack of a mouse, making some of these movements even more cumbersome. For these scenarios, and our power users, we’ve introduced some convenient key combinations. Hold down the Windows key and one of your arrow keys to give it a try. You may want to try holding down Shift as well, especially if you’re in a multi-mon setup.

Design process

OK - So those are the scenarios, and the way we chose to address them. Seems straightforward enough, right? Especially for those of you that have been using Aero Snap in out Beta build. It all behaves as you’d expect. But how did we get here? Well, in this next bit we’d like to something that we don’t do that often and really give you a peek into our design process so far and some of the snags we ran into along the way. Keep in mind that this is a brief overview and by no means exhaustive. While we allude to usability testing for instance, this post is by no means meant to give insight into the scope of those efforts. There will certainly be opportunities to talk about some of those topics in the future.

Let’s have a look!

Sketching

We’re back in early 2007, and after we established window management as a potential area of interest, and identified several appealing scenarios (again, see our previous post for more detail on that stage of the process), we started with brainstorms to generate ideas. “How can we make window arranging more efficient?” “More direct?” “More fun?” are some of the questions we asked ourselves. This was a multidisciplinary process, with disciplines like design, user research, program management and development involved. All in all there were around a handful of us, certainly less than a dozen, thinking about this space at the time.

We imposed a significant constraint on ourselves: we wanted to achieve our goals without introducing any extra widgets in our UI. Imagine an extra caption button on the window title bar for instance: this may not seem too bad for one window, but when we’re talking about 10 windows or more, we’ve all of a sudden introduced a significant amount of clutter on your screen. And that’s something that we simply didn’t feel good about. After all, as we shared in our UX Principles talk at the PDC, we believe in “Solving Distractions, not Discoverability”.

We captured our, many, ideas in very quick sketches that we shared via an internal website. Transferred from the whiteboards in our offices and hallways, these took less than 5 minutes to sketch each. The sketches below are some actual examples in which you can start some of the Aero Snap ideas forming.

Early ideas are captured in quick and disposable sketches

Early ideas are captured in quick and disposable sketches

Interactive prototyping in early code

With so many ideas on paper we were eager to try out the best ones. Now was the time to prototype. Note that we are still very early in the process. We wanted our prototypes to be interactive, and we wanted to be able to live with them in our day-to-day work. So we chose to implement the ideas using early code that we could run on our work machines. For example, the image below shows a “smart resizer” prototype running on Windows Vista. Of course these prototypes are not “done” features that we could actually ship: they merely get the basic ideas working, and they definitely have more than a few “quirks” (bugs ;-)). What’s important however, is that they allow us to experience just enough of the interactions ourselves, as well as get feedback in usability studies.

Early “smart resizer” prototype running on Windows Vista, note the taskbar button created by the prototype (and the date in the calendar to get a sense of where we are in the process)

Early “smart resizer” prototype running on Windows Vista, note the taskbar button created by the prototype (and the date in the calendar to get a sense of where we are in the process)

We use this firsthand experience and early usability feedback to iterate on the ideas as we hone in on the final design. We approach this part of the process in a very open minded way and allow ourselves to be surprised. Sometimes ideas that don’t look like much on paper prove to be startlingly powerful. On the other hand, we found out that others look much better on paper than they were in practice! Since we’re not invested in any one idea or implementation yet, we freely refine, and drop ideas.

Finally, the prototypes ease us into thinking about design details. And we might stumble on some insights too (of course we tell ourselves the real feat is to recognize the insight and hold on to it). Here’s an example from an e-mail at the time from one of the team members about a new version of the “smart resizer” prototype:

I noticed something changed. In the original version if I resized it to the max it “supersized” the window. Then if I resized the window smaller, it jumped back to the normal restored state. It was as if the supersize state was different than restored state. With this version when I supersize the window and then resize it again later, it doesn’t jump back to the previous restored size. There was something kind of nice about the supersized state being different than the restored state. We should think about it more and consider making that a part of the design.

After many a prototype we settled on the concept of side-by-side windows and vertical maximized windows. We’re getting clearer on what we want to build.

Detailed design: state transitions

OK - We’ve whittled down our ideas to a good, but not fully specced, set of interactions and behaviors. Time to start filling in the blanks by asking detailed questions. “What does it mean to have a side-by-side window in a world where there used to be only minimized, restored and maximized windows?” “How exactly would you get to and from this new window state?” The e-mail snippet above already pointed to some of these questions.

Currently the common window states are (left to right) minimized, restored, and maximized, how would side-by-side and vertical maximized windows fit in?

Currently the common window states are (left to right) minimized, restored, and maximized, how would side-by-side and vertical maximized windows fit in?

Let’s look at the state problem in detail. Below is an example of two proposals made during this time that show how you can move from one window state to another, for all the different states. Which model is better?

Two proposals detailing the various ways we can transition between states

Two proposals detailing the various ways we can transition between states

To answer that question we considered more specific questions like “What states do we want to link directly and how do we move between them?” “Is it compelling to go from a vertical maximized state directly to a maximized state?” “Should the vertical maximized and side-by-side states behave similar, as they look similar?” Our answers of course guided us to the model that you are now familiar with, which is model B.

But that’s not the end of it. More details need to be worked through, and more questions come up. “What if I want to move a vertical maximized window sideways?” “Resize its width?” “Then pull it down?”

Soon you’ll find yourself in elaborate sequences of events, many possible actions, and even more possible outcomes. Which would be the most expected when actually using the entire system?

To help guide our decision making process we established some guiding statements. Assumptions that we hold to be true. Examples are: “The intuitive way to undo an effect triggered by a mouse movement is to make the opposite mouse movement.” And: “It should always be effortless to go back to the previous “restored” state so as to avoid excessive work to get the window back to a reasonable size.” Or: “If the user specifies a width for a window in a given state, that size should be preserved across state changes when it makes sense.”

Using these statements we were able to answer questions like the ones above in a predictable way and as a result craft a predictable experience. And while the underlying state transitions and rules are fairly complex when added all together, the resulting behavior is, we hope, intuitively understood. That’s definitely something we’re aiming for.

Conflicting rules

Here’s an example of a sequence problem for the really attentive reader. When working through our many new state transitions, sometimes the rules that determine what should happen, conflict. Consider the following scenario. Two rules in our new window model are:

  1. Dragging a window to the top of the screen maximizes it
  2. The intuitive way to undo/cancel an effect triggered by a mouse movement is to make the opposite mouse movement

OK – Let’s try the following scenario in your Windows 7 build. Start with a restored window. Vertically maximize it by resizing it to the top of the screen. Release the mouse. Drag (don’t resize) down the window and drag it to the top again, all in one motion. Release the mouse. What happened?

Your window should be maximized. Which means in this case we chose to follow rule 1. We could have also followed rule 2, in which case your window would be vertically maximized. We figured rule 1 would more accurately reflect the user’s mental model for this scenario.

This is just one example of the decisions we had to make for each transition to and from a window state.

Throughout this process we made sure to preserve the subtleties in the current model. One small example that some of you may be familiar with that we did tweak is the scenario of dragging a window title bar off screen. In previous Windows releases we would snap the window back halfway in an attempt to provide you with just enough space to still move the window around, while optimizing vertical space as much as possible. We chose to be a little more deliberate and straightforward here by snapping back so that the entire title bar is visible. This way you can start to rely on the fact that all of your windows are always very easy to grab, also with touch, and move around. If we really felt half of a title bar is enough, why don’t we always half it, right? For our vertical maximized window states we of course chose to keep the entire title bar visible as well, leading to a solid story all around.

Storyboards and other visualizations

State diagrams are of course only one way to look at the world. We used various ways to communicate different aspects of the feature, picking our medium based on familiarity, availability and intent. We didn��t even shy away from the occasional ASCII art as you can see below! We’ll simply use whatever tool gets the point across. Most of all, interaction storyboards were a very valuable technique to help us understand the user flows, and even though this is only a small sample, you can see we did quite a few of those.

Feature details are communicated throughout using appropriate means

Feature details are communicated throughout using appropriate means

Accidental triggers

Besides figuring out the right state transitions, one or our biggest discussions was around when a state transition should exactly occur, or in other words: when the feature is triggered. We talked a lot about “accidental triggers”, i.e. running into the feature without deliberately setting out to do so.

Aero Snap is triggered by touching the edge of the screen with the mouse

 

Aero Snap is triggered by touching the edge of the screen with the mouse

From the very beginning we always made sure that our feature did not get in the way of current scenarios such as tucking a window off-screen to the side. After all, we don’t want to have a detrimental effect on your current, expected, way of managing your windows. That’s why you have to literally touch the edge of the screen with your mouse, not the window edge, to trigger the transitions.

However, at this time, the feature as you know it now was different in one very important, fundamental way. In our early builds, Aero Snap followed an “instant commit” model. When you moved your mouse to the top of the screen, your window would literally be maximized while you’re still dragging. That is, before you even release the mouse. Moving back in one motion would literally restore the window. We liked this approach as the “preview” was very accurate, i.e. the preview was the window, and there is a certain directness in not having a commit model.

Because our UI is invisible by design, we expected some accidental triggering. In fact in some sense we were relying on accidental triggers to help with the discoverability of the feature. However, after living with the builds for a while we got a little worried because accidental triggering seemed higher than we expected. From our telemetry data we saw people running into the feature, and then cancelling it nearly twice as often as committing. In our usability studies we observed confusion as to what exactly triggered the behavior. Was it the window touching the edge that did this? A gesture? Or something else?

We’re now in early 2008. What should we do? Cut the entire feature? We actually did consider this as an option. Again, we really respect our current window management behaviors, and the last thing we wanted to do is degrade the experience. More constructively, we took on the challenge to come up with a design tweak that would address these issues. We explored several solutions. Some conservatively centered on smoothing out the resize transitions, so an accidental trigger would at least be smooth. A conservative approach for sure, but probably not satisfying enough as a real solution. Others focused on trying to detect user intent more accurately, based on the angle of motion into the screen edge, or the speed of the motion. This proved much too complex to be predictable. Maybe we could trigger the transition only when double-bumping the edge? We were worried that this would degrade the experience of fluidity and flow of the current model.

In the end we settled on the implementation you’re familiar with. We don’t trigger until you release the mouse, making it easy to back out of the effect before anything happens to your window. In addition we provide you with a smooth preview animation, and a cursor effect to help you understand what just happened. This way you can be more deliberate in the future, and use the feature to your full advantage.

Did we solve the issues? Feel free to let us know :-)

Look and feel

It’s interesting to think back and realize that up to this point we had essentially designed a feature without any visible UI whatsoever. Now all of a sudden we have window previews, and a cursor effect. What should those look like, and how should they behave?

Well, luckily we had some things to go on. At this point we had already established a clear picture of our taskbar look and feel (we call it “personality” and will talk about it more in a later post). We had settled on using glass sheets for Aero Peek. We saw an opportunity to use the same visual representation for our preview windows. But how should the glass sheets appear? After experimentation, we settled on a scale animation that originates from the cursor. This gives a subtle hint as to where this preview window came from. We also made sure to animate our transitions. Try this in your build for instance: move a window to the top, and then to the side, in one motion without releasing the mouse. Notice the smooth morph of the preview? Why did we spend time on this? We believe “Small Things Matter, Good and Bad” of course.

Light effects are used to indicate the snap trigger, and glass sheets for snap previews

Light effects are used to indicate the snap trigger, and glass sheets for snap previews

Finally, we tied into some of our ideas around “light” for the trigger indication. We tuned this to be noticeable, but not too loud and made sure to synch with other light effects in the system such as our touch feedback.

We hope this post has given you some insight in the Aero Snap feature, including our design process. We would love to hear your thoughts!

Stephan Hoefnagels

Leave a Comment
  • Please add 8 and 7 and type the answer here:
  • Post
  • I love Aero Snap and for the most part use the shortcuts exclusively.

    On another note, although the support for using the taskband on a side of the screen rather than the top or bottom is far and away the best in Windows so far, please allow it to be made narrower. Right now, with 'small icons' enabled there is what appears to be more that 8 pixels of dead space on either edge. I don't need 2 columns of notification icons, I don't need to see the date, or even the time really! I moved it to the side because I only have 600 pixels of vertical resolution so it makes more sense to save that for content.

    tl;dr: Let me make the taskband narrower when it is docked to an edge of the screen.

  • Tihiy wrote:

    "There should be way to disable/tweak Aero Snap. As suggested on Win7taskforce, when CTRL is held, disable snap temporarily."

    Kosher wrote:

    "Linux uses shift for enabling snapping, don't try to be all different with the ctrl key.  Keep it standard please."

    FWIW, Photoshop uses Ctrl to temporarily override any "snap-to-grid" or "snap-to-edge" functionality when dragging, so Ctrl would be what I would naturally try as well.

    (Whether more Windows users also use Photoshop and apps which follow that model, or use Linux, I don't know. I'm just pointing out that there are at least two standards here and the proposed Ctrl one is what I at least would find natural.)

    I also think it's better to have a key which temporarily turns the feature off, rather than one which turns it on. First, it helps people discover the feature (though they then have to discover how to override it, I suppose). Second, if the feature is well-designed then it should be rare that you need to override it.

    I have not used the Beta as a day-to-day OS so I don't know how often I would want to override it. I know I definitely would want to override it sometimes, though. (Indeed, in other programs I use that have this "docking" behaviour at the screen edges, I can remember several cases where I've needed to override it. Usually I'm happy with the default, though.)

  • I should start of by saying, that I have not had the opportunity to try out the beta. So I might be completely wrong on this.

    You mention in your post, that one of the questions that arises, is "what if you want to rezise a windows width?". From what I've seen, this is a point that has unfortunately been overlooked. I agree that Aero snap is an improvement of the old Tile vertically feature, but it does not greatly improve usability, unless the user is able to change the amount of screen real estate that one window occupies. A 50/50 split is only useful if the content of the windows, that you wish to compare or simply view, takes up an equal amount of space. I think in most cases you might want an unequal division of space, say 60/40 or 70/30.

    It would be helpful if it was possible to change the width of one window, by dragging the edge, and have the other window dynamically scale. And similarly with three or four windows tiled (video conferencing, mail, a document, browser), dragging the corner of one window could scale the remaining.

    Right now the Aero snap feature appears to only make it faster to tile vertically, but it does not really make it much easier to compare window content or divide screen real estate, as compared to the old tiling actions.

    PS: Really looking forward to the new OS

  • I must say of all of the new features introduced in Windows 7, this is the biggest letdown.

    It's like you have taken a really great idea and made a half-hearted attempt at implementing it. Why can I not snap windows to each other, why don't windows snap to monitor edges (not screen edges), why can I only perform 50\50 splitting?

    These are all relevant use cases, and it's just a shame that something that is going to impress so many people could work so much better.

    The amount of times (even in beta) that I have vertically maximised windows then had to *carefully* slide them across the top of the screen neatly stacking them next to each other.

    All I'm saying is that you have missed a lot out, somehow.

    That said, you have made a great start, so if by release you fancy squeezing the extra bits in that would be great!

  • "It would be helpful if it was possible to change the width of one window, by dragging the edge, and have the other window dynamically scale. And similarly with three or four windows tiled (video conferencing, mail, a document, browser), dragging the corner of one window could scale the remaining."

    The problem is that Aero Snap cannot know which of the windows you want resized so it would have to do it for all snapped windows on both sides of the screen, which is a quirky way of doing things. The current method allows you to snap a window and increase or decrease its width without unsnapping the window - this can be done on both sides to do what you describe.

    As an aside, one of the things I dislike about placing the taskbar on a different side of the screen - especially on Win7 now that's it is actually practical - is that the Start Menu doesn't mirror the change. By this I mean if you move the taskbar to the top of the screen then the search box and All Programs menu remain in the same place (towards the bottom) - that means you have to move your mouse much further to access the All Programs menu and means the profile picture is emerged rather than hanging down. It's still impractical to move the taskbar away from the bottom. And when you put it at the side the date looks bad because it goes right up to the edge.

    PS - I don't like the way the taskbar icons now take more clicks if there are multiple windows open. Messenger is especially bad with its "fake" window, meaning I have to click twice versus the one click it takes on Vista. It takes longer to access the windows I want.

  • @TAC4U, I agree, dynamically resizing multiple windows at once is not intuitive. It would be a nightmare for designers and users alike I think.

    But I was brainstorming about the use for splits other than 50/50, and I think there is an interface mechanism that could be usable and save a bit of effort on the users part.

    If a user wishes to place two windows in a 70/30 split for example. One window could be placed first at 50%. Then manually resized horizontally to the desired dimension (i.e. 70% of the screen). Next, when the second window is attempted to be snapped on the other side, the initial dimension for the window would display an outline of 30% of the screen and would snap to that dimension if the window is released. If the user (without releasing) instead moves the window out of the snap trigger zone and then back in, the outlined snap dimension would be 50%. I believe this behavior would be quite intuitive, because a user surprised by the non-standard snap dimensions would be quite likely to wiggle the mouse or move out and back in to the trigger zone to verify the behavior. In addition, the non-standard snap size would only be suggested if a snapped window existed on the opposite side of the same screen (monitor) which was not at all covered by any non-modal windows.

    This suggestion might seem complicated, but to me it seems very intuitive and useful from a user-perspective.

  • Thanks for nice insight into UX design process - and by the way, I have 22" monitor and I LOVE this feature :)

  • @Urvabara

    "Did you really remove the "Edit|Invert Selection" menu item? Please, bring it back. People should learn to use it"

    it was mentioned in the previous blog that this was re-instated.

  • Aero is really cool. I think it can be extended more so that of you drag the window to some corner, it will maximize itself to 1/4 of the window!!!

    Also, how about some keyboard shortcuts for cascading windows!!! or even a dedicated applet in the control panel for custom shortcuts!!!

  • I love this feature and this post! I am currently in my first year of college and I hope to be working on UX type stuff so that users find the interfaces to be intuitive and attractive. In depth posts like this are really useful for learning as well as for discovering the reasoning behind features.

  • Hello,

    thank you for insight to the process of designing the feature.

    I really like Aero Snap and use it almost everyday. However, there are - although not that often - situations, when it can get me a bit angry very easily.

    "...our top goal for the Aero Snap feature is to provide you with an effortless way to position your windows the way you want them."

    "In a general sense, we want you to be able to manage your windows with confidence and create a feeling of power and control."

    Well, that's not my case. They are cases where Aero Snap does not know what I want better than I.

    A very real scenario: running 1920×1200, open remote desktop connection and connect to a computer with 1680×1050 resolution. Now see what happens if the opened window is smaller. Obviously you don't want to maximize it, as it would stick to the top left corner. If you take the bottom right corner in order to resize it to the full 1680×1050 size, the Aero Snap starts to annoy very intensively (trying to vertically maximize it for example). You also hardly can take the window and move it around, as it gets snapped everywhere. I do not find it effortless, even possible to position the windows the way I want, and I do not feel power or control. I rather feel my efficient desktop size has been shrunken.

    Yet still, I like the feature very much. So I think there should be a way to temporarily disable it, as others already pointed out. I would keep it on by default, as it helps to discover the feature and the situations where you need to disable it are indeed not very usual.

    For me, there is no discussion how should be this done – Microsoft itself already uses proven way in its other products as Visual Studio, Office etc. – hold the control key while dragging. So it would be consistent and very intuitive to allow the control key to disable snapping the same way as it disables docking, which, in fact, is the same operation.

    The control key does not introduce any UI, any globalization problems, does not degrade the feature in any way, neither does it interfere with any other tasks (e.g. when you need to drag files with ctrl, you have the windows already positioned). What is most important is that the design is well proven and used for couple of years already, and that it allows you to accomplish the very goals you had at the beginning – that the user can place the windows the way they want and makes them feel a bit more of control.

    That are my feelings, thanks for listening.

    If interested, other notes I have are that I no longer can put the windows side by side horizontally, which I could up to Vista. I no longer can hold control and select several windows in the task bar and close/arrange/tile/whatever them. Personally, I would welcome the top and bottom of the screen to allow side by side windows too rather than using the top side to maximize a window, as you can do that in several other ways already, like double-clicking the window caption. Also maximize horizontally by resizing the window in horizontal way would at least help if the former is not going to happen.

  • As said:

    "I can manage my windows with confidence but I can't manage my files with confidence due to Windows Explorer's confidence, productivity, control and power boosting enhancements. Several others seem to be having problems too, but MS perhaps doesn't want us to manage our files with confidence."

    I totaly agree. Aero snap is a good implementation, and appears to be going to be even better.

    BUT, please, fix windows explorer. OR, better,  give me a option to simple use explorer.exe from windows xp (with libraries, they are very good), because that was not broken.

    I need to see my file sizes in the statusbar and/or preview pane, WITHOUT having to select them.

    I need to see full file names in list view, and NOT having they cut because of a fixed size column.

    When a file is selected, it´s file size appears in the uper line at right (for pictures) or in bottom line, at left (for documents) and so on... where is the consistency we had in xp?

    Can´t we have a nice option to always show file sizes in, lets say, the right of the status bar, much like xp always did?

  • Slightly off-topic but I still can't understand the sense of linking an image in the post which is actually smaller than the original one:

    example:

    http://blogs.msdn.com/blogfiles/e7/WindowsLiveWriter/DesigningAeroSnap_13DE4/image_10.png

  • Great work on this as always guys...

    One thing I can think of... SHIFT modifier should allow you to pin a window to the TOP LEFT, TOP RIGHT, BOTTOM LEFT, or BOTTOM RIGHT of your screen. Very useful for large res / projector desktops where you have the screen real estate for it!

    I would also like to see the drag to Taskbar to minimize be brought back from your original ideas! The whole thing about Snap is that you don't have to press the GUI buttons to do anything but close the window, and minimizing has always been somewhat annoying. It seems intuitive enough: you are dragging the window back down to join its icon in the minimized state: what could make more sense! :P

    Also, somewhat off topic, I would like it if there was an option to make the "Show Desktop" perform a Win+M instead. At the very least, having right (or Shift+) click perform this command would save power users some of the annoyances with Win+D...

    Lastly, I still feel a simple "pin to top" command when you right click the Taskbar would be an excellent function, and would work perfectly in tandem with Aero Snap. This would simply save me from having to run Power Menu or another third party app to perform this basic function. Also, I honestly don't think anyone would be sad to see "Move" and "Size" be forever removed from that same menu!

    Anyway guys, great work, keep it up (and implement some of my ideas from the last post PLEASE! :D)

    - AeonSlayer / Simon

  • @Simon, Move and Size menu items are required if you are working with keyboard only.

    I also use both Win+M and Win+D and wouldn't like to see go any of them.

    What I miss is the Aero Snap for resizable common (open/save) dialogs. You are allowed to double click their caption to maximize them, so I think that being able to do it by dragging is a natural request.

Page 3 of 6 (76 items) 12345»