(further bringing to attention that there are now too many buttons)
Without this button I needed to first label the message and then archive it. Now it is one action. For anyone that uses labels in any way like folders, this was an awesome improvement.
The one 'nice' thing about not having it was that it forced me to create filters to automatically label all my email.
I actually really like the new label functionality. Multi-select and autocomplete textbox is very nice. However the problem I see there is now every action looks the same. Before you had drop downs, and it made it easy to find what you wanted to do. Hence my too many buttons comment.
(I disagree, I think the buttons are good because they allow both fast keyboard access in addition to mouse friendliness. This behaviour differs from regular buttons and it seems reasonable for them to look different.)
This works visually, but I think it really tramples on a lot of UI metaphor.
This makes sense in the [Save] _Cancel_ case at least, I'm sure there are apps that aren't consistent though.
A blog post with some ideas on the matter:
Positioning of tables is sometimes problematic, and I'm not sure how fast a browser can render a 9-cell table as opposed to multiple nested elements, as the browser does something akin to constraint-satisfaction as it lays out the table.
The engineers think that separation of concerns is something the system designer imposes. Does your fancy button use a squirrelly pile of implementation weirdness? No problem, just create a templating mini-language with a simple syntax for expressing a button; hive off the squirrelly stuff into its own module. In their minds, making a button with a 9-cell table is Baby's First Custom Widget, at least compared to frameworks like GTK+.
Naturally there is ... friction between these two schools.
Not sure why he was trying use <b> rather than a <div> or why he stuck it on the bottom instead of hanging it from the top, but the latter approach intuitively seems like it would work cross-browser.
That's a 4 byte savings on each button. If you had a lot of buttons on a page...that could end up saving hundreds of bytes.
I'm not sure how much that matters in the long run, but it's a great attitude to have. Bytes matter, microseconds count.
I started this comment purely tongue-in-cheek, but convinced myself of the argument before I finished writing it.
I do like the way they regrouped the buttons on the toolbar, but I wish there was a little more space between them. Put a few pixels between the buttons in each group; then, perhaps, put a slightly different color behind the buttons to emphasize their grouping. It'd also be nice if the "more actions" dropdown was right-aligned.
I really like the interface on the "Move To" and "Labels" buttons. The "move to" option doesn't seem to fit in very well with the whole label-based interface, though. It's much more intuitive to label something and then archive it (it's just one more click/keystroke). "Move to" doesn't add any new functionality; it does makes label+archiving slightly more convenient, but it clutters up the menu, so I'd say remove it.
And once the "move to" button is gone, it probably makes sense to move the input box that you get when you click "label" directly onto the bar with the archive/report spam/delete buttons. Add a dropdown arrow to get to the list of labels/management stuff, and put "Labels" grayed-out in the input box by default to clarify what it's for.
The easiest improvement, I think, would be to iconify the Archive, Report Spam, and Delete buttons. That would be fairly easy to do, and it would make it easier to distinguish the function of each item and declutter the menu.
The last thing I'd like to mention may just be a matter of taste, but I definitely preferred the older color scheme. There isn't a big difference:
MAIN BOX light blue light blue
RSS BAR lighter blue darker blue
READ ITEMS lighter gray-blue light gray
Overall, I love Gmail. Just a little constructive criticism ;)
But the problems is there, css rounded corners + multiple backgrounds would solve this in a second. this is an area where I think people can afford to use incompatible css to show decent looking buttons to supported browsers and ugly ones to ie, sadly firefox still doesnt support multiple bg's (safari introduced them 3? years ago)
The main disappointment in the article is that after all that, he still didnt provide final working solution.
You know what? Desktop clients still have a bright future thanks to stuff like this.
Agree: "Desktop clients still have a bright future thanks to stuff like this."
Google is pioneering in the UI design area here, and they have a track record of supporting standards, sharing their technology and being developer friendly. To improve the usability of the web they are introducing controls that unleash the capability of the web. After trying out these buttons, I found that they are bliss for a keyboarder. Labeling and archiving before was abysmal, and different across browsers. Now it is a pleasure to use.
1. If you've ever tried to do cross-platform desktop client GUI work you'd know that getting it to look good on every platform is a nightmare. It's really no different from where we are with RIA.
2. Right now there's a large amount of work going into js frameworks that means that we'll see these techniques become standardized over time.
3. If you look at desktop clients there's actually a lot of innovation in terms of small UI components (see most things that Apple is doing) and so desktop clients are by no means static.
4. As js and the frameworks improve we'll see more and more applications move into the browser. At my current startup we are working on a very rich application and there was no question of doing a native desktop client, there was just no point tying ourselves to a specific OS.
I agree with you that web design with HTML is pretty sad in comparison to just about any purpose designed desktop client library. You get about 1/10 of the form controls you get out of the box with, let's say, VB6, and it's tough to extend.