Ah, that's much nicer, cheers

Downside; it looks usable now so I'm going to have to spring for a VAX license extension... *grumbles*

It's awesome how the most unimportant stuff like the capslock got such a huge backlash

anyone using the german version? i today learned about "ctrl ,", the coolest quickfind window ever in visual studio. but ctrl comma doesn't work, so i'm still trying to find out what the shortcut is in the german version.. *annoyed*. and by asking that, i might actually have helped some others to learn about that shortcut..

It's awesome how the most unimportant stuff like the capslock got such a huge backlash

I wouldn't have said it was unimportant; UI details are important and caps are both distracting in that they draw the eye AND are known to be harder to read than mix case.

Same deal with the lack of colour; it takes the brain longer to recognise and decode a destaturated image than it does one with colour, certainly when picking it out of surrounding destaturated colours at that.

In fact the mindset that UI presentation isn't important which seems to exist for many many programmers is the reason why most 'normal' people don't like programmer created interfaces... it's also the reason why our program designed UI at work for the artists tools was utterly disliked by everyone who tried to use it and resulted in a complete UI rebuild. (Ironically the design the artists, the primary users, like is one that a few programmers dislike...).

In short; hell yeah the details are important.

Same deal with the lack of colour; it takes the brain longer to recognise and decode a destaturated image than it does one with colour, certainly when picking it out of surrounding destaturated colours at that.

I agree with what you said, but VS has never really been that colorful anyway? At least not by default. Unless you were just talking about in general

Yes, details are important. That's why they actually used capslock in the first place to separate the menu from all other textual stuff in a simple, but visible way. It was visible and noticable, the reason everyone got so mad is the same reason it's actually useful: one can see it and separate it.

and yes, i'm fully supportive of proper design and stuff, and details. that's why i support and use metro, having found a style that i understand in concept and execution. interestingly, the ui of visual studio fits me much more than the older ones, being less cluttered with random ui lines and stuff that make no real sense.

and the reason why everything got grey, and why it's a good thing, ask everyone in your teams that works with 2d or 3d art programs. they're all totally grey for a reason, too.


anyways, i hoped, mainly, to log on here to find someone who could tell me where to find ctrl-comma which is a real usability feature. unlike capslock or not capslock.

Yes, details are important. That's why they actually used capslock in the first place to separate the menu from all other textual stuff in a simple, but visible way. It was visible and noticable, the reason everyone got so mad is the same reason it's actually useful: one can see it and separate it.

I think the problem is that the kind of users for this program relies much more on shortcuts and barely touches the menubar (and when they do it's likely they do so using the keyboard), so making the menubar stand out for no real reason is an unnecessary annoyance. A relatively minor one, but still an annoyance.

Though I think the response wasn't so much because of the menubar per-se but rather because of how Microsoft reacted. It was an unneeded change, and they tried to justify it, and even their argument was flawed as they aren't being very consistent across all their current products regarding using all-caps either. This probably caused a worse backfire than the change itself.

I'd have rather gone with small-caps if they really wanted to use caps (you know, using smaller caps instead of lowercase), but no idea if that's doable (and would probably require custom menubars, while going all-caps was just a matter of changing a few strings).

and yes, i'm fully supportive of proper design and stuff, and details. that's why i support and use metro, having found a style that i understand in concept and execution.

I'm not really fond of the Metro UI. I has been looking at that free PDF that came in the MSDN newsletter some days ago that teaches how to use Metro, and I couldn't help but headdesk at stuff like forcefully making the app UI wider than the screen to force horizontal scrolling, even if everything could fit perfectly without cluttering the screen. If stuff like this is meant to be the standard for Metro apps then it's a massive step backwards.

It does not stand out for no reason. It stands out to separate from the rest of the ui (they're menues, not labels, for example). now wether or not that helps to not use them, or to use them, that's for each owns' way to use. but separation helps for BOTH.

i'm using metro from phone to tablet to notebook to desktop to tv screen, and i can honestly say it's the best ui concept that ever came out from microsoft, and definitely NOT a step backwards. it's a HUGE step indeed, so a lot (esp powerusers) need to get used to it. esp. power users because they have to learn new stuff (and ironically, power users hate that the most). but once you move on beyond blindly hating it, it's a great ui.

and no, there's no useless scrolling in the design. that's still bad design. but there is the fact that typically, you have content that grows => some form of scrolling should be implied. as on EVERY web page on this world, and most other apps including visual studio at several places.

and no, there's no useless scrolling in the design. that's still bad design. but there is the fact that typically, you have content that grows => some form of scrolling should be implied. as on EVERY web page on this world, and most other apps including visual studio at several places.

The issue is, we're talking about enforcing scrolling where there really isn't need for it at all, not adding scrolling where it could be useful. In fact, the example app shown in that book is more likely to benefit from vertical scrolling (by having the list becoming too big) than horizontal scrolling.

It's bad design and there's no excuse for it. By all means add scrolling if that means less clutter or making it easier to fit stuff without making it too small, but don't add scrolling for the sake of scrolling. That's just bad.

The issue is, we're talking about enforcing scrolling where there really isn't need for it at all, not adding scrolling where it could be useful. In fact, the example app shown in that book is more likely to benefit from vertical scrolling (by having the list becoming too big) than horizontal scrolling.

I think this is part of the UI switch just being uncomfortable. In general it looks like metro is trying to switch to a more horizontal approach, so it's probably more typical that developers will want their things to scroll horizontally to correspond with it.

It's bad design and there's no excuse for it. By all means add scrolling if that means less clutter or making it easier to fit stuff without making it too small, but don't add scrolling for the sake of scrolling. That's just bad.
[/quote]
I'm confused. You're saying that it's a dynamically sized list, which would totally justify scrolling, but then you're saying that you're adding scrolling for the sake of scrolling, which would indicate that you know the list will never grow larger than the size of the screen. Can you clarify? Not criticizing your point, I just think it hasn't been as clearly presented as it could be yet.

I think this is part of the UI switch just being uncomfortable. In general it looks like metro is trying to switch to a more horizontal approach, so it's probably more typical that developers will want their things to scroll horizontally to correspond with it.

OK, let's say they want to do things horizontally (which makes sense, considering that in a touch screen to make the appbar to appear you need to do a vertical swipe - though I think that's limited to a small region of the screen). It still doesn't explain forcing scrolling when it still isn't needed.

I'm confused. You're saying that it's a dynamically sized list, which would totally justify scrolling, but then you're saying that you're adding scrolling for the sake of scrolling, which would indicate that you know the list will never grow larger than the size of the screen. Can you clarify? Not criticizing your point, I just think it hasn't been as clearly presented as it could be yet.[/quote]
The list grows vertically, not horizontally =P

Let me put it simple: the example app is forced to scroll horizontally by explicitly setting the total CSS width to 120%. There is not a shortage of space here, mind you, so scrolling really isn't justified. In fact, let me quote the PDF:

It is common in Metro apps (or at least common in the ones developed so far) to provide a content area that is wider than the screen and allow the user to scroll from left to right to access different regions of the app. Setting the cumulative width to 120 percent sets up that behavior, which you will be able to see when I run the example web app later in this chapter.[/quote]
This is in the first chapter. I could understand if the app tries to show a lot of stuff at the same time (then you may want to add scrolling to give more room for stuff), but this isn't the case of this app. Maybe that's the point it's trying to convey, but the way it's explained makes it look like all apps are expected to implement scrolling regardless of whether it's really needed or not.