Recreating the button

http://stopdesign.com/archive/2009/02/04/recreating-the-button.html

by peter123 • 17 years ago

110 37 17 years ago

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.

alain94040• 17 years ago

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.

old-gregg• 17 years ago

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.

ewiethoff• 17 years ago

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."

halo• 17 years ago

Why? Creating cross-platform non-native custom widgets on the desktop isn't much easier.

jgrahamc• 17 years ago

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.

mseebach• 17 years ago

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."

mattmcknight2• 17 years ago

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.

ks• 17 years ago

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

moe• 17 years ago

Let me be the first to say: http://is.gd/gw5L

Jebdm• 17 years ago

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:

              OLD                   NEW
  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 ;)

shutter• 17 years ago

Awful lot of markup for something that could arguably be better-accomplished with standard techniques (a tiny image and/or javascript progressive enhancement).

timcederman3• 17 years ago

The worst part is the new button styles don't add anything, except a jarring sense that something has changed.

(further bringing to attention that there are now too many buttons)

jwilliams• 17 years ago

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.

ahpeeyem• 17 years ago

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...

JoelSutherland• 17 years ago

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.

litewulf2• 17 years ago

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.)

timcederman3• 17 years ago

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.

cdr• 17 years ago

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.

babul2• 17 years ago

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

Harkins• 17 years ago

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.

babul2• 17 years ago

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...

aston• 17 years ago

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.

ivey• 17 years ago

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.

daleharvey• 17 years ago

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.

Luc4• 17 years ago

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.

Daniel_Newby2• 17 years ago

The article says why: to make it more easily skinnable by simply referencing a different style file. Skinning tables takes more work.

Luc4• 17 years ago

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...

litewulf2• 17 years ago

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.

salathe• 17 years ago

Any idea why Ajaxian removed their coverage of this? Originally located at http://ajaxian.com/archives/how-many-engineers-does-it-take-...

Recreating the button

Related Stories