As always, the GNOME design crew have been hard at work of late. We helped to drive many of the changes you can see in the last GNOME release, including a new color picker, updated application designs, new scrollbars and updated spin button widgets. We haven’t taken our foot off the gas though, and there’s plenty of work to report.

It’s an exciting time in GNOME design land right now. GNOME 3 is a big undertaking: we’re working to improve the entire experience, including everything from interface widgets and controls, through to applications and the core user experience. But we are making good progress, and more and more pieces are slotting into place. Slowly but surely, the design of the overall experience is starting to take shape.

It has been far too long since I’ve posted a GNOME design update. In fact, it’s been so long that I’m dividing this update into two. In this first part, I’m going to detail design work that is focusing on the core GNOME user experience. The second post will cover application design updates, as well as application integration. I’ll post that update in the next few days.

Excitingly, many (though not all) of these new designs are planned as features for the next GNOME release. If you want to help implement any of these designs, just get in touch.

Lock and login screens

This is something that we’ve wanted to do for some time. The lock screen plays much the same role as a screensaver – it is what is displayed when your device is idle. The difference between the lock screen and a screensaver is that the lock screen is really useful, of course, since it will display the time and updates about notifications (the notifications part will also be configurable).

Cue a motion mockup from Jimmac:

This motion mockup shows several things. In the first section, you see the process from boot through to user selection. (Yep, a simple spinner and fade in is all we want.) The second demonstrates what should happen once the machine has gone idle – the screen blanks, is woken up to display the lock screen, then the lock screen is removed and login occurs.

[Edit: a note about this – although the video shows the lock screen being removed with a short mouse drag, it will also be possible to remove it using the keyboard or with the mouse wheel.]

Message tray design updates

One area where we’ve all been keen to see some improvements is around notifications and the message tray. The GNOME design crew recently returned to those designs and came up with some updates which we think will make a big difference.

Under the updated designs, pop-up notifications will avoid the mouse pointer (some of this behaviour already landed in GNOME 3.4, actually) and linger until we are sure they have been noticed. The expanded notifications will also queue up so you can always see when new messages arrive.

Plans are also afoot to replace the moving targets in the tray with larger static icons:

Scrolling

Jon and Jimmac have spent quite a bit of time working through the details of how scrolling should work under different conditions. The idea here is to keep things as consistent as possible across different types of devices, while still leveraging their different strengths.

Jimmac’s motion mockups show the desired behaviour for both pointer and touch devices. We’re hoping to see scrolling improve along these lines in future GNOME releases.

Printing

Jon and Lapo have done a bunch of work that aims to improve the state of printing in GNOME, and they have produced some quite detailed mockups for new print dialogs. These look great in my opinion, and are a huge improvement on what we have right now.

One of the best things about these designs is that they let you get a clear preview of what will be printed. They also present a clear set of simple options.

Initial Setup

Initial setup is intended as a specification for what the user should see the first time they boot into GNOME 3. This is new territory for GNOME, but it is an important piece of the picture if we are going to produce a consistent experience for our users. The goal is to ensure that the system looks and feels like GNOME from the moment someone starts using it.

The initial setup assistant will be an optional component that can serve as a reference implementation for distributions. It includes several important elements for new users, such as a setup screen for online accounts and a product tour to help people get started.

And more…

There are other areas that the GNOME designers have been looking at, but which aren’t as fully developed. Other recent design work on the core user experience includes:

70 Responses to GNOME Design Update, Part One

I know I’ve written about this before, but how about making the Power off button visible by default?
It’s the only essential feature that’s hidden under a keyboard shortcut. Actually, it’s the only feature hidden under a keyboard shortcut, which is quite surprising, given that it’s necessary for people who care about their computers (it doesn’t do the computer good when it runs 24/7, especially if you travel with it), about power consumption, those who dual-boot, and those for whom Suspend doesn’t work (e.g. my sister, who’s computer won’t wake up from a suspend). It’s not at all in tune with Gnome’s “made of easy” ethos.

mirek2, we’re looking at the user menu for 3.6, including the power off and suspend options. There aren’t any definite designs yet, but I think we’ll be able to come up with something that’ll make people happy. 😉

I like the intention to avoid moving targets in the tray.
Yes new color picker, updated application designs, new scrollbars and updated spin button widgets are cute, but what about SPEED and PERFORMANCE?

I mean in paticoular STARTUP SPEED and responsiveness (my laptop show much disk activity and LAG when I search an application, it should be cached in RAM).

There was a version ( I don’t remember 2.24 or 2.26) that one of the feature was improved startup speed, that was very good, but after some other releases that feature was lost…
I remember many studies made by gnome developers about speed up start, but that argument seems that isn’t touched anymore.

But In the long run it would be nice to have a notification system that copied Google+. The message tray could be disabled, and the top menu could contain an icon that allowed me to open a notification history.

It doesn’t actually matter where and when you want to pick a color. Being able to lift it from the screen is potentially useful in all scenarios. Much easier than fiddling with the widgets or entering hex codes by hand.

Quite often you want to match colors you already have on the screen /somewhere/. And It would even easily fit into the dialog, just put it next to the shaded [ + ] button.

adding back the eye dropper is certainly possible – it was removed because it requires collaboration with the compositor (given that we cannot ask X11 for pixels that are generated solely by the compositing manager – and that in the future with Wayland only the compositor knows what’s displayed at pixel [x, y]) and that collaboration will require some form of communication protocol that hasn’t been defined yet. plus, it has to work on all the platforms supported by GTK+.

it’s certainly possible to add back the color picker – it was left out because the previous implementation was unsatisfactory (i.e. a hack) and because it’ll have to be made working on the platforms supported by GTK+, as well as future-proofed for Wayland (in Wayland, an application cannot access the buffer containing the contents of the screen or of other applications).

even on X11 it’s better to go through the compositing manager, like we currently do for taking screenshots. part of what you see on the screen is fully generated by the compositing manager without the X server knowing how to get it; also, reading back data from the GPU has to be done sparingly and at precise synchronisation points – you don’t want the color picker to slow down the refresh of your whole desktop, for instance.

all these factor contributed to the removal of the eye-drop tool; you can still use Gimp if you want to, but in the future even image editing applications will have to deal with the fact that the graphic system is not going to be the same as it was 20 years ago. 🙂

@Tobias: at the end of the day, the compositor will do glReadPixels() – the application can’t (the buffer is owned by the compositor, the application knows nothing about) – and send us the pixel data using some form of IPC. obviously, this has to be specified in a known place, so that other compositors can use the same interface; plus, there needs to be some form of degradation so that it doesn’t utterly fail on non-composited environments or with compositors that don’t implement that capability.

if you mean “let’s take the X11 window under the pointer position”, which is (more or less) what the old eye dropper was doing, then that will fail for things that are not inside an X11 window (e.g. the entire shell UI); alternatively, you’ll have to ask the compositor for the XComposite overlay X11 pixmap, in order to get to the pixels that you’re seeing on the screen.

I understand that there are areas on the screen that don’t correspond to any window and that we need to go through the compositor for that reason. However, given that the compositor is also expected to do full-screen color correction (which may be more complex than a simple gamma curve), I’d say that glReadPixels with the front buffer (i.e. reading directly from the screen) is wrong. You want the pixel before the correction, not after. Hopefully the compositor maintains a fully composited but uncorrected auxiliary buffer – that would be useful.

@Alexander color correction and how to deal with it is a very good point.

currently, the idea is to do full-screen color correction through shaders – and that would by applied by the GPU, so we cannot keep two buffer in memory because there is only one buffer. we could render the scene to an offscreen pixel buffer and read it from that, and then map that buffer to the screen – the performance implications may be very interesting to deal with.

The direction you’re going with this is awesome, especially the welcome screen! I feel like GNOME’s needed that for awhile now, and it’s really encouraging to see that it’s being planned. I hope things go well for you!

Will “Esc” be the only keyboard key that moves from the lock screen to the password screen? I wonder it may not be one of the first keys a clueless new user would try. Why not include one or more alternative keys in order to increase the probability of success on the first trials?

Proposed candidates:
– the “up arrow” key, because it would move the lock screen up;
– the “Super” key, because it is the system key;
– the “tab” key, because it is used to change focus, in this case to the password screen
– the “Enter”/”Return” key, because it is often used to aknowledge (the information in the lock screen) and advance (to the password screen).

Yes! Those changes to the message tray and notifications look like they’ll kill the only things I think have been a severe degradation in terms of user experience. The message tray as it is currently is just bad, the moving targets are hideous.

The only issue remaining would be without the title appearing by default it’s difficult to differenciate multiple chat icons if they have no photo attached to them. I can live with that, though, given the other improvements! Great work, everyone! =)

I’m not sure if this would solve the problem. I sometimes have 15 open IRC contacts with no avatars. Assigning them random avatars would remove the confusion just a bit. I’d appreciate some kind of tooltips appearing above an icon when hovered by the mouse pointer.

Any plans for HUD-type menus like Unity? Would love to see it.
The only other improvement I could possibly think of is the ability to drag and drop desktops into another order. Given that you traverse it linearly, if you’re moving multiple windows from desktop to desktop to reorder them, sometimes the dynamic desktop destruction works against you.

Gnome-shell exudes beauty with a simple but functional interface. However, I was surprised 3.4 did not include the media player indicator extension as standard? That is the only extension which I consider should be “in the box” (apart from the alternative status menu for the power off option but you hint above that you are finally fixing that).

The design page for Screen Locks shows as first objective:
* Shield system from stray taps and clicks when locked
and that lock is removed by:
* dragging up with pointer or touch – scrolling up with mouse wheel – Esc key on keyboards

Is that really a problem on desktop/laptop computers? I’m not talking about phones or tablets or touch screens but just your regular mouse-and-keyboard computing device. It’s not the same as a phone which you hold in your hand and can easily swipe.

I would just find it annoying on a desktop or laptop. Having met several of those not-power-users you seem to want to attract, I’m pretty sure that after moving the mouse or hitting *any* key and nothing happened, they’d just assume the computer froze.

Are you thinking of flipping the scroll direction on a mouse? Again, scrolling on a touchscreen and scrolling on a mouse (or touchpad) are not the same.

I agree with your mouse scroll comment. On a trackpad it is “arguably” more intuitive to be the reverse of the current, but on a physical mouse wheel, it’s horrid trying to scroll up to go down the page

I think the Initial Setup wizard is actually old ground which was removed from early GNOME 2.x. The idea being that GNOME was a desktop you could just start using.

What actually requires setting up to use GNOME? It seems like the only real question we need to ask is “What is your name?” “Would you like a password?” Other items, like adding online accounts could appear as a notification bubble at the bottom of the screen when you boot for the first time.

You’re right that it should be minimal, and I think the design only asks for the bare essentials. It’s just 4 items – name and password, location (automatic if possible), wireless network and online accounts. Those are the basic requirements for getting started.

I believe that Mirek’s idea (Ubuntu’s actually) would make a lot of sense.
All the OSs listed on your wiki page come pre-installed and people never need to actually install them (maybe upgrade them or reset them, but there’s no need to ever go through the (lengthy) install process).
For Gnome OS, being a third-party OS, it would make a lot of sense to do the setup while installing, though.
Actually, ubiquity (Ubuntu’s installer) asks for your wi-fi password even before installing so it can download updates (and Flash, should you want that).

The one thing that currently irritates me about messaging is the current scenario –
– Run Shotwell, then insert an SD card from my camera.
– A notification appears allowing me asking what to do with the media on the card.
– The message tray is visible, on top of the “Import photos” button at the bottom of the Shotwell window.

I basically need to flick the mouse down into the corner, on top of the tray, then move it away to dismiss the tray, then move it back again to click on the button I’m trying to get to. Very annoying, and almost the only thing I dislike about Gnome Shell.

Thank you for fixing the terrible notification accordion expand behaviour.

While I too always disagreed with the lack of power button, it was at least accompanied by a rationale and explanation. What was the original thought with the expanding behaviour (besides teaching your users fine motor control…. 😉

Usually on a desktop computer if you provide any input to the blank screen it’s because you want to access your desktop. As it is right now, you already have a clock both on the blank screen and on the login screen, I don’t think we really need another huge clock on a different screen that does little more than adding an extra step to unlocking the computer.

The whole point of a lock screen is to keep users out of your session, so I don’t think letting people mess with things like connection settings without authenticating is a really good idea.

I’m not sure about managing the music player without login, that might be useful in certain scenarios (I can’t think of any, but let’s say it might be). That could still be integrated into the login screen without adding yet another layer.

I reckon lock screens are trendy (just because smartphones are trendy as well) but other than that I can’t think of any reason why I would ever want a lock screen in my computer.

For those who wish to personalize their computing experience with art, or photos of family, etc., will this eventually support screensavers? They could be optional, and appear after blanking of the screen, and disappear when the user touches a input device to show the lock screen. My only issue when using xscreensaver right now is loosing the ability to switch users, and in this future incarnation the notifications.

these all look really nice and seem very well thought out, as usual (imo). most of the suggestions and ideas in the comments seem equally well thought out so i hope you can take them into account.

i also wondered about the ‘banners never pop under cursor’ – in the video the cursor is conveniently not right at the bottom of the screen. what happens if it is? perhaps i (possibly accidentally) left it there whilst reading a long article – do i miss important messages?

i noticed something in the screen lock mockups – are we really allowing people to switch my networks (switch devices on and off or change wireless networks) from the lock screen? i don’t think i mind someone pausing my music or skipping to the next track but i’d like to know my network will keep running (programs running in the background while i’m away) and it’ll be on the same one when i return.

agree 100% with James Cape about the re-use of desktop background in the lock screen. on android you specify two backgrounds – the home background and the lock screen one. can we do that? also worth stealing from smartphones (patents permitting) – the homescreen background is bigger than one screen and is then shared acrosss home pages, moving a bit at a time as you swipe through the screens. can we do that? we’d need our desktop background to be taller rather than wider – maybe it could be another mode along with Tile/Zoom/Centre .. maybe ‘Slide’?

Great looking designs here. I’m confused about the message tray at the bottom. I always assumed it was a temporary hack where legacy applications could put their icons, and that in future everything would go into the menu bar at the top. Was that wrong? It seems a bit weird to have this second popup taskbar.

I would like to see that the default GNOME-Shell theme got some love. All the UI-elements are ridiculously huge! The “session”-menu (clean install, no extras and only one account) takes up 50% of the vertical pixels on my screen and I have 1920×1200 px 24″ screen! It’s obvious that it’s been designed for high-resolution small monitors like tablets but can we at least get some configuration settings in the system settings? Like font, font-size and general scale of elements?

Today I’m required to use third-party themes to just get it all in a usable scale, though there are few that look good, so I’d rather that the default one was more flexible. And why have to depend on gnome-tweak-tool to change theme settings? What if you need a high contrast theme? Shouldn’t it be a more user friendly way of accessing it?

Always exciting to see the future direction of gnome. I’m no expert but I would like to make a couple of observations:
– If going with the kinetic scrolling paradigm then it must always be adhered to. There should never be a step change eg, page down should animate the page scrolling. Although we have learnt where to reposition our eye after pressing down arrow or page down, most new comers (especially kids of the future) will not have learnt this. Trying to read a block of text in a small window when someone else is scrolling up and down illustrates how unintuitive this is to the the brain.

– For boot I think distributions should be aiming for a even cleaner process from boot to desktop. The default desktop image should be the first thing displayed. This image then remains as the one constant through the gnome experience. Be it boot progress, login, shell or programs they should all overlay this backdrop. Any introduction of graphical UI elements should occur within the physical/kinetic paradigm ie. they should animate in and out of the display. That way the brain always knows it is always looking at the device whatever modality it is in.

Please
1) add temperature monitor to “system monitor” (gnome aplication).
2) add some application, were will be easy to set size of fonts, window’s frames, size of buttons etc. Gnome is to big for small LCD monitors (for example 14″ and less), still.
Thank you.
Excuse me. My english is not well, i know
Best regard,
Ravensun

About the printing dialog and that I’ve seen no reference to “common printing dialog project”.
They’ve put a lot of energy in designing a new printer dialog and solving a lot of issues all currently existing dialogs (on all platforms) have and have created some really existing specifikations. Wouldn’t it be clever to continue to work on that?