Unity, design coherency and Alt-F2 [LWN.net]

Unity, design coherency and Alt-F2

Posted Feb 15, 2011 13:51 UTC (Tue) by Frej (subscriber, #4165)
In reply to: Unity, design coherency and Alt-F2 by sladen
Parent article: First look at Ubuntu "Natty" and the state of Unity

Hmm either you misread my name or you mistake me from jeffrey stedfast (fejj). :)

Important: I'm not saying the rationale for unity isn't sound. I can't judge soundness with subjective opionions in any way :). Also i'm heavily biased. Sorry :(, at least i'm honest :P. Consider it a trust to be earned issue with gnome being a successful design through many and years and iterations, andin my opinion less fortunate ubuntu additions. (Seperate topic).

So to be anoyingly pedantic. Unity was announced in 2010 although with the netbook precurser. I'm pretty sure the shell sidebar idea was floated in mid/late 2009, actually from user who used the same configuration in gnome2 (sidebar). He might have been inspired from the ubuntu netbook stuff. It doesn't seem so. But lets not get in to a 'i was first' fight, i'm just saying that the picture shows the authosr perceived timeline, and there are no dates on that diagram. It's quite an aggressive diagram to float around suggesting you influenced others.

In any case, i agree no (great) work happens in isolation. Don't quote me otherwise ;)

I agree that the focus on touch is something that needs a completely different UI, but it's still not about user behavior or mental models. Clearly mark is missing something when he writes:

Relationship to Gnome Shell
Unity and Gnome Shell are complementary for the Gnome Project. While Gnome Shell presents an expansive view of how people work in complex environments with multiple simultaneous activities, Unity is designed to address the other end of the spectrum, where people are focused on doing one thing at any given time.

The purpose of shell is exactly to separate activities and tasks, allowing you to focus on one task, and not being disturbed. It's concerning if Marks decision is based on such a misunderstanding on workflow purpose. Note i'm not saying that canonical should not focus on unity, they are more than welcome to do so.

Pixel waste

I completely agree with the pixel usage waste, it should always be a design goal. Using a global menubar is one way to accomplish this, and i agree this is a good thing and also a really hard thing to do considering the scope of handling existing applications, props! :)

For potentially higher pixel saving... consider changing gtktreeview. Look at the height of each row, and how much whitespace a single row is used by banshee/rythmbox. It's excessive!

Remove some of the whitespace between each row, it might clash with the multiplum of 6 rule in the HIG, but the potiental savings are huge. (2pixels*rows).
Use a smaller font size, or otherwise a font with a lower x-height than the current dejavu font has. (it's somewhat large). Again the potiental space to be saved is huge.

Ah well, pet peeve. Should be an easy change.

Touch

Clearly the biggest workflow change is focusing on touch. I guess it's up to you to prove that it's possible to create a unified touch/pointer interface without too many tradeoffs, as you want unity to be default i assume it's not just for netbooks, but regular desktops.

PS: I think alt-F2 is a superuser feature, that is extremely hard to use unless you know whatever resides in /usr/bin (and thus that calculator is named gnome-calculator). But that isn't ubuntu's fault. :). If you already proper application/desktop/documents search with zenity, that should certainly cover it. Argument purely based on my own usage patterns. I guess it is important because to please a loud,childish and stubborn but important minority.

Sorry i didn't add to the bug, but it's partly flamebait... ;).

(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.
Whitespace when showing a list of data has a very high cost. You can show less rows in the same screen, it's an order of magnitude easier to compare data when scrolling is not required. If whitespace were free in this context, gtktreeview rows in rhythmbox/banshee should have no borders at all, we could just increase whitespace to frame each row.

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 think it's unfair to call it flawed because a (min. 10 year old) documents states something in pixels. Pixels are the mechanism, not the goal. It's pretty easy to rephrase the points in.. say em. Second the gnome HIG is for the desktop. Not phones.

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.

[1] http://dansted.co.cc/bits/11px_button.png

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.