Hacker News new | past | comments | ask | show | jobs | submit login
Use Google+ to Improve Your UI (pixify.com)
183 points by blakeperdue on July 18, 2011 | hide | past | favorite | 44 comments

One interesting difference: Google just uses <div> for their buttons instead of <a> tags or even <button>. They also don't set cursor: pointer (the hand) for them.

Any UI people want to comment on the best practice for cursor styles? I always figured pointer should be used for all buttons or links that have an action attached.

I, personally, hate buttons without cursor:pointer. Hover effects are nice and all, but they're often rather subtle, and your eyes are attuned to the cursor already. Changing it is extremely visible, and gives you immediate feedback that you're hovering something actionable. Anecdotal, but I find I "see" when my cursor enters a clickable region much more quickly if the cursor changes - I click sooner, rather than making sure it's positioned inside the element.

I find that I subconsciously interpret cursor:pointer as "clicking here will do something with GET semantics" vs. cursor:default as "clicking will do something with POST semantics". I feel about the same way about cursor:pointer-styled buttons as I do about plain blue-underlined "Delete" links.

I wonder if that's born from OS UI semantics... interesting. I wonder what pushed us in opposite directions.

Well, the old technical limitations of the web have muddied the affordances somewhat, but my rules is generally "add cursor:pointer if the button behaves like a link, leave it unchanged if the button behaves like a button".

Most of the G+ buttons actually behave like buttons, i.e. you click on them and something happens on the current page. They don't have cursor:pointer, but they have other standard button hover effects. Pre-AJAX, the web had a history of tarting links up to look like buttons so they would seem more "clickable". Those kinds of "buttons" should get cursor:pointer, but not any other hover effects.

My rule is add cursor: pointer if you can click on it.

Just because browsers didn't do that in the past for form buttons doesn't mean they did the right thing.

Agreed completely. At minimum, and this should be obvious, but you should never leave the text/I-beam cursor on something that can be interacted with (e.g. buttons, sliders, tabs). (I would have only upvoted you, but with hidden scores, who does that help?)

(It's meant you've expanded on ars's point, which is a win from my point of view.)

This is absolutely terrible for accessibility. Screen readers will not handle these buttons properly leading to a significantly more difficult experience. James Edwards actually talked about this at The Highland Fling conference a few weeks back.

The Google buttons do use the ARIA role="button" attribute, which should let them work in screen readers.

Good point on accessibility. Anyone have links to making your UI accessible (including buttons)?

Here's a pretty good introduction on ARIA which is what Google uses to make their web sites accessible: http://msdn.microsoft.com/en-us/scriptjunkie/ff743762

Or for people using Vimperator/Pentadactyl :|

FWIW, I asked also this here: http://www.quora.com/Whats-best-practice-for-buttons-on-sing...

Would be cool to get more opinions on it.

Also note that the buttons in the header area of Google+ are <a> tags, probably since they actually link to separate pages. I guess that's Google's practice.

Yes, use pointer. I don't know why G doesn't, but that is not good practice. There should be a visual indication that an object can be clicked, other than a highlighted border.

Yes, changing the cursor to indicate the element can be clicked is the easiest method to communicate this and for the user to understand it.

But it is not unheard of since desktop applications most likely do not change the cursor hovering on a button. It is mostly a web browser feature.

It's always been my belief that one should try to stick to the browser's native behavior when possible. Web browsers (on personal computers) have pretty consistent pointer states for links (which take you to another page) and form elements (which activate an ability on the current page [with the exception of 'submit' buttons]).

In this regard it seems like Google is doing the right thing. Only run against the user's previously acquired assumptions if there is a very good reason.

Is there some downside that I am not seeing with relation to using <button> instead of a <div>?

I have always used <button> tags (occasionally <a> tags as well). Along with a css reset and some custom changes I can make the button look like anything I want.

These look good to me (apart from the previously mentioned issue of not actually using <a> tags or similar), but where's the license on these? Neither the site nor the download includes any license information.

almost identical to the particletree buttons from almost 4(!) years ago http://particletree.com/features/rediscovering-the-button-el...

I like the buttons described there. They were also rolled into blueprint css as the 'buttons' plugin.


Well done. Backpacking an existing fad to get visibility from early adopters on your project. Case study in excellent blog-marketing.

Thanks for the buttons too~

No, no, no! Please don't let GMail and G+'s new look become a new fad. The white space around every element is very wasteful and obnoxious. Not everyone has huge resolutions and those that do don't appreciate having to scroll several times just to see past the first 4 or 5 entries in a list view.

I like the "flatter" UI design overall, but I agree on the whitespace. Especially in Gmail. I wouldn't mind a flatter phase going through The Internets, as I think it's less distracting, but I entirely agree. Less wasteful display of data, please.

I would be interested in any info people may have as to whether such a large amount of whitespace does or does not improve user's understanding/use of sites. I like dense displays, but I'm also willing to learn how to use more powerful tools, as I value the efficiency.

Yes the extra whitespace in gmail is good. Just read TuFte's book on ink-to-information ratio. Good stuff

This has nothing to do with whitespace. It's just a CSS library for Google+ style buttons.

But it does have something (ie, everything) to do with spreading the Google+ style, which includes the whitespace.

I think you're going to lose this battle :)

I like the new layout and white space, it's much easier for me to read, but I've always liked this style. In fact, I have a tendency to double space much of my code and other coders hate that I do this.

The only think I REALLY don't like is the giant red COMPOSE button. Uhg. I just want to change it to another color. I REPLY all the time but don't compose often, and having this giant red eye-sore there all the time is very uncomfortable.

I'm using the new gmail theme, and I don't have any of those complaints. I'm on a medium resolution screen (1400x1050 I think) and I currently have 18 mail entries visible.

It definitely took me a bit to get used to a typography-centric layout. I really do like it now, however.

Between the dense new theme and the original, I go between 18 entries and 26 entries. The original also has noticeably more preview text. The "normal" new theme gives me only 14 - nearly half the number. Were my window a bit shorter, it would be half, because the header area and priority-inbox-label lines are larger.

The increased whitespace makes it massively less dense.

Okay, thanks. I was just about to write the exact same thing (although I may have been more dramatic complaining about the huge amount of unnecessary white space that fills my small netbook screen).

The new buttons however are quite nice and simple. There should be a hint of 3D though, to make them feel more "press-able". Other than that, I am okay with them becoming wide spread on the web, just don't surround them with so much wasted space.

I wrote a userscript that dials down the whitespace, if anyone's interested: http://userscripts.org/scripts/show/105891

It looks pretty nice but the use of background gradients is inconsistent. The buttons with a background image have no gradient but the other buttons do.

Nice catch. Know of an easy workaround to this?

You can use multiple backgrounds in CSS3: http://snook.ca/archives/html_and_css/multiple-bg-css-gradie...

Lots of details here and some catches to look out for (mostly browser support).

Warning: Multiple backgrounds can lead to LOTS of waste in the CSS (defining gradients over and over) if you aren’t using sprites for those icons (and setting all of them at once).

Nope, I don't think there are any (the CSS3 workarounds can be tricky with custom padding/margin). Google consistently uses nested elements and I think for the next few years that's the only solution that's going to work well cross-browser.

Is it me, or does this theme look similar to jQueryUI?

Unless we're talking about different things (I'm thinking http://jqueryui.com/themeroller/), it feels completely different from jQueryUI. jQueryUI is much glossier and not as muted.

Reminded me of the aristo theme which I quite like https://github.com/banzor/Aristo-jQuery-UI-Theme

C'mon, at least link back to the original ;)


In what way? The sites don't look similar, and neither do their buttons.

For the love of god people, please stop using the Silk icon set. It's had a good run and it's time to retire it.

Just wanted to say thanks for providing this - it's already been helpful

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact