Recreating the button(stopdesign.com)
stopdesign.com
Recreating the button
http://stopdesign.com/archive/2009/02/04/recreating-the-button.html
10 comments
I disagree. The "Move to" button was a great addition. I have a "Needs Response" label in Gmail that I keep full of things I must act on. When I get email, I immediately move it from my inbox.
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.
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.
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.
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 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.)
Yep, I was more talking about the style. I do quite like the keyboard functionality, but 99% of Gmail users will never notice/use it sadly.
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.
There is also now a trend to mix button and hyperlink styles - usually where one has emphasis - e.g. (Save) _cancel_
This works visually, but I think it really tramples on a lot of UI metaphor.
This works visually, but I think it really tramples on a lot of UI metaphor.
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.
A blog post with some ideas on the matter: http://www.svennerberg.com/2008/09/the-use-of-buttons-in-web...
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: http://www.svennerberg.com/2008/09/the-use-of-buttons-in-web...
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.
Other things to worry about with tables.
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.
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 article says why: to make it more easily skinnable by simply referencing a different style file. Skinning tables takes more work.
I see, but I assume(d) that it would be just as easy to skin the 9-slice table method through CSS. But then, I am not a web developer...
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.
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.
Thanks, that was funny to read, and I am glad to find out I belong to a school of thought :)
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:
Overall, I love Gmail. Just a little constructive criticism ;)
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:
OLD NEW
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 ;)
Awful lot of markup for something that could arguably be better-accomplished with standard techniques (a tiny image and/or javascript progressive enhancement).
Any idea why Ajaxian removed their coverage of this? Originally located at http://ajaxian.com/archives/how-many-engineers-does-it-take-...
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.
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.
He was using <b> instead of <div> because it was shorter.
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.
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.
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.
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.
Forgetting about the layout wars with the forces of table for a minute (forever, please?), this is a really nice use of CSS+JS. No images...impressive.
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?
You know what? Desktop clients still have a bright future thanks to stuff like this.
You know what? Desktop clients still have a bright future thanks to stuff like this.
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.
Sorry I'm so crabby about this. But, by golly, Google's new "button" really calls out for the question "Why?" And to think on top of it all, Google has to go through a lot of trouble (probably Javascript trouble, though I haven't studied the code) to make these silly "buttons" tabbable. Pretty soon, every Web 7.0 kiddie will try to replicate Google's "buttons" and fail to make them tabbable.
Agree: "Desktop clients still have a bright future thanks to stuff like this."
Sorry I'm so crabby about this. But, by golly, Google's new "button" really calls out for the question "Why?" And to think on top of it all, Google has to go through a lot of trouble (probably Javascript trouble, though I haven't studied the code) to make these silly "buttons" tabbable. Pretty soon, every Web 7.0 kiddie will try to replicate Google's "buttons" and fail to make them tabbable.
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.
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.
LIghtweight multi-platform XUL is something I think may be the answer. I'd like to take browser's connectivity and JavaScript VM, but non of HTML/CSS nonsense. XUL seems to work, and can be served from the cloud, but it's not easy to program for.
One positive thing about XUL is that it makes the GWT/pyjamas (pyjs.org) approach seem reasonable if not downright natural.
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.
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.
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.
Why? Creating cross-platform non-native custom widgets on the desktop isn't much easier.
If a desktop client is an option, so is "use [Firefox|Safari|IE7+] is access this app, or live with slightly less polished UI. kthxbye."
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
In case you miss the (non-obvious) link in the article (or do not want to read it), the final buttons (v3.1, created without using any images) are...
http://stopdesign.com/eg/buttons/3.1/code.html
http://stopdesign.com/eg/buttons/3.1/code.html
Those were not the final buttons -- the article and that demo page note that the final buttons are only visible in production, the last demo doesn't work in IE and has pretty heinous markup.
Sorry, incase it was not obvious meant the final buttons in the article not the ones they actually use in production (which he says you have to reverse engineer yourself) as per his comment http://stopdesign.com/archive/2009/02/04/recreating-the-butt...
Let me be the first to say: http://is.gd/gw5L
(further bringing to attention that there are now too many buttons)