| |||||||||||||
Unity, design coherency and Alt-F2Unity, design coherency and Alt-F2Posted Feb 15, 2011 20:01 UTC (Tue) by oak (subscriber, #2786)In reply to: Unity, design coherency and Alt-F2 by Frej Parent article: First look at Ubuntu "Natty" and the state of Unity
> Pixel waste
White space can make the layout more balanced and pleasing to the eye. If you remove too much of it, UI becomes too busy & cluttered.
(Although I've used KDE for over a decade, IMHO Gtk apps have typically looked better than KDE apps and I think it was because of more balanced use of white space.)
(Log in to post comments)
Whitespace and pixel-fixing Posted Feb 17, 2011 7:08 UTC (Thu) by sladen (subscriber, #27402) [Link]
Whitespace is hugely important, it frames the content and provides the cadence. It needs to be there.
At the same time, any specification (GNOME HIG) based upon repeated hard-coding of specific pixel-counts is flawed in an age of infinitely scalable vector graphics and 150300 DPI screens!
Whitespace and pixel-fixing Posted Feb 17, 2011 10:10 UTC (Thu) by Frej (subscriber, #4165) [Link]
I agree whitespace is hugely important, i've actually bought and read Tufte's books ;). I was specific about gtktreeview for a reason. Framing content with whitespace is a tradeoff.
Remember, not all widgets are equal. Pixel waste when showing a settings dialog is rarely important, you want clarity and the minimum number of choices possible. Whitespace here has almost zero cost.
It's not illegal to use 'ink' to frame content if it results in a better ratio of information. Scrolling/sliding windows are a special case because a smaller row hight allows you to present more data, without scrolling.
Also about the HIG.
I don't see laptop screens changing DPI soon (ie 250+). The work is just too high. Even the traces of resolution independence in OS X 10.6 were lower than in 10.5 (arstechnica). Of course if somebody invents the dual mode DPI screen as way to go forward we might get there. It is different for phones, new platform no legacy and all that. But high DPI would certainly be nice.
I don't believe in porting the same app from desktop to android/iphone without changing the layout anyway.
Lastly. davidz has actually tried to get a resolution independent GTK (although his works dates back to 2008, and danni did pick up the branch, but it seems dead). That's the actual hard work. Not changing the HIG - it just represents what's possible. Cairo was also required work, and was required work before gtk could be changed sensibly.
But i sense this is 1) getting off topic 2) Nitpicking on gtk.
Whitespace and pixel-fixing Posted Feb 18, 2011 16:29 UTC (Fri) by droundy (subscriber, #4559) [Link] Remember, not all widgets are equal. Pixel waste when showing a settings dialog is rarely important, you want clarity and the minimum number of choices possible. Whitespace here has almost zero cost.I strongly disagree, in the common case that setup dialogs do not have scroll bars and the ability to be resized to fit the screen. I don't care to count the number of times that I couldn't hit "apply" because I couldn't see the bottom of the screen. And in worse cases, you also can't see some of the actual settings. (examples: google chrome, firefox, epiphany and empathy all have settings dialogs that either have a fixed minimum size or can be resized to be smaller, but then the content isn't visible.) Of course, the proper solution is to make all dialog boxes resizeable with reasonable behavior (i.e. scrollbars) when they are smaller than their content.
Whitespace and pixel-fixing Posted Feb 23, 2011 19:59 UTC (Wed) by mrshiny (subscriber, #4266) [Link]
I second this. I have an HTPC running on an older TV and so the resolution is 1024x768. However the fonts aren't readable (because it's a TV) so I have to make them bigger. This makes MANY dialogs taller than the screen and makes the controls go off the end where they cannot be reached. And since it's a TV I don't always have a keyboard so I can't hit ENTER.
Unlike fonts, Whitespace not easily user adjustible. Posted Mar 11, 2011 14:35 UTC (Fri) by gmatht (guest, #58961) [Link]
And I find it particularly that shrinking fonts to fit dialogs onto a 1024x600 netbook screen has little effect. Shrinking my fonts down from 12 pixels to an almost unreadable 6 pixels doesn't even come close to halving the size of the dialogs because it does nothing about the vast seas of white space that surround each line of text.
It is kind of silly that I upgraded my netbook to one with 768 pixels, not some much because my eyes can tell the difference on a 10" screen, but because it allows me to shrink the otherwise unshrinkable whitespace. I did a mockup [1] demonstrating that it should be possible to have usable buttons (etc) in as little as 11 vertical pixels including white space. If had the option of shrinking dialogs down that small even the 480 pixel screen on the original Eeepc would start being usable for most applications.
Whitespace and pixel-fixing Posted Feb 28, 2011 2:58 UTC (Mon) by JamesOnTheWay (guest, #73205) [Link] sladen writes, “Whitespace is hugely important, it frames the content and provides the cadence. It needs to be there.At the same time, any specification (GNOME HIG) based upon repeated hard-coding of specific pixel-counts is flawed.” I sincerely agree. Therefore, users must be given the ability to adjust all parts of windows, tables (row height and column and table width sizes) and dialog boxes with a Restore to Default available. This can be accomplished with an add-on window function and the Window Manager ready to instantly incorporate users' changes. This includes dialog boxes—or at the least these must instantly add scrollbars whenever content is greater than window-size and the dialog box must automatically move or resize to fit on each user’s screen. Anything less than the above is laziness in design and development. That includes overuse of high level languages that add tremendous overhead; avoidance of minimal overhead low level routines written in a language such as Assembly; poor memory management; failure to effectively create and reuse global routines; and under- or misuse of OOP. Since I am a senior designer-developer-programmer and neither a Canonical designer or developer nor a contributor to Ubuntu, I am hoping all of these concerns and more are effectively addressed by Ubuntu designers and project managers. I also hope I will be forgiven for stepping on the toes of all the fine people who actually are “in the trenches” creating Ubuntu and the applications we need to make Linux “ready for the desktop” and all of the wonderful high tech tools currently in use and coming in the future.
|
|||||||||||||
