> - State transitions are far too subtle with the current styling. The > hover can barely be made out, for example. > > This is obviously going to vary with the quality of your monitor and its > contrast settings (it was clear enough to me when designing it), but the > current styling was not set in stone, it was just a quick change that > everyone on IRC at the time liked.
This is on a screen calibrated for color and ambient light. In fact, it's my image editing workstation. But also on my laptop, which is only crudely calibrated, the change is barely noticable. > - The usability is worse than unstyled buttons, because people know > their OS widgets and know how they look like and what behavior to expect > from them. > > There is something to be said for this point, but I think people are > hiding behind it blindly for the lack of a better reason and because > they haven't taken the time to actually think through the alternative. > > I also don't think changing the button style significantly impacts the > user's ability to recognize the function of the object. In fact, I think > the ability to more finely hone the message of each button is improved. > Colors speak volumes - having the 'delete' button include red somehow > would greatly improve the understanding of its function, as red and > green are basic colors users have already associated with certain > actions and consequences. Using non-OS-standard styles allows us the > ability to customize the interface in ways which harness user > understanding outside the browser, and allows us to do it on any platform. > Can you honestly tell me that this (although hastily done and a bit over > the top) doesn't convey more information about the action being > performed than the standard > button? http://dump.chrismeller.com/habari_buttons-reddelete.png What do you think is the reason that cancel or delete buttons are not normally red in ANY OS? Also, color alone should not be a distinguishing factor for UI elements, especially if we're talking about red and green. Add icons (red X for delete) or sth so you have color + shape, at least. Red says "You don't want to do this." But seeing how the Save button is the default and the Delete button needs explicit action - more tab key presses, mouse movement + click - and that it says 'Delete', I think it's pretty clear what it does and we can assume the user knows what s/he is doing. So, yes, I can honestly tell you that the red delete button does not convey any more *useful* information to me. > You may like the buttons on OS X (I don't), but there are users of other > platforms out there. There are also those of us who regularly switch > between platforms and would appreciate a little aesthetic unity. Yeah, I'm not even using OS X, but thanks ;) I like native widgets, I also like some styled widgets, but most of all, I'm think about the less savvy users. Native widgets have a known look and known behaviour. With everything new, you ignore the users' experience & muscle memory. I'm switching between WinXP, GNOME, KDE, Series60 and sometimes OS X (when I fix other people's computers...). I know each platforms native widgets. I don't want to learn WordPress' and Habari's and Skype's and everyone's I-know-better-than-the-OS widgets. > I would also like to point out that the dropbutton concept in no way > integrates with the OS. It's a button and a select drop-down merged > together, yet it shares no elements of either. How is that particularly > intuitive to the user? While working on the new buttons on IRC, we also > discussed changing the look of drop-buttons so they more properly > emulate their default counterparts to convey a more clear purpose of > their intent and to match the newly styled buttons. Again, unifying the > entire design so we don't have big ugly black dropboxes all over the > page. Can you really tell me that it wouldn't look better using the > button style, something like > this: http://dump.chrismeller.com/habari_buttons-dropbox.png Yes, yes I can. Because designing the dropbutton like a dropdown or a button evokes the wrong response from the user. A dropbutton is not a normal dropdown, so it shouldn't look like one. It's not a normal button either, so it shouldn't look like one. The dropbutton is a whole new beast, so it's valid to style it differently from existing widgets. > Even the almighty Apple has done the exact same thing with me.com > <http://me.com> [1] and the Apple Store [2] - they replaced not only the > button, but also the checkbox with a custom control. Since they designed > the original OS X widgets and are considered *the* UI company, surely > there's something to be said for the fact that they chose not to use > them on their own sites. In fact, I would say that Apple's use trumps > any 3rd party UI "assessments" (like the one Khaled links to). > > [1]: http://dump.chrismeller.com/dc7ea1853be03c3bbc450cd80e11d250.png > [2]: http://dump.chrismeller.com/47daa54fd7a9196d584e049e8695e7c4.png And you haven't heard all the complaints that no two programs look like each other? About plastic safari vs. brushed itunes vs. aqua what-have-you? Or the outcry over Firefox 3 Beta not being completely native-looking and -behaving? > - Lastly, I don't think they fit in with the rest of the admin > (different border radius, different color, different gradient, etc.) > > > How can you say they don't fit the rest of the admin? The gradient > colors are nearly identical to the page and box background colors. The > border is nearly identical to the shade of gray we use for text all over > the place. Except no other admin element looks anything like the buttons, shape-wise or color-wise. The border color being the same as the *text* color elsewhere? The background color/gradient is not used anywhere else either. > The different border radius is because they're different elements. Half > the argument here is that they're buttons and shouldn't look like > everything else... well, should they or shouldn't they? Everywhere else, we have rounded rectangles. The buttons, suddenly, are oblong "pills". > By making them slightly more subtle, we also prevent things like this > abomination from looking so horrible: > > Buttons: http://dump.chrismeller.com/habari_buttons-comments.png > No Buttons: http://dump.chrismeller.com/habari_buttons-windows.png > and http://dump.chrismeller.com/habari_buttons-osx.png I assume that by horrible you mean the Habari style? ;) In order of preference, I'd take the Windows style over the others. The Habari style is noticably smaller than my native buttons, and the shape doesn't say "button" to me at all. And I'm familiar with the Habari interface. > The only pro argument I could see: > > - Make Habari look consistent across platforms. Doesn't resonate with me > because I don't think Habari should try to appear as a separate > platform. For me, Habari is an app. > > > I disagree. I regularly use Habari on both OS X and Windows, and would > appreciate it looking the same on both platforms. Currently all our > other input elements are styled heavily, buttons are the only ones left > untouched. Why are they different? If you can visually indicate to the > user that this modified text box is a text box and they have no problem > comprehending that, why is it different for buttons? It's not... We're not styling dropdowns, checkboxes, or input fields anywhere except for the publish page where we style the inputs. Even those have labels inside them to make it clear what they're there for. I don't think that arguments holds much water. Maybe styled buttons can work, if we find the "right" styling. Until then, I'm sticking with my vote for using native buttons. -Matt --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
