I agree "move to" is useful. I'm just surprised, given Gmail Labs, that they made this a default button.
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 think he's talking about the style of the buttons and not their functionality.
(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.)
I thought doing this was to obey the web usability rule of "Links must never change state, while buttons could potentially change state." - the REST model, e.g. if you click a button you're going to modify/submit something, if you click a link you're just going to go somewhere else.
This makes sense in the [Save] _Cancel_ case at least, I'm sure there are apps that aren't consistent though.
I think they're actively worse than old, normal buttons - the way they run into each other means I have to expend more effort to figure out where the button I want to click is, and then be more careful when I click it lest I hit the wrong one.
I guess his reasons for cringing at the 9-cell solution are so obvious to other web developers that he feels he doesn't need to state them. To me the 9-cell looks like an elegant and proven solution that doesn't need a 'better' way of rendering, and he just got caught up in the excitement of using some new technology to solve an non-existing problem.
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.
You're also adding a ridiculous amount of markup, it's less semantic (you have a table in your button!), and requires use of an image which requires yet another http request. If you look at the "just barely enough to be renderable" mark-up of the G homepage, you'll see that they're really big on conserving size...
I guess you might save a couple of bytes on the markup (but not like an order of magnitude), and I guess you save the HTTP request for that 200 byte image that gets cached. I guess that could make sense for Google. The semantic argument I don't get though - it's not like anyone reads web pages in source view. Unless that's the state of the art in web development and you're literally programming to the browser-metal.
The semantic argument is what you get when graphic designers and web monkeys try to articulate separation of concerns. The only way they know to partition a system is at the CSS-HTML boundary, because that's what they were spoon fed. This mindset forces them them to viciously make all HTML human readable: it is their only tool for managing system complexity. They take things like the W3C's statement that tables ought to be for tabular data only as Revealed Truth, to be enforced without question. (Seriously. A lot of them consider violating these principles to be a career-ending move, and adjust their hiring policy accordingly.)
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.
For those interested in the final gradient technique, it looks like they're just using a div with a background color of #f9f9f9 and a bottom border of #eee, then sticking it (absolutely positioned) at the top of the box that also contains the text div for the button.
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.
The technique is cool, but in this case the customization doesn't seem very helpful. The default buttons are more comfortable to use, I think, although a flat color background or a rounded button or something might be nice. A gradient on something so small, on the other hand, is overkill. (I don't mind all gradients; a soft gradient in the background can have a good effect.)
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
This change in color scheme totally switches the "look and feel" of the app for me from a pleasant, Google-y environment to a corporate, enterprise-y one. Maybe this was intentional, but I'd like to change it. There is a "classic" theme available, but it doesn't quite get the colors right and regardless I use Google Apps and Themes haven't been rolled out to me yet. For now, I'm reverting to the "older version".
Overall, I love Gmail. Just a little constructive criticism ;)
After I just spent time defending web layouts against desktop clients ... a little embarrassing.
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.
I encourage every architect in the world to design custom light switches for every building and position them in locations unique to each building. That way, everyone who enters any building has to first figure out how to identify and operate the light switches.
Agree: "Desktop clients still have a bright future thanks to stuff like this."
"Really, you find this impressive? I find it sad. 20 years of GUI evolution leads to faking round buttons and color gradient with a ton of CSS and HTML?"
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.
I strongly disagree that desktop clients have a bright future.
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 do find it impressive. I've tried it before and not gotten it too look that nice. I just didn't use enough divs, apparently. It's about 6, nested. BTW, the buttons aren't round.
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.
The problem with the official implementation (using lots of divs) is that you lose the semantical value. They should have used the <button> element that can be styled using CSS. He does mention that he tried using <button> elements, but it was released using nested <div> elements