I was reading Adam’s preview of Red Hat Limbo beta 2 the other day, and was also checking out his screenshots. I already did a Gnome 2 review a few months back, and a month ago I did a more constructive article on KDE 3’s UI. This time, I just picked a random screenshot off Adam’s article, and I will suggest some UI changes to make it look better. IMNSHO, as always of course, so be prepared. Update: My post to Gnome Usability mailing list, regarding a more refined/fixed version of my GUI suggestion for the specific theme discussed.As many of you already have noticed so far, I am a control freak. I want my work, my life and especially my desktop to be pixel perfect. You either give me something that looks good, or I will trash it in my review. That’s the deal, and I am not hiding behind my own finger. Whatever I find good, it will be praised, but if I find flaws, these will be pointed out in a pretty critical manner.
So, I opened up Gimp last night, and tried to modify a part of this screenshot. I tried to modify just its two preferences panels, a Font Preferences one (made by Red Hat and not by the Gnome project, I think, doesn’t really matter) and a Theme panel.
Please note, that I do not just criticize Red Hat here, but also Gnome2, the person who did the themes, and the GTK+ project, as all of them have their own small part to that overall UI disaster that was shown before me on an OSNews article. It is not one person’s fault, and it is not one’s team fault. It is the fault and miscommunication of many people, many projects and companies. The fact that a Linux desktop is consisted from many different components made by different teams, is its strong point, but when speaking of its UI, is its plague. Inconsistency to the max.
Same goes for KDE, of course, but Gnome2 has more visible problems. For a UI to work well, the people doing the toolkit, the UI designers, the developers, the font engine guys and the distribution company should be under the same “roof”. You either having the developer on a meeting with his UI designer, and the font engine guy talking to the Toolkit team face to face about how to make things better, or you end up creating UI atrocities, glued together.
Oh, yeah, flame as much as you want. I am wearing my flame proof Dolce & Gabana jacket. At least I respect my (jacket) designers. 😉
All I did in the following screenshots was to clean up the UI of two preference panels that will come with Linux’ more popular distribution: Red Hat. I did nothing more and no less. As a user, I do not care who did what, and who programmed or designed what, what I care, is that it should look good, consistent, and logical. Some of my clean ups are only 1 pixel changes here and there, or changing a color to a tiny tint different one. To see many of my changes you will need to zoom in or wear your glasses in order to notice the rounded widgets or the change of some colors. But when you look to the original and to the modified one, side by side, possibly from a distance, the modified one just feels more “right”.
The Original | The Modified |
Please note, that most of the following points, can apply to whatever theme is used. They are generic enough.
Changes I made:
1. ALL the widgets are now rounded. Just one pixel off their corners and you immediately get this nice smooth feeling. Combo boxes, buttons, Tab Views, Sub-Views, the font input text etc, are all have been rounded.
2. The Theme Panel’s “Help” and “Close” buttons do not perfectly align with the Tab view.
3. That huge Nimbus font used *everywhere* at the *same* size (no matter if it is plain text, or widget text) is terrible. Its characters are glued to each other in many cases, it is big and it is ugly. I simply used the ever present, Arial font. It is not something that you find in space, just Arial, in different sizes and modes. Please replace it with whatever equivalent font, if Arial costs too much to license or something.
4. The little underline under each word’s letter than happens to be a hot shortcut, it is too big.
5. That “Details…” button on the Font panel is stupid. It does not really give you a clear idea of what it does. Does it give you more details on the choice you just clicked? Does it give you details for all the Font Rendering settings available?
Check my “More Settings…” (rather modernized) HTML-like link instead of an abrupt button. Of course, here, I have to guess that this “Details…” button is about having more settings.
6. The Theme panel has unnecessarily big width. In fact, the font used inside the list view should have been smaller anyway, but even with the current font size, the list view is too big. I can hardly imagine someone naming a theme as long-ish as “My Beautiful Atlantian Theme – Under the GPL too! Hoorah!”
7. The “install new theme” and “go to theme folder” buttons have been aligned with the list view in my version. I also changed the “Go to Theme Folder” to “Open Theme Folder”. “Go To” might mean that the current application might change to a file manager and get you away from the current view (that of course, doesn’t happen, but “Open Theme Folder” is more correct).
8. The default radio buttons are too big. They look like holes…
9. The input text placeholder showing “abcdefgop AO” etc., have unnecessarily big height. Instead of the characters to be aligned “middle” in the text field, they are aligned “bottom”, leaving all this white space on top of them. Also, the fourth input text placeholder is wrongly, 2 pixels shorter than its neighbors. Also, the first row is one pixel off on the left, than the second row.
10. Very important: The background color of the “Font Rendering” child view and the background color of the Tab child view on the Theme panel is now RGB(226,226,226) while the parent view is RGB(230,230,230). It is hardly noticeable, but it really helps creating a real object oriented system, with colors and boldness, making it nice and logical to the user’s eyes. The parent view should have the fairest color, any children views should have a tint bit darker color, and the buttons and widgets should be a bit darker than that. In our case, the buttons are now RGB(222, 222, 222). A window’s menu background (File, Edit etc) should also have this tint different color as the tab view or any other child view. Object orientation is a Good Thing (TM), even at your desktop, even when created with nothing by colors.
11. The line around the “Font Rendering” child view is now a bit darker, making the child view more distinct.
12. And talking about object orientation with colors regarding views, the same should be true for the text. Notice that I have as “Arial, bold, size 8” the headers of the Tabs, and the child view of “Font Rendering”. It is really like a header to a new chapter/child view, and it should look like one. To do all that today, a theme can’t do it. You need the GTK+ guys to allow this! Come on guys, you know you want to do this, even if it breaks the current themes and even if the current available fonts for Linux suck when used in different sizes or enable boldness. But do the right thing and ask people with money and a reason to do so (e.g. Red Hat, Mandrake and other companies richer than you and me) to license better fonts to get bundled with XFree86, because the default configuration is the only one that matters, not what a user might or might not change (IF he/she is allowed to change in a corporate environment anyway).
13. Buttons are Arial size 9, and normal text is size 8.
14. The combo/drop down boxes have been made smaller (via code you can tell the combo box to have a standard default size, even if the inside data might need more space – the box will expand when in use to meet the size of its larger option). They are also centered and their accompanied text on the left side, they now have been aligned on the right (and not on the left as they were originally – hope this makes sense).
15. Notice the Tab differences between the two shots. The modified version exhibits an inset look of the non-selected tab.
16. Now, create event states for all major widgets (for example, for buttons it would need tiny bit different looks for onMouseOver, when selected, when pressed and onMouseOff) for all themes included in an official distro, and there you go, you get a great, clean UI.
17. I won’t talk; neither did I touch this window manager theme and the thick/unattractive border it exhibits around the window. It looks bad, unoriginal and it should not be used as the default one (not sure if it the default or not for Red Hat 8).
And these were more than 15 points of modifications needed (without counting the actual window manager issue), to only two preference panels. I do not want to think how much time I need to spend to modify or simply clean up the whole distribution’s UI and/or Gnome2 (sorry Spark, too much work to do :). It is a dirty job, but someone’s got to do it. People will pay money to Red Hat. But I won’t, unless they fix these issues on each and every window or menu they include. MacOSX’ Aqua might be a bit too much for some, but overall, their UI is really refined and carefully designed, as they have some great UI and graphics designers in their premises (everyone knows that I am not a big Apple fan, but I recognize that they have the best UI/gfx designers in the industry).
Red Hat or Gnome2 UI designers should go over all of their applications, developers should listen to their designers and fix their mess, and the Toolkit developers should also listen to UI designers to enable some of the color and fonts changes discussed above. As for the distributions, should employ people to clean up the GTK+ and window manager themes that they are going to use, to something better crafted, and then send these changes back to the theme developers. As for the XFree86 and Freetype people, they should do something together to fix their font interoperability issues, and license or create 2-3 fonts that are looking good, for a change.
And the most important one… What’s the deal with that ugly mosquito (update: now they tell me it is a dragonfly; whatever…) as the default background on Red Hat Limbo (or so I was told)? It is repulsive. If Red Hat wants to be closer to nature (as WindowsXP and Lycoris seem to exhibit a similar urge lately in their background images), it is better to choose something cuddly instead. A big fluffy sheep eating grass in a nice, open field, for example. 😉
Yeah, some will find me funny today, others will find me nasty. What I really am though is very serious.
All it needs is a woman’s touch. 😉
A little care goes a long way. Much improved.
Matt
who likes the new font best of all
That isn’t a mosquito in the last screenshot.
>That isn’t a mosquito in the last screenshot.
Whatever that is…
My husband tells me (he just came back from work) that this is a dragonfly.. whatever.. we don’t have these in Greece. I have seen some of these here in USA, they give me the creeps. Too big for my taste..
Many of these are RedHat problems (background, theme)… the ones that are really intrinsic to GTK/GNOME2, are no worse than KDE. Unlike KDE, at least the GNOME team has UI guys and listens to them. KDE used to do that, but not since versions ~2.2 and on; GNOME didn’t do that before, but since 2 has. Amazing how they’re switching around, KDE becoming the do-everything distro and Gnome following the 20-80 rule. And Gnome’s the better for it.
Of course, this is all irrelevant, as I use ratpoison.
Very important: The background color of the “Font Rendering” child view and the background color of the Tab child view on the Theme panel, is now RGB(226,226,226) while the parent view is RGB(230,230,230). It is hardly noticable, but it really helps creating a real object oriented system, with colors and boldness, making it nice and logical to the user’s eyes
Never thought of OO this way -it was always Car->Engine->piston to me. Actually having a hell of group theory studies in my past life I can keep my OO thoughts clear of illustrations but when I need to explain it to other voices in my head I would crank it with less esoteric schema than RGB triplets.
Your improvements, whilst minimal, give the window such a better “feel” to it. I hope the Gnome programmers respond well to constructive criticism, because simple changes like these do improve the popularity and reception of a UI toolkit by a mile (users don’t care about the code behind it, they care about the look).
Regarding the mosquito and Ximian window manager theme:
Those are definately not the defaults. The default WM theme I believe is called Wonderland like the GTK theme of the same name, which it matches quite beautifully. The default background is the brushed metal that is the default for all GNOME2 desktops.
Erik
Object orientation in the User Interface *is* about this Car->Engine->piston. It is like this:
Parent Window ColorA -> Buttons ColorB -> Any Children Views ColorC. It is just another kind of OO. It is color based depending on its role on the UI… By using different colors, you let the eye understand what belongs where. Borders around buttons are not enough. Colors should also be used. And colors is what the Gnome and GTK+ designers have left out.
I can tell you, since the screen shot Eugenia modified is one grabbed from my system, that everything there IS the default except the Window Border (which was Wonderland by default). That “mosquito” was the desktop wallpaper that came as the default with Limbo, not the brushed metal that was the default in Limbo 1.
As for the quality of the screenshot, please know I built Limbo 2 on an older P3 450 that had a 4MB S3 video card in it. I’ve seen Limbo on better systems, and, if nothing else, the backgrounds are much nicer.
Sorry – but I fail to see the point of the excercise
I just had to look for about 5 minutes to spot the differences (and I had the text)
Doing just one example like that is almost better than doing many. It is astonishing the difference some thought and work make in just this example.
KDE used to do that, but not since versions ~2.2 and on; GNOME didn’t do that before, but since 2 has.
You should really check out the KDE-Usablity mailing list, and tell me that KDE is developer’s centered. GNOME 2 didn’t listen much to the users in the first place, just Sun, Ximian, and Red Hat… perhaps HP.
—
I really like your improvements, the buttons and the radio buttons – they look much more cleaner and professional to me. However, I reall never understood hyperlinks in a window/dialog unless they are suppose to open a web page…
Some people are going to call me a moron for insisting on this, but why on earth do we need to antialias all fonts?
One thing Microsoft has understood perfectly is how to handle fonts. MS-Windows Standard antialiasing setting only antialiases fonts that are bigger than 14-15 and that are not bold nor italic. It is the bigger and/or bold or italic fonts (thicker) that look dreadful when not antialiased. With today’s available (meaning price) screen technology, you cannot get neat/crystal-clear antialiased fonts on sizes smaller than 14-15.
>>
13. Buttons are Arial size 9, and normal text is size 8.
>>
The GNOME2 modified UI is certainly very much improved, very nice fixings, I hope RedHat8 listens. Now, the modified UI would look awesome, very neat, without antialiasing for those small font sizes. Take a look where it says “Window Border”, check out the letter “e” for example, not very clear. Afterwords, look at the screen preferences panel within MS-Windows (I’m looking at my Windows2000) not a single bold font, and none of them antialiased, they are all neat and clean and readable.
After installing Limbo2 I found the RedHat “mosquito” a very cool background, though I admit an insect is not very neutral to different tastes. I think they would do better setting the start up with no background at all, or with a more abstract one, no creatures.
The GNOME GUI is maturing very well, though it isn’t complete, and fonts are still a mess (specially within Mozilla), it looks better and better to me, unlike KDE, the GNOME hackers have done a great graphics job.
> Some people are going to call me a moron for insisting on this, but why on earth do we need to antialias all fonts?
You do not need to antialias a font. This is why Red Hat made this nice panel (as shown in the screenshot) to give you the option to have AA, non-AA, and special support for LCDs. And indeed, AA should only be ON after and before a certain font size, not for all font sizes. I agree on this point.
> Take a look where it says “Window Border”, check out the letter “e” for example, not very clear.
One of the reasons why my AA of Arial sucks in the modified screenshot, is because the mockup was firstly done under Linux with Gimp. Freetype is not the best TTF renderer in this world you know, especially when it is not compiled with its proprierty renderer.
Can anyone explain how to get Gnome2 to recognize new fonts? I’ve installed a plethora of new TT fonts to my system… even xlsfonts sees them, but Gnome2 just won’t list them via gnome-font-properties.
Thanks,
-fp
Does anyone knows any fast mirrors to download Limbo? Somethng close to 20kbps perhaps?
I know you don’t have to antialias a font, I knew of the antialiasing options, I also have chosen withn KDE3 tha antialiasing range. Don’t get me wrong, I like and want antialiasing, I simply would like a default setting that doesn’t antialias *ALL* fonts, only the thick and bigger ones.
I guess you are right regarding the Freetype renderer, ’cause I’m clueless about its possible solution.
I guess you are right regarding the Freetype renderer, ’cause I’m clueless about its possible solution.
How abour Red Hat licensing the renderer?
Growing up in the Balkans, I do remember seeing plenty of dragonflies, especially near canals (flood based and irrigation). We used to call them ‘witches’ (translated). I guess Eugenia is a city girl, not a mountain boy like myself 🙂
Actually, I am a mountain girl. I grew up in a village of 300 people, up in a mountain, 2 hours drive from the closest city. But I have never seen a dragonfly in Greece. 😮
Although I didn’t realise half the mistakes the ideas you suggest seem quite sensible. Excellent article.
Although I like alot of your modifications, the most obvious change to me is that almost unreadably small fonts are now well into the unreadable range. Also the smaller radio buttons don’t look good to me. (This is running in 1600×1200 on a 20″ display)
While I agree with the changing the “Details…” button to “More Settings…” (details seems windows centric, and therefore alien to me), I agree with rajan r that a web link is badly out of place there.
Quite a few of the issues you raised are not UI (IMHO), but skin issues. (Okay, not many, but the rounded corners and the radio buttons.) Also, couldn’t you have changed the default font to Arial in that same prefs window?
That is about all I can pick on about your changes. My only major complaint is the fonts. If I was doing it at my DPI I would have made the fonts larger. Still, I can’t help but wish DEs would choose apropriate font sizes automatically.
That was some nice constructive feedback, too bad that you had to be so negative in your introduction.
The fact that your changes are all minimal tells me that we are on the right track. =) I don’t know what you expect, GNOME2 is a _huge_ step from GNOME1. If you don’t believe me, I ask you to make a review of _this_ one:
http://62.26.209.204/download/Screenshot-Gnomecc.png
😉
About your points:
1.) This is a matter of taste! Your shot looks a lot like BeOS.
I like sharp edges. With this particular theme, rounded edged look indeed good though. For the Gtk default theme, I really really like the sharp edges. Maybe RedHat should consider to implement your idea in their theme. Some Gtk themes have rounded edges and I don’t like them (like Crux, which is very rounded).
2.) Talk about nitpicking.
But a good catch, as all other similar windows _do_ actually align those buttons. I will report that if they don’t know already.
3.) Getting high quality fonts is a _huge_ priority for everyone in the free desktops world. We are lucky that we even get some half-decent fonts like Nimbus. Fonts like Arial are just too damn expensive. Just getting a license doesn’t help, as we need a free font. And to get someone to create a high quality free font will take LOADS of money or someone donating those fonts. I’m sure this will get solved one day but not today or tomorrow and not by just deciding to do so.
Meanwhile, most users will most probably just download Arial like I do…
4.) Maybe it’s just me but… I think it’s fine. Your lines look to small for me, especially with the “W”…
5.) I absolutely don’t agree with the HTML-style because while looking good, this isn’t actually the most usable. The string change could be discussed with the RedHat guys. I don’t have a problem with “Details” though but “More settings” is indeed very nice.
6.) I like their width. Actually with my crazy naming schemes I come pretty close to that.
Better have a little bit too much than too less. Also you don’t know about the “Application” tab, maybe it needs more space. But I really think the width looks pleasing… Maybe it’s because of my large resolution. About the fontsize, this should never be changed as it’s user configurable. Your small font actually looks like… ehm… “flyshit” in 1600×1200. =) Not actually usable.
7.) I like them much better when aligned to the top. Changing the name to “Open theme folder” is a very good idea, I will suggest this to the list. Maybe they had a reason to choose “Go to” though, we will see.
8.) I like them better than your ones.
At least with this fonts. The default Gtk radio buttons are smaller though. So this is most probably a matter of taste… Again.
9.) Hehe… Good catches. Yours is wrong too though.
There is too much spacing for the lower two.
10.) Wow, this one is controversial. I kinda like it though. Not sure how problematic it would be to implement something like this. Buttons wouldn’t be a problem of course, but I’m not sure about childviews… Also, what do you do when rendering a childview in a childview?
Like a group in a tab. I think I wouldn’t change the color for tabs as you don’t really have to visually separate them (there is always only one tab open at a time). As inactive tabs already have a different color, this theoretically should be possible…
11.) The RedHat theme indeed lacks some contrast there, it’s fine with the default Gtk theme though.
12.) Again the font issue… Besides of this, I agree with it. It would be useless though when the user has choosen a bold font anyway (I sometimes do this). You say it’s impossible to do with Gtk? I can hardly imagine that, as the mouse preference panel uses italic fonts.
13.) No way! This would require the user to set different font sizes for all kind of elements. Arghl. Just choosing a smaller size for text is a _very_ bad idea because it would make text basically unreadable for me and choosing a larger size for certain elements would make it look ugly. I choose a font size because I know it looks good and I can read it quite well and I don’t want the toolkit to change the size for anything. Webpages and word processors are the exception of course.
14.) Left justified text might not look as good, but it’s easier to read. All elements are left justified (or right justified for certain countries).
15.) To me, those two inactive tabs look absolutely identical…
16.) As it was already pointed out, this isn’t any default of course.
Neither of RedHat, nor of Metacity.
*goes off writing a mail to gnome-usability*
>almost unreadably small fonts
As I said earlier, this is because of the way Freetype and Gimp rendered by Arial at size 8.
>While I agree with the changing the “Details…” button to “More Settings…”
This is a matter of taste, and how “modern” you want your UI to be.
>not many, but the rounded corners and the radio buttons.
The default Gnome and RedHat theme should change to this roundness. No matter it is get solved by a skin or by GTK+, it does not look good if it is plainly rectangles. It is not 1998 anymore.
>Also, couldn’t you have changed the default font to Arial in that same prefs window?
No, Gnome only picks up some sans serif fonts for its UI, I could never make it to see Verdana or Arial. KDE works fine with Arial or Verdana.
>Your small font actually looks like… ehm… “flyshit” in 1600×1200.
Read my two replies about it. It was not as was intended to be. Gimp and Freetype rendered my Arial badly on the small size.
>10.) Wow, this one is controversial.
I strongly stand by it. It gives a great contrast.
>13.) No way! This would require the user to set different font sizes for all kind of elements.
No. The sizes can be proportional. When someone is choosing size 8 for something, the engine will automatically choose size +1 for the buttons. On Windows you can change all elements btw, and it is really easy to do.
> The fact that your changes are all minimal tells me that we are on the right track.
I do not think so. The changes are minimal to do, but the overall finishing effect, is ENORMOUS. And I did not even talked about the Gnome bar and the menus!!!
“No, Gnome only picks up some sans serif fonts for its UI, I could never make it to see Verdana or Arial.”
Wrong, I’m using Arial. Verdana works flawlessly too.
“This is a matter of taste, and how “modern” you want your UI to be.”
While visual design is all nice and such, usability comes first. As we use buttons for everything clickable, it would make absolutely no sense to mix hyperlinks in.
“Read my two replies about it. It was not as was intended to be. Gimp and Freetype rendered my Arial badly on the small size.”
No, they are hard to read because they are just too fricking small, not because of some bad anti-aliasing. Actually I can read them quite well, I just would never think of using such small fonts, that’s no fun at all.
“No. The sizes can be proportional.”
As I said, I don’t want that. There is a reason why I choose a certain font size. I usually choose quite small fonts that are still convenient to read. I don’t want them smaller nor bigger. Not for buttons or anything. Changing the weight is one thing, but changing the height is a completely different thing.
>Wrong, I’m using Arial. Verdana works flawlessly too.
It never worked for me.
>it would make absolutely no sense to mix hyperlinks in.
Personally, I would prefer the “Help” to be a hyperlink instead of a button in each window, taking so much space… Hyperlinks are new things, I believe that people need to get used to them, I do not think they are wrong form the UI point of view.
Perhaps you or one of the other Gnome2 hackers would be kind enough to explain how you got Arial and the other AA fonts (default ones notwithstanding) to be recognized by Gnome2? As a point of reference, I’ve recently installed a bunch via the “standard” Linux way… xlsfonts recognizes *241* “Microsoft” fonts now, although I still only have the 30-or-so AA default fonts listed in gnome-font-properties. What’s going on here?
TIA,
-fp
> No, they are hard to read because they are just too fricking small
I just compared the “Arial Size 8” to the default WindowsXP file menu size. And I trust Microsoft on their font sizes, as they have a whole team of UI people working on this very issue.
They are identical (except that in XP, the AA is *off*).
It seems that you are driving your monitor way higher than you should use it.
IMO verdana looks much better at 8pt than arial.
I vote the Macromedia MX product line as having one of the best themes I have seen. Microsoft’s Office XP and .Net themes are also not bad.
Yes, you are correct. Verdana renders a bit “bigger”/clearer than Arial on the same size. And it does look better when it is small indeed. Better than Arial.
It might look better if only active tabs had bold text (not all tabs, as you have in your pic).
> It might look better if only active tabs had bold text (not all tabs, as you have in your pic).
We were in fact discussing this with my husband an hour ago. We decided that this would be tricky from UI point of view, because they might seem to some users as “unselectable”, truly inactive, and not just as the “currently not selected tab”.
That you acn’t use those fonts can have several reasons… For me it was a missing line in /etc/X11/XftConfig (had to mention my new font dir there too).
You might get more help at the GNOME support forum:
http://help.gnomedesktop.org/forums/
and maybe this guide can help you (I didn’t read it in detail because I don’t have such problems):
http://help.gnomedesktop.org/forums/viewtopic.php?t=51
Eugenia:
“It seems that you are driving your monitor way higher than you should use it.
”
It’s 1600×1200 and I expect this to be the standard soon.
My point just is that I will choose a font that is as small as possible but still big enough. Because I think that large fonts really look unpleasing. So rendering buttons in a larger font would make them look ugly to me. It would be normal text at size 9 and buttons at size 10. Uargh… I really like having everything at the same size. =)
On the other hand, it is not a bad idea either (I just tried it and it does not look bad at all)… It is just a bit tricky UI-wise, as it is one of the points that _truly_ needs a large team of users/testers to provide feedback on the issue and what they prefer. It is one of the points that you can never be sure what to pick…
I don’t see a reason to change the weight of tabs at all. I can understand it for groups though as they should be easy to spot. But tabs are really special anyway so I don’t see any further usability in bold fonts.
>I don’t see a reason to change the weight of tabs at all.
I believe it looks really nice to have them bolded out, because they are indeed the header of a group, the Tab group.
I live in MN, USA and we have tons of mosquitos(way too many, maybe ship some to you). I’d hate to see a mosquito as big as a dragon fly.
They suck enough blood the way it is.
Anyways, the GUI tweaks you made look good. Hope all the developers out there are paying attention.
“Personally, I would prefer the “Help” to be a hyperlink instead of a button in each window, taking so much space… Hyperlinks are new things, I believe that people need to get used to them, I do not think they are wrong form the UI point of view.”
I agree with its use anytime it is taking you to hyperlinked content, so for help buttons it is probably okay.
“It seems that you are driving your monitor way higher than you should use it.
”
No such thing. =) Any failure by me to be able to read fonts or see icons is the fault of the DE. OS X does (relatively) acceptably on fonts, and better than anything else with icons (almost good enough). Windows (in my limited experience with it) could do better with fonts with its “Large Fonts” option.
In this day and age any DE that asumes a certain DPI (or even range of DPIs) is fundamentaly flawed (yes, that is pretty much the entire flock). I could just as easly be running this monitor in 800×600 as 1600×1200, and a good desktop environment should adjust to run at whatever DPI I want it to.
Also, while I’m at it: It would be nice if OSNews used text size relative for the width of its table, or even just let it grow. 765px wide leaves huge margins for me, even when using Mozilla’s Text Zoom.
> It would be nice if OSNews used text size relative for the width of its table, or even just let it grow. 765px wide leaves huge margins for me
I have talked about it in the past, I really do not want to let OSNews’ tables to autoresize. I have seen weird behaviors from older browsers (eg. NetPositive) when they resize on the fly their tables. At least now, I know they render exactly what I ask them to render. And OSNews should render well even on old, obscure OSes…
Your right, you are a control freak.
Half of your changes I agree with, the other half I don’t. I don’t see the point of going into detail because most of it is a matter of taste.
You really should have looked at the lot of Gtk2 and Metacity themes, taken the best one and reviewed that combo. Do you have any idea how many gtk1 themes there are? Not to mention Sawfish? I’m pretty sure the same is going to happen with Gtk2 and Metacity.
Anyways, go file a bug report. The Gnome2 developers are quite responsive. I make it a point to alwas file a bug report when I have a complaint about something, otherwise I’m just bitching.
>Your right, you are a control freak.
Sure I am. This is because my shot looks better. And I am a web and UI designer by profession. I _have_ to be a control freak.
>Anyways, go file a bug report […] otherwise I’m just bitching.
My point is to write an article that everyone from Gnome, Red Hat, X11, GTK+, Freetype will read and discuss these changes here, not to file a bug report than no one will read. And to whom should I file the bug report? To Gnome? To Red Hat? To GTK+?
This article is about exposing problems in the way things work today in the UI OSS world, not just fixing a couple of visual problems to a random screenshot. I am the editor in this site, and it is my job to write such articles, I am not your random Joe User who will file a bug report and he will shut up.
I did the same for KDE, and the guys were very responsive, and we also had a large discussion afterwards in 2-3 of their mailing lists. I hope that the Gnome guys will also be as open for suggestions.
“OS” News?
Maybe if the desktop is the OS 🙂
the changes make it look very much more eye pleasing except for one thing..
The font selector combo boxes and their labels should NOT be centered. It is very distracting when the left is not aligned. One word starts farther in than the next. It gives the whole dialog a ragged look.. I prefer the original style there.
>”OS” News? Maybe if the desktop is the OS 🙂
The desktop is a VERY important part of a modern OS. And before you become even more lame, read rule No 8 underneath the posting form:
“8. OSNews is not just about operating systems. We are reporting on other technology news, on development issues and articles, hardware, and if are short on news, we might kick in some sci-fi movie news or other stuff we might find cool. This is normal. We do OSNews for fun/hobby, so it has to be fun for us too. Comments like “this article is not OS news” will end you up get flamed.”
And in fact, I am preparing one more UI article.
I was just wondering why those windows can’t be resized. Discussions on how wide a textbox should be to see an x chracter long file name would be moot. Have it grow on resize. Add a scroll bar if necessary…
OTOH, since I’m a more or less BeOS only user, I shouldn’t care less and better I hope OBOS will get it right…
“I was just wondering why those windows can’t be resized.”
Who said that? Of course they can be resized. Only a few windows can’t be resized (where it really makes no sense).
And of course they reflow nicely, add and remove scrollbars, etc.
It is the pretty part of the OS. And without it a lot of people would not use a computer. ;P
How about center the font selectors, but align the left sides of their labels.
Eugenia,
Could you combine the screenshots into one pic.
People would be able to immediately see the differences that way.
Sure I am. This is because my shot looks better. And I am a web and UI designer by profession. I _have_ to be a control freak.
No man.. you need to lose control… I just open up VS.NET and I don’t program anything. After a few hours of quiet meditation I compile. My clients are very happy that I used .NET, through they would have preferred fewer decisions. Design is the same. Embrace nothingness. Let it all go. Relax.
😉
I used to love OSnews. I really did. It was my favourite site.
Unfortunately, Eugenia, you convinced me that you are a complete moron.
Go ahead, remove my post. I don’t care. The only person who has to see it, is you.
How does what a person is determine wether you like a site or not. Granted, Eugenia does a lot with OSNews. Why not just read a few articles and ignore anything you do not like.
Sorry Eugenia, I just had to.
I have not read the rules of engagement, and the
article was pretty interesting.
I find it a bit sad that although open source desktop environment *should* make it possible to exceed the comercial alternatives, they don’t.
Apart from that, I think the desktop hackers are doing a great work on their spare time. No disrespect 🙂
Don’t expect just because it’s open source it will be good… No way, won’t happen. But if everyone works on it, it _is_ possible. People constantly say “this and that isn’t possible with free software” just to be proven wrong a short while later.
Just a few months ago, everyone was just hacking on features. Usability was almost ignored so there arrised a lot of great free applications but most of some had horrible usability.
People said usability wouldn’t be possible without huge budgets and usability teams. They where proven wrong. GNOME took a HUGE step forward in terms of usability. It might not be perfect yet, but it’s definetly very good for a first release, whatever you say. It can only become better from now on.
Visual design is something else, that was practiced by Eazel quite a lot and I guess Ximian is also doing a lot of it, but there isn’t any centralized taskforce yet like there is for usability. I think until now, visual appearance was mostly thought of as artwork and themes (of which we have _excellent_ ones) but not as of button layout, etc. This is another uncovered area where some engagement couldn’t hurt. It would just need a very competent guy (like Seth for usability) to channel and lead all the community input.
I’m pretty sure that we can tackle this one as well. But atm this would most probably be low priority, as functionality and usability should definetly come first.
Excellent change there, making the unselected tabs look recessed. I’d noticed the problem, but not given any time to finding a solution. Thanks for the solution.
There has been a call for semantic labels to make changes like bolding of some text a trivial matter. Right now the only ways to get that are by style markup in strings (done by programmer or translator), style changes by a more cumbersome api (done by programmer), or by meticulous theming (done by noone ;-).
Semantic labels would allow, for example, message text, commands, and captions to be distinguishable by font or color.
The left-aligned labels are a GNOME HIG violation; it calls for right-alignment. I don’t know if it says about where the centerline should fall.
The only point where I notably disagree is for prelight (onMouseOn/onMouseOff as you call it). I don’t think buttons (or web page links) should prelight; their clickability and clickable region should be apparent without jarring last minute changes. Why do you favor them?
Please keep writing great articles and making mockups.
The only changes I’d actually like to see made are 1, 2, 7 & 8, still – but articles like this are great because it *is* the tiny changes, matters of alignment etc that give something a much more professional look.
Some of it looks better, but some of it absolutely terrible.
1) Don’t Capitalise Every Word – It Is Stupid.
Why do people insist on doing this? It annoys me incredibly.
2) Your labels are too small for tired eyes.
Why do people insist on making things small? There’s no point!
The original had a bad font, but using a small font is not an improvement to me.
3) Shrinking the radio buttons?
What does that serve? Yours having a nicer rendering, but again – what’s the facination with small?
4) Web style buttons? Please no!
5) The tinting is good, but I’m not sure you’ve got the balance right (although this monitor isn’t calibrated, so it could be me)
6) Neither version has the Font window done correctly.
In both cases the focus is firmly on the rendering group box, but I don’t believe that to be the most important part of the window.
Probably the rendering, and the font selection sections should both be bordered.
7) I’m really not convinced on the button placement in the themes window.
8) I suspect you’ve made the font popups too small. I have some fonts with quite long names.
9) I like the window border.
While I think that the modified version looks better than the original ones, there are some holy cows you shouldn’t sacrifice for mere eye-candy.
As pointed out by previous posters, the hyper-link is a prime example for this. First of all, blue and underlined only meant hyperlink in the primordial days of the web — and a very bad desicion anyway (blue means background, underlining is typographical heresy). And why a new metaphor when we already have buttons for the “execute action” command? A link that pops up a new window is bad enough on web pages…
About the font issue: Why can’t we honour the fact that fonts come in “point” sizes, not in pixel sizes? So if I specify a 12 point font it should come out at 12/72s of an inch in the real world i.e. on my screen, regardless of whether I’m using 800×600 or 1600×1200? To make this work the dialogs should have sizes heuristics based on the actual size of the type.
And why is there no affirmative button on the “Theme preferences” panel? Or an undo method? I don’t use Gnome2, so I can only guess that the selection I made is automatically applied when I close the window (or even real-time) and to go back to the previous theme (when I decided that I don’t want to change after all) I have to remember its fancy name and select that. What’s wrong with “OK” and “Cancel” or better variatons thereof?
Sigh, I just wish the GNOME (or KDE) people would have decided on a style-guide _before_ running of to code applications that would make a GUI designer cringe.
Sadly we now have two kinds of people working on this: Programmers and Web “Designers”. Rejoice, oh multitudes…
Some inane ideas:
Setting individual fonts to absolute values should be an advanced option. The basic preferences panel should let the user select from a small set of proven combinations and sizes.
The font smoothing preferences (there should be more of them) could as easily swapped out to an advanced panel and/or there could be some kind of “wizard” button that lets the user preview the standard fonts at different sizes with the select settings (smoothing type, smoothing minimum etc.). BTW, Ideally the sub-pixel smoothing shouldn’t be displayed when you haven’t got a LCD connected.
Are those window borders the default? The contrast between the background and the text is abysmally low. At least there’s no maximize button right _next_ to the close button. Although those might appear on windows other than dialogs.
The KDE review was great, this one sucks big time. How man times did YOU have to look at the screenshots to spot the difference? I personally looked at both screen shots THRICE, and I still don’t see the difference (I’m using an ‘average’ AMD 450 machine, with an ATI ALL in wonder card. Do I need the latest Nvidia card to spot the difference?).
I’m sure I will see the nice differencies if I looked a little bit more closely and carefully, or after I know what to look for. But that is the point precisely!
Unless you are a design geek, the differences are not immediately obvious, and definitely not the sort that would make a difference one way or the other for Joe user, who doesn’t exactly care about absolute perfection in the very last pixel. That’s why somebody had to ask:
> Could you combine the screenshots into one pic.
> People would be able to immediately see the differences > that way
Linux desktops need a lot of improvements, most notably in terms of speed and the way things are arranged. Limbo 2 is definitely a great improvement in the later category. I appreciate the effort, but critiquing a desktop from just one screenshot is really kinda tough, to say the least. Eugenia is an OS junkie, and if she hasn’t already done so, I encourage her to install the new Limbo. That way, you are more likely to get a better appreication about what Redhat has done so far and they are going. I bait your UI review will be both more sensible and more useful to Redhat if you looked at the full picture.
“And why is there no affirmative button on the “Theme preferences” panel? Or an undo method? I don’t use Gnome2, so I can only guess that the selection I made is automatically applied when I close the window (or even real-time) and to go back to the previous theme (when I decided that I don’t want to change after all) I have to remember its fancy name and select that. What’s wrong with “OK” and “Cancel” or better variatons thereof?”
Because auto-apply is a _lot_ more convenient. I don’t think that anyone will ever have a problem remembering the name of the theme he liked. =) And if he does, he can simply try all of them again. As it’s auto apply, this really just takes a few clicks. And there is always the “Default” theme if you are lost (however this could happen).
“Sadly we now have two kinds of people working on this: Programmers and Web “Designers”.”
What do you mean? Those people working on the style-guide (which is close to be finished) are neither programmers nor web designers (maybe some are, dunno).
“Setting individual fonts to absolute values should be an advanced option. The basic preferences panel should let the user select from a small set of proven combinations and sizes.”
The font dialog is mostly to change the font, not the size. That’s just a detail of it.
“The font smoothing preferences (there should be more of them) could as easily swapped out to an advanced panel and/or there could be some kind of “wizard” button that lets the user preview the standard fonts at different sizes with the select settings (smoothing type, smoothing minimum etc.). BTW, Ideally the sub-pixel smoothing shouldn’t be displayed when you haven’t got a LCD connected.”
What’s wrong with the RedHat setup? It seems simply and easy to understand. Don’t make simple things to bloated.
That won’t help. BTW, the font dialog is really new to RedHat. The one from GNOME 2.0 looks like this:
http://62.26.209.204/download/Screenshot-Gnome-font-properties.png
“Are those window borders the default?”
No no, absolutely not. Metacity isn’t even finished, neither is it GNOME default (but will be in 2.2), so isn’t even a real default border yet (there is one but it’s very simple). RedHat’s default seems to be Wonderlond which looks quite nice:
http://www.getlinuxonline.com/Downloads/limboscreens/Screenshot-3.p…
“At least there’s no maximize button right _next_ to the close button. Although those might appear on windows other than dialogs.”
Indeed there is… The buttons are placed just like in Windows. Minimize, then maximize, then close. Right besides each other. :/ Personally I don’t have a problem with this as both buttons are pretty useless to me (which sucks even more somehow… hm…). I read that there was some discussion about this where Havoc probably was pro this setup but unfortunatly I never read it and don’t know where to find it. :/ There is no Metacity mailinglist AFAIK so it could be everywhere.
“No, they are hard to read because they are just too fricking small, not because of some bad anti-aliasing. Actually I can read
them quite well, I just would never think of using such small fonts,
that’s no fun at all.
”
They may be too small on your screen but they are perfectly readable
here. You are using an unusually high resolution.
Obviously the size has to be settable by the user. What’s wrong with
the original is the bad (or no) kerning in the Nimbus font, and the
choice of the same size for everything.
I found this chapter in the GNOME styleguide:
http://developer.gnome.org/projects/gup/hig/draft_hig/layout.html#t…
According to this the current placement is definetly right and it shouldn’t be changed just to make it look better (read the row about “Other component labels (e.g., spin boxes, text fields)”, it definetly reads “left aligned”).
Gnome 1.4 had xalf which changed the cursor when a app was loading, in gnome 2 you have no freaking Idea if the app is loading or not, you might notice the hard drive spinning when loading mozilla, but that is not a good way to visible see if a program is loading.
Gnome 2 has a long way to go to be in the same class as KDE 3
Unfortunately, this is what happens when people design for asthetics but leave usability out. While Eugenia’s screenshot does look much nicer, and most of her changes are benign, a few are Very Bad(tm) for usability.
First, right-aligning the combo-box labels is a bad idea, at least in English. The most signifigant word is the leading word, found on the left. When labels are aligned by this word, they are very easy to scan–a simple, vertical motion. When they are not aligned (when the whole label is right-aligned) scanning the list becomes much more difficult, and involves moving the eyes in a zig-zag pattern. This pattern is much less efficient and more tiring.
Second, while changing the text of “Details” to “More Settings” is a good idea, giving a command button the HTML treatment is another bad idea. GUIs are about consistency and learnability. A command button has very defined semanatics, and will always look the same. A link has neither of those attributes going for it. Will clicking it open a web browser? A new email? Spawn pop-up windows? If the intent is to make the UI look like a web page, it is a very misguided one. Besides the limitations inherent in HTML interfaces, the user has a whole new, inconsistent set of rules to apply. Suddenly, the user has to mouse-over graphics in the interface because, hey, if web-pages use graphics as links, maybe I can click them here…
“They may be too small on your screen but they are perfectly readable
here. You are using an unusually high resolution.
Obviously the size has to be settable by the user. What’s wrong with
the original is the bad (or no) kerning in the Nimbus font, and the
choice of the same size for everything.”
But that’s the point, when there are different font sizes, there is no way to make sure that my fonts are always well readable. That’s why i think that fonts should always be the same size. This is also covered in the HIG btw:
“To a user with normal vision, textual output provides the majority of the information and feedback in most applications. To a visually-impaired user who may not be able to see or understand any additional graphical output, clear textual output is critical. it is therefore essential that you choose and position text carefully on the screen, and leave the choice of fonts and sizes to the user, to ensure that all users are able to use your application effectively.”
Usability isn’t something we should break for eyecandy.
“I have talked about it in the past, I really do not want to let OSNews’ tables to autoresize. I have seen weird behaviors from
older browsers (eg. NetPositive) when they resize on the fly their tables. At least now, I know they render exactly what I ask
them to render. And OSNews should render well even on old, obscure
OSes…”
Which it does on this Amiga browser with JS disabled. Please don’t
change it.
“As pointed out by previous posters, the hyper-link is a prime example for this. First of all, blue and underlined only meant
hyperlink in the primordial days of the web — and a very bad desicion anyway (blue means background, underlining is
typographical heresy). And why a new metaphor when we already have buttons for the “execute action” command? A link
that pops up a new window is bad enough on web pages… ”
Hyperlinks shown by underlining are just a cheap hack to replace
proper buttons. Underlining is typographically ugly (especially the
horrible underlining of one letter in a word). In a graphical
requester window, buttons should be shown as buttons. They do not need
“rollovers” to make it obvious that they are buttons.
Anyone can understand and respond to a button with a word (or two) on
it.
“But that’s the point, when there are different font sizes, there is no way to make sure that my fonts are always well
readable. That’s why I think that fonts should always be the same
size. ”
Yes there is. You set all the options to the same size. No problem.
I certainly wouldn’t want all the fonts in an interface to be the same
size, but if you do, you can set them thus.
“The KDE review was great, this one sucks big time. How man times did YOU have to look at the screenshots to spot the
difference? I personally looked at both screen shots THRICE, and I
still don’t see the difference”
I opened the images in two windows side by side, and to me the
improvement was blindingly obvious. It’s the difference between
totally amateur and professional.
I’m pleased that Eugenia is addressing these issues. Windows is ugly
enough, why does Linus have to be even worse?
I’d have to say that is one of the sharpest looking UI edits I’ve seen. It actually reminded me a lot of BeOS, which had a pretty sharp UI. Good job Eugenia!
“Because auto-apply is a _lot_ more convenient. I don’t think that anyone will ever have a problem remembering the name of the theme he liked. =) And if he does, he can simply try all of them again. As it’s auto apply, this really just takes a few clicks. And there is always the “Default” theme if you are lost (however this could happen).”
I really don’t see the convenience. You don’t save anything, whether the user pushes “Close” or “Use this theme” doesn’t matter at all. And it breaks a fundamental widget metaphor. Lists are used to _select_ things, buttons to execute _actions_. This is the same league as javascripted comboboxes on web pages…
On the other hand, if you have any pointers to reasearch in this area which says otherwise, please send me some links.
And BTW, forgetting the name of the theme is an issue when you’ve got 20+ themes, all with ridiculous names. And I assume the auto-apply style will be used by other dialogs where this might be even more obscure.
“What’s wrong with the RedHat setup? It seems simply and easy to understand. Don’t make simple things to bloated.
That won’t help. BTW, the font dialog is really new to RedHat. The one from GNOME 2.0 looks like this”
Yuck, that’s even worse.
For a standard font selection dialog, the RedHat version isn’t that bad. But its too technical, i.e. tied to what actually happens on the GUI level instead of what the user probably wants. Which is probably the most common problem in user interface design…
Probably the most common productive use of this panel would be to adjust the readability of the display, because either the type of the font or its size doesn’t suit the user. But it forces to fine-tune everything by hand. Okay, it’s just a few combo-boxes, but that’s still too much micro-management.
There’s no way to just increase the size of all the fonts at once, which would be highly useful. If the user has lots of fonts, he could spend a large amount of time just selecting them. By having a small group of “recommended selections” most casual users would easily be satisfied. The anal-retentive ones can use the advanced panel…
Well, speaking of anal, of course my little diatribe sounds quite overblown. But the devil is in the details and preference panels are always a good judging point for GUIs. Just take a look at the early Mac or Win (3.1) dialogs where _everything_ is in little window (granted, they didn’t have that much options back then).
Those dialogs aren’t worse than those of Windows, but striving to just be the leser evil isn’t a very noble goal, is it?
“I really don’t see the convenience. You don’t save anything, whether the user pushes “Close” or “Use this theme” doesn’t matter at all. And it breaks a fundamental widget metaphor. Lists are used to _select_ things, buttons to execute _actions_. This is the same league as javascripted comboboxes on web pages…
On the other hand, if you have any pointers to reasearch in this area which says otherwise, please send me some links.”
Users don’t care about “widget metaphors” (whatever that is
) but about reallife metaphors. And in reallife, you change a setting of a device or machine and it will take affect immidiatly. No fluff.
If you don’t see the convenience of just setting a preference and immidiatly seeing the effect, I don’t know… Please just try it yourself.
You can probably imagine that this was discussed already a few thousand times and trying to convince someone that it doesn’t suck with words is pretty tiresome, if he could just see for himself. 
BTW, most modern JS sites I know make changes to a combobox immidiatly active. For example you choose a page where you want to go and it immidiatly transfers you there, no need to press “go”. This is even more drastic but still people seem to prefer it. Pressing a button after every little change is just awfull and serves no real purpose. If you are crazy about a revert button, than it can be added, that has nothing to do with auto-apply. But believe me, you won’t need a revert button for themes… If you install 30+ themes, you are probably a freak who has no problem finding the theme he wants to use.
“Yuck, that’s even worse.
For a standard font selection dialog, the RedHat version isn’t that bad. But its too technical, i.e. tied to what actually happens on the GUI level instead of what the user probably wants. Which is probably the most common problem in user interface design…”
The GNOME usability guys are no amateurs… Understanding this issue is one thing, provoding solutions is another thing.
Not everything is immidiatly technical possible.
“There’s no way to just increase the size of all the fonts at once, which would be highly useful. If the user has lots of fonts, he could spend a large amount of time just selecting them. By having a small group of “recommended selections” most casual users would easily be satisfied. The anal-retentive ones can use the advanced panel…”
“Advanced” panels is something that they want to avoid… It is pretty ambigous. Atm there are only two fonts in the font preference panel so you probably understand that things like “change all sizes at once” didn’t make sense.
I agree that this should be very simple. This is also the reason why I’m _against_ several sizes in a GUI because all of them would have to be configurable (as Don Cox suggests to solve my problem) and this would again clutter this dialog.
Maybe to make this dialog simpler the font selections could only contain fonts, not sizes and there could be an additional “size” option that lets you choose between several “base” sizes? Like “large (1600×1200)”, “small (800×600)”, etc. This could even default to something that depends on the current screen resolution. One option could be “custom” which adds a size control to every font option.
What do you think?
“Those dialogs aren’t worse than those of Windows, but striving to just be the leser evil isn’t a very noble goal, is it?
”
You can be assured that GNOME usability is very motivated to be no evil at all and they don’t care for what Windows and Mac do.
Although Mac usually isn’t quite that bad.
Michael, I’ve made a link for you: http://makeashorterlink.com/?L26D13571
There’s a lot that has been said on the instant-apply issue. When you’ve read it all, let me know if your opinion is still the same.
“Users don’t care about “widget metaphors” (whatever that is
) but about reallife metaphors. And in reallife, you change a setting of a device or machine and it will take affect immidiatly. No fluff.”
Most machines I use don’t have lists. I’m not talking about volume knobs or sliders. And imitating real life has its limits, as shown by all those fluffy media players. Or the prime example: the steering wheel. We don’t use reins in cars. Okay, never been to Iowa…
Still, if consistently applied I could live with that. So every list has instant-apply and deferred apply would be handled with radio buttons or something similar.
(I have to see those instant-apply file selection dialogs, he thought sarcastically…)
A small Undow button would just be icing on the cake…
”
The GNOME usability guys are no amateurs… Understanding this issue is one thing, provoding solutions is another thing.
Not everything is immidiatly technical possible.”
Hey, I’m not throwing stones at anyone. But my guess is that this is a deliberate choice and not just the lack of manpower. User interfaces are pretty technical nowadays, not task-oriented.
“I agree that this should be very simple. This is also the reason why I’m _against_ several sizes in a GUI because all of them would have to be configurable (as Don Cox suggests to solve my problem) and this would again clutter this dialog.”
Hmm, don’t think this would work. Window titles should be bigger than the normal text. And proportional and monospaced fonts often don’t work well together at the same sizes.
So just setting everything at the same size would not be a good solution. Either a preselection of different choices (“Arial + Courier, small”, “Verdana+Lucida Typewriter, big”) or a “Make fonts bigger” button.
It would be interesting to know what kind of scenarios apply to this dialog. I don’t think that many users (especially novice ones) don’t like a particular typeface and want to change that. Exceptions occur, e.g. someone who _really_ likes serif or just wants to disable the ugly gaudy font used by the theme for window titles.
The problem with open-source usability is that most programmers spend so much time in front of a computer that they develop their own detailed preferences and like to apply those as fast as possible, where most novice and intermediate users just don’t care whether they use Arial Narrow 12 or Verdana 13…
To get away from such small details, one point I really liked about the “improved” version was the placement of the select box labels, i.e. right-aligned. Much more whitespace around the controls.
Spark wrote:
> 15.) To me, those two inactive tabs look absolutely
> identical…
Za! I think Eugenia’s recessed tab is a huge improvement.
Nice reading, thanks.
I’m not quite sure. My main gripe is consistency, as long as they stick to one certain style _all_ the time I don’t particularly care. Auto-apply has some deficits when it comes to reverting, but maybe that causes some new metaphors apart from the old “Cancel”, which would be better anyway.
I think Jef Raskin demanded that every action in a GUI should be easily to undo. It would be nice if that would be possible. I’ve yet to see a desktop-wide undo facility…
Could the woman PLEASE use a spellchecker?
Please? I feel like I’m reading the rant of an illiterate idiot. No matter how interesting what she says may be, she comes off like a whiny complainer who can’t spell.
I missed the web link style bit. I disagree with that too.
The GNOME HIG has changed – recently, I think. There had been discussion of label alignment concluding with right-aligned labels. Now, without any notice I can find, it has been changed. That royally sucks! (I’m trying to find out when and why this happened.)
Regarding the buttons in the windows: Close isn’t supposed to be there; it was a concession for which I quit the HIG. An Undo button is supposed to be there; “It’s too hard to do (now),” is the reason why it isn’t. A Defaults button should be there too; same reason.
Regarding the buttons on the window frame: I’ve written about that enough elsewhere. I recommend setting up FVWM instead of the GNOME default. It has an active maintainer and is the most standards compliant window manager I’ve found. But I’ve not yet moved to it myself; a good theme builder and configuration tool for it would be great.
“Hmm, don’t think this would work. Window titles should be bigger than the normal text. And proportional and monospaced fonts often don’t work well together at the same sizes.”
That’s not what I meant.
It meant it like this:
First one option menu that let’s you choose between predefined sizes or custom:
Font size: [ Small | Normal | Large | Custom ]
then the certain fonts like
Standard application font: [ select ]
Desktop font: [ select ]
Windowborder font: [ select ]
etc.
When setting the font size to small, normal or large, the font size of all fonts should be adjusted automatically. For example “small” could set “8” for standard application font, “9” for desktop font and windowboarder font, etc.
If one of them is selected, of course the font select box shouldn’t include a font-specific size setting. When “custom” is selected, this size setting would appear so those who don’t like the defaults could adjust every single font size (like it’s the default right now).
Maybe this two quick mockups make more clear what I mean:
This is what it would look when choosing the “small” font size, providing some reasonable defaults for all fonts:
http://server204.serverflex.de/download/font-dialog/small.png
And the “custom” selection would allow to set the size of every font manually:
http://server204.serverflex.de/download/font-dialog/custom.png
I don’t know… The point sizes appearing right out of the blue seems a little bit hackish. What about having those fields grayed out and the point sizes change according to the Small/Medium/Large box. And “Custom” wouldn’t be part of this menu, but two radio buttons, one in front of the “Font size” box, and one in front of the font selection boxes. Once you clicked on “Custom”, of course they wouldn’t be disabled anymore.
If it’s just small/medium/large, a radio group would be better.
This gets kinda cluttered, so the font smoothing and font selection should probably end up on separate tab panes.
The novice user just clicks “Large” if he can’t read clearly, while the discriminate user just selects anything by itself. Combinations would occur, e.g. activating “Large”, then switching to “Custom” and further increasing the window title size.
BTW, there’s auto-apply for this, too, isn’t it?
“The point sizes appearing right out of the blue seems a little bit hackish. What about having those fields grayed out and the point sizes change according to the Small/Medium/Large box.”
That would probably be the best solution… Not sure if it’s possible though (one part of the button grayed, the other not grayed) but it should be.
“And “Custom” wouldn’t be part of this menu, but two radio buttons, one in front of the “Font size” box, and one in front of the font selection boxes. Once you clicked on “Custom”, of course they wouldn’t be disabled anymore.”
I don’t really understand this. How can “Custom” be two radio buttons?
“If it’s just small/medium/large, a radio group would be better.”
Yes, I thought about this… Not sure… It would move the font selection quite a bit down and would eventually make it less comfortable than more in the end. It’s not something that will (or should) be changed all the time so I liked the idea to have it into one single options menu better. Also you get some slight problems with layout when you place a radio group there. Of course that shouldn’t be a real obstacle.
“This gets kinda cluttered, so the font smoothing and font selection should probably end up on separate tab panes.”
Indeed, I thought of that too. But maybe this wouldn’t even neccessary when using an options menu (the HIG actually allows/suggests to use option menus for a few items if space is limited).
“The novice user just clicks “Large” if he can’t read clearly, while the discriminate user just selects anything by itself. Combinations would occur, e.g. activating “Large”, then switching to “Custom” and further increasing the window title size.”
Yep, the should be possible… Hm… Maybe it would be better not to gray out anything? So you could for example choose “large”, then you would change the fontsize of the windowtitle and it would automatically jump to “custom”. When you select “small” then it would reset all fontsizes to the small default again.
“BTW, there’s auto-apply for this, too, isn’t it?”
Yes.
The argument that “You can just select your previous theme if you don’t like the new one” is missing one vital point – once you’ve set foreground, background, everything, to black (or blue, or red, or whatever) you can no longer see the UI to change back.
When MSWindows changes the screen resolution, it reverts back to the previous setting if you haven’t clicked “Yes” within 15 seconds, to avoid a similar problem.
An automatic preview with timeout, and a Cancel button for “I’ve had a look at the other themes, and have decided to let sleeping dogs lie” should address everyone’s concerns, no?
I am amazed that you can read anything at 1600×1200 on a 20″ screen. I have a 19″ monitor, which is pretty good, but I can’t use anything above the 1100something resolution (the one between 1024×768 and 1280×1024). This is on a CRT display.
On my laptop I use 1400×1050 on a 15″ screen. This is a whole different world. Everything is crisp and clean unlike on the CRT monitor.
Instant-apply seems to be not the right thing, in my opinion. Most dialog boxes offer options for more than just one setting. Usually I like to play around, selecting options for several settings and then apply them at once. There is also a problem between dialog boxes that have instant-apply and those that don’t. Take the screen resolution panel for example. You have to restart X in order to get any effect. This is far from instant-apply and breaks consistency. Also, the nice thing about the Apply button is that it is usually greyed out if nothing has been changed. Sometimes I get distracted and do something else and come back to the dialog later. If I see I didn’t change anything it is safe to just close the dialog. With instant-apply I don’t have that kind of feedback.
Most of the changes in the screenshots are very nice. I am not so sure about the hyperlink, but this is a matter of taste.
What Eugenia did was work in a very detailed way on one page/aspect and it made a huge difference. Some things could be argued – hyperlinks, etc. But let’s not get lost in the details. It is the overall effect for the end user that counts, the user who is not looking for these details, but benefits from them, even if they don’t realize it. The big thing, as Eugenia pointed out from the beginning, is that this was just one little thing compared to the totality of the interface. It is obvious that the entire UI can be improved dramatically, should be improved dramatically.
“I am amazed that you can read anything at 1600×1200 on a 20″ screen. I have a 19″ monitor, which is pretty good, but I can’t use anything above the 1100something resolution (the one between 1024×768 and 1280×1024). This is on a CRT display.”
I also have a 19″ and 1600×1200 works fine. I can read every font, although the 8pt font that Eugenia used is pretty much on the edge.
If auto-apply or not is the right thing or not is a mood point. It’s discussed to death, it’s the default now and it will stay, if you like it or not. Most people like it (who actually try it). Once you get used to it you will feel that manually applying changes is a thing of the stoneage.
Not-autoapply dialogs like screen resolution don’t break consitency at all. There are some things that are still not auto-apply (basically everything that makes no sense or is dangerous to auto-apply) and there is no problem with usability.
I liked the dragonfly. Creepy? Sorta. Beautiful? Definitely.
By the way — it’s a BUG. Which is what I assume to be the idea behind it this buggy beta verison.
Pretty cool, IMHO.
Maybe a little off-topic,
But I just can’t get myself to use ClearType (Windows) or anti-aliased (Linux) fonts because I get a headacke after half an hour. Is it me or does everybody else think AA fonts are blurry? Even in the screenshots they look blury.
You may think it’s my monitor, but I have an 18″ Samsung LCD with 0.26 dot pitch and 500:1 contrast ratio. I just think AA fonts are useless.
On the other hand, I find fonts whose rough edges have been smoothened much better on the eyes.
My $0.02 CDN
Man … look at the size of those icons on the KDE “taskbar”. (yes I kno they can be changed)
“I don’t really understand this. How can “Custom” be two radio buttons?”
You’ve got two groups, one with the font size combo box or radio group, one with the font selection boxes. Each group is preceded by a radio button, so only one box is active.
You don’t need to gray it out, but there’s got to be an indicator whether the custom mode is on.
Well, personally I prefer crisp fonts on a high resolution desktop. Serifed fonts only printed (and then at least 600 dpi). The FreeType AA is pretty bad, IMHO. But if even the quite subtle ClearType bugs you…
I recently came upon a study about the readability of on-screen fonts. The researcher came to the conclusion that both for speed and understanding a printout still can’t be beaten, and that 8-bit antia-aliased clearly beats 1-bit monochrome font display. Surprisingly, both Georgia and Verdana (Microsofts fonts designed specifically for on-screen readability) were on par with the traditional Arial and Times. (1280×1024, 12 pt)
If only there’d be a good distinctive free “system font” for Linux desktops. Nimbus looks quite rough, IMHO. Reminds me of the free Ghostscript fonts…
As I was reading Eugenia’s changes, I had to think that perhaps developing a content/style/layout engine similar to what is used for HTML content would work for UI components. Not that I’m suggesting that pure HTML would work for UI, but if one could develop styles that layout automatically and cleanly, with layout separate from content, then every dialog box would not have to be manually created, eliminating many of the inconsistencies she found. Additionally, it could aid in internationalization, etc.
Just a thought, and a first one at that.
-todd
Linux is whatever you and other programmers want it to be
And that’s the problem. Linux is whatever linux programmers want it to be. Which is really great, if your target market is linux programmers.
I talked almost two years ago with a red hat developer who worked on RedHat’s Anaconda installer. I mentioned a few usability problems that had bothered me (stuff that would confuse end users into not booting into X, modal dialogs that blocked crucial information, etc) and his response was “you don’t think it’s pretty enough?”. To be fair, Mandrake also has the same wrong idea with their installer, as seen by all the ambiguous star-shaped widgets they use (in an attempt to make it “pretty”). While redhat uses less ambiguous widgets than mandrake, they are no less guilty of making stuff confusing because they lay out their unambiguous widgets in extremely ambiguous ways. If you look here (yes, I know it’s 7.3 and not limbo, but red hat has a habit of being backwards-compatible with their usability problems)
http://www.redhat.com/software/linux/screenshots/installer-installc…
Notice they use some sort of “hierarchical radio buttons” where the gap between the “Install” and “Upgrade Existing System” is the size of a small asian country. Radio buttons are effective because they group choices together (making use of a psychological principle called “chunking”), but they start to lose their effectiveness if they are spaced too far apart. Radio buttons also are not appropriate for conveying hierarchy. While Microsoft is orders of magnitude incompetant at designing user interfaces, not even they would create something this bad. What’s worse, we see this kind of design quite often in many pieces of free software. What’s even worse than that is that many people in the linux community seem to not notice these problems because they are able to use their prior linux expertise to get around the most confusing and ambiguous parts of the installer. And some of them testify that linux is perfectly ready for the desktop.
Guess what happens if some poor schmuck hears that linux is a usable alternative to windows and then hits these confusing areas of the installer’s interface? He writes off linux as “an operating system written by nerds for nerds.” A badly designed linux UI is more deadly than Microsoft’s best FUD.
Hey Joe, maybe she’ll get a spell checker when you start writing articles in her native language, Greek <g>.
Most toolkits since Motif have advanced layout managers where you don’t have to hardcode the actual sizes, so different screen resulutions should pose no big problem.
I don’t think more than that is possible. As you can see from the debates in this thread even minor issues are important. So you just can’t say “I want 5 boxes in this dialog, make it so!” and let the software heuristically lay them out in a pleasing manner.
Where did you get the idea that HTML has good layout management? It requires an insane amount of hand-holding and micro-management in three different pseudo-languages (HTML, CSS, Javascript) to arrive at anything semi-productive.
No, what you want is a good, readable style-guide, similar to the ones MacOS had.
Put the fonts in /usr/X11R6/lib/X11/fonts/TTF and change
<dir>/usr/X11R6/lib/X11/fonts/Type1</dir>
<dir>/usr/share/fonts</dir>
to
<dir>/usr/X11R6/lib/X11/fonts/Type1</dir>
<dir>/usr/share/fonts</dir>
<dir>/usr/X11R6/lib/X11/fonts/TTF</dir>
at the top of /etc/fonts/fonts.conf
You can replace /usr/X11R6/lib/X11/fonts/TTF with other directories if you like.
OK, it’s new. But GNOME2 is attemption to have fonts display at the correce size.
Now a point is 1/72 inch. So an 18pt font should be 1/4″ tall. Regardless of the screen resolution. The old X11 default of 72dpi is gone. X asks the monitor what the resolution is. If the monitor is wrong, you can override the setting.
It threw me the first time. The fonts looked huge. That’s because it realized that I had 96dpi monitor, and was using a 1280×1024 display. So it drew an 14pt font 14/72″ (0.19″) tall, instead of the old way, which was 14 pixels, or 0.146″ tall on my monitor.
A 12pt font is 12pt tall, weather the screen is 640×480 or 1600×1200. Imaging if a 12pt font printedon a printer changed size, when you changed the resolution of the printer. 720dpi to 1440dpi, to pick Epson resolutions, would halve the height of the printed letter.
The screen shot is probably blurry, because it was made at a low resolution or you not displaying it at the correct size. Measure the height of the font. Is it displaying at 8pt height?
The glaring thing that any good usability person will immediately see about the font dialog is that layout of the radio buttons is simply so bad, confusing, and ambiguous they’d swear the interface was designed either as a joke or an example of how not to use radio buttons (see my previous post for another example). For radio buttons to be successful, radio buttons must be
1. Clustered closely together (exploits psychological principle of “chunking”)
2. Aligned some discernable sequence, preferably vertical, as the brain will use parallel processing for two adjacent columns of like visual information (i.e. column of button icons beside column of text), which adds greater speed and organization to the process of decision-making. Horizontal alignment, while taking up less vertical space, has the undesirable trait of requiring the user to sequentially process alternating pictoral and textual elements (all on a single line). Horizontal alignment leads to a slow, disorganized mess that makes the processing of decision-making a greater hassle.
The layout of the radio buttons in this font dialog neither clusters the choices together nor puts them in a sequential order. Why they even used radio buttons is beyond me.
Also the “Help” button’s icon stands out as a problem area. Or rather, the problem is that it doesn’t stand out. There is a population stereotype that two overlapping red rectangles (aka ‘Red Cross’)means “help”, “aid”, “assistance”, etc. This would be highly preferabe to the striped “doughnut” that keeps people guessing.
That the GNOME usability project (assuming they looked this design over. My apologies if they haven’t) didn’t catch these awful designs within 5 seconds of looking at them speaks volumes about why linux has been having so many terrible usability problems and why a macintosh from 1984 is still more usable than tomorrow night’s build of GNOME or KDE.