Minimise and maximise buttons were recently removed from the window titlebars in GNOME 3. Discussions of the change have been ongoing for some time, but the decision only just happened, and the change came as a surprise to many. Personally speaking, I think the removal of the buttons is a definite improvement, and it’s a move that I’ve been in favour of for a while. Though Owen gave a really excellent account of his reasoning for the decision, some people are still wondering why the buttons have been removed, so I thought I’d try and explain why I think it’s a positive change. As with most major design decisions, the removal of the buttons is an attempt to balance a number of factors: there isn’t a single reason that you can point to.
First, let’s consider the issue of minimise buttons. Why remove them?
- They don’t make sense within the current shell design. There’s nothing to minimize to, like a dock or window list, and it’s potentially confusing, since users will not know where their windows have gone.
- Minimise buttons could be replaced with hide buttons, but that would require a new way of organising minimised windows in the overview and we’d need to establish an effective way of communicating where the hidden windows have gone. These changes would add complexity to the overall design (and subsequently to user interaction), and that would go against the aim of producing something that is simple and straightforward to use.
- Workspaces and the activities overview can replace the need for minimisation. Want to see a particular window? Go to the overview. Want things to be neat and tidy? Organise them using workspaces. A lot of work has gone into designing and implementing both the overview and the new workspaces functionality – we want to focus on the best parts of GNOME 3 rather than carrying incomplete legacy functionality. And focusing on one set of functionality results in a more streamlined user experience.
Without minimize, the GNOME 3 desktop is a more focused UI, and it is a UI that has a consistent high level of quality. Yes, moving to a minimiseless world might take a little getting used to for some, but the change makes sense and has clear benefits.
Second: maximise. Why remove these buttons also? A few reasons:
- It emphasises dragging the title bar as the primary way in which windows can be resized. (Double-clicking the title bar is available as a quick shortcut for this operation.) Dragging is already the mechanism by which windows can be snapped to fill one half of the screen, and there are possibilities for extending this snapping functionality in other ways in the future. This consolidation means that all the snapping resize operations are accessed through dragging, and this consistency of operation is predictable and satisfying.
- Drag-to-snap is more enjoyable than pressing a button to resize. This approach also enables some fun and novel interaction patterns, such as dragging a maximised window down to ‘peek’ behind it. These kinds of user experience advantages are extremely beneficial.
Again, removing this button streamlines, but it also adds a significant extra level of satisfaction to user interaction as well as a consistent interaction pattern that we can further exploit in the future.
Thirdly and finally, there are a number of reasons why removing both maximise and minimise is beneficial:
- Isolated titlebar buttons are touch-friendly.
- Multiple buttons on the right of the titlebar was incompatible with centered window titles: the arrangement was visually unbalanced and did not work well with narrow windows. Having only one window control on the right enables us to keep the window title in the middle; this is desirable because:
- It prompts users to read windows vertically from the centre (which is something that we can exploit in future application design).
- It opens the possibility of having another control on the left hand side.
Clear advantages here also, then. Add them to the other benefits and, on balance, it is clear that removing the two buttons makes GNOME 3 a better product. I’m definitely having a better experience since they were removed.
[Edit: I can’t guarantee that comments will get published, since I don’t have time to review them all. Many apologies!]
As far as I know 
Good work. I wonder how we can teach the user about the maximise feature. For example, if the user is constantly moving the window to the top left and stretching it out, we can give a hint that you can just drag it to the top.
That sounds like a pretty good idea! ๐
Perhaps it would be a good idea to remind everyone that the **buttons** were remove but not the **feature**?
I.e minimize is still available through a number of possibility:
– alt+F9
– alt+space -> Minimize
– right click on title bar -> Minimize
As well, maximize is still available by doing one of:
– alt+F10 (alt+F5 to unmaximize)
– alt+space -> Maximize
– right click on title bar -> Maximize
It seems like most of the time, when those kind of changes have been announced for Gnome 3, the developers / designers have said “the button has been removed” and have assumed that everyone would understand that it obviously meant “the underlying functionality is still there, just not accessible in the GUI as it used to”.
Significant flamewars have followed each time, and lots of people would realize a few days later that the functionality was still there and then say “it’s ok then”. However, it was too late as lots of misinformation had circulated all over the Internet.
I’m convinced that the recent outcries (e.g about the “suspend on lid close removal”) would have been much less important if emphasys had been made on the fact that the feature was still there.
Yes, we should be clearer about these things. ๐ Maximise is obviously still there. Minimise is too, and Owen has said he wants to review the situation as it progresses. Personally speaking, though, I’d actually like minimise to be removed altogether…
Nice! I really like it how you care to think about these things and challenge old UI habits.
“Drag-to-snap is more enjoyable than pressing a button to resize.”
What is this based on? Any particular user-behaviour research or just personal preference? I don’t know much about these things but I personally find all these drag-around touch UIs terribly inefficient. Especially on a desktop where I don’t have and don’t *want* a touch screen (fingerprints!). IMO, Windows 7 with that AeroSnap feature showed us how *not* to do things. Very gimmick-y…
Fab:
It’s based on critical examinations of what our competitors are doing, on feedback from users, and on a range of product testing done by myself and the other design contributors. You might personally disagree with the assessment (and that’s fine) but that puts you at odds with a quite robust position. AeroSnap, for instance, has been extremely successful. It’s not just a gimmick: people use it to enhance their productivity.
Drag-to-snap doesn’t require a touch screen, btw: you can use a traditional pointing device if you’d prefer…
Perhaps I read too much into your reply here, but leading with “critical examinations of what our competitors are doing” invites too many theories that we’re followers in F/OSS, not leaders…
Jon:
So is everyone who does touch interaction a ‘follower’ rather than ‘leader’? (Apologies for being facetious… I couldn’t help myself. ๐ !) It’s pretty clear from the GNOME 3 design that we have *a lot* of our own ideas: look at the activities overview, messaging tray, workspaces, etc. Look at all the ideas in our design repositories. You wouldn’t see any of that stuff if we were simply following what others are doing.
I believe I prefaced my comment with the fact that this is personal and I have no idea about these things. All I wanted was an explanation of the reasoning, thanks for that.
Fab: Oh! Apologies if I came across too sternly! That certainly wasn’t the intention. You’re right – it was a perfectly fair question to ask.
I really like what Gnome 3 is doing in general.
I totally disagree on AeroSnap and similar features on the Mac being “popular” though. I support everyday users in my part-time work 16 hours a week and I have yet to meet *one* person who actually likes these features. Everyone I’ve talked to in the last year or so that Win 7 is being rolled out there hated these things and found them annoying. To this day, people regularly complain to me that they “want the XP way back”.
It’s a bit different on the Mac but I generally think Mac users are defensive rather than critical about their OS and I don’t believe that has anything to do with the quality of MacOS X. They’ve payed such a premium for their hardware that they need to defend the OS to justify the purchase price. But having said that I don’t see the Mac users using these features much either to be honest.
Again, YMMV and total personal opinion. Just saying. ๐
> “IMO, Windows 7 with that AeroSnap feature showed us how *not* to do things. Very gimmick-yโฆ”
On the other hand, I find it tremendously efficient to drag one gnome-terminal window to each edge of the screen to easily have them fill half the space. It’s a very fast way to setup an enjoyable environment for development:
– open session
– alt+f1
– drag two terminal icons from the favorite to the workspace(s), same with one epiphany window, evolution, empathy, xchat,…
– snap one terminal to the left
– snap the other to the right
– start hacking a few seconds only after having open your Gnome session
I don’t use the drag-to-maximize though, since I’m so used to doing alt+F10.
What surprises me is that you need all that excise to setup your environment after logging in. Why doesn’t Gnome remember that setup and restore it for you?
@Boudewijn Rempt
Because I don’t do always the same thing on my computer.
Sometimes I want to watch a movie, why would Gnome launch all of the above?
How could Gnome possibly know what I’m about to do when I turn my computer on?
In that regard, getting ready to do something is much faster in Gnome-Shell than it was in Gnome 2. At least for me. ๐
A further improvement would be to trigger the snapping feature when a window is resized close to the edge of the screen. That would make life easier for those people who are โmaximizingโ by resizing the window.
As for balancing out the titlebar with another button to the left, I would love to see a proxy icon (ร la OS X).
I like this idea. I can’t see why people _wouldn’t_ want snapping near the edges.
Pingback: Where did the buttons go?afaik | 9nd.pl
Reading about all those changes in Gnome 3 I think I will have to install KDE. Or at least continue using Gnome 2.
Hi Karol,
I’m sorry to hear that. GNOME 3 might sound quite different, but it’s actually quite easy to use. I’ve tested it on friends and family and they took to it with great ease. I’d definitely recommend that you try it out before you make a decision – there really is a lot to like about it. (You’re welcome to carry on using GNOME 2, of course!)
But apparently you forgot to test it on old Gnome users ๐ I have been using Gnome since almost beginning. And this minimalistic approach while sometimes make sense is not always the best. You may be right about buttons (I have seen Gnome 3 in action only for a moment) but other ideas people were writing about recently – like the one with suspend on lid close are really bad, bad ones! Moving useful options to the obscure GConf editor is contrary to the Gnome simplicity you’re writing about.
Anyway, I hope that I will not be forced to use KDE, after all those years with Gnome it would be very difficult to get used to it ๐
Karol,
Oh, we have enough old GNOMEys around to tell us what they think about the changes ๐ (well, most of the people working on GNOME 3 *are* old GNOMEys!) If you’re an old GNOME user, my advice would be to seriously try GNOME 3 before you make a decision. It really is nice to use; I’d be surprised if you didn’t enjoy it. Use it for a week: I’d be really interested to hear how you get on.
Just for the record, nobody’s planning to simply move options to GConf (or DConf now) editor. We’re focusing on providing what we think makes sense for the default behaviour and options, but we really want to have a nice GUI method for people to change other options which might not be there by default. I’ll be blogging about that soon.
Very good explaination pal, awesome post.
Pingback: Just why has Gnome 3 removed window controls entirely?
I like that reason. I can control max n minimized by shorcut. But we all know, even the close funtion have shotcut for it. Why close function isn’t removed too?
You’ve just alienated thousands of potential users!
You’re making people that use Gnome for WORK (not gaming or home recipes) have to retrain themselves. This is not trivial and it’s something Microsoft are guilty of too. Take the Office 2007 redesign of the toolbar ribbons! Please don’t mess about with this stuff! Make it pretty by all means but don’t mess with the core UI functionality unless it’s been reported as a real problem. Just common sense really!
Craig,
I strongly disagree. I’d be very surprised if large numbers of people outside our communities consciously notice the change prior to using GNOME 3. Some might need to make an adjustment, but the change is a positive one and they should notice the advantages. Also, the sleekness of our design will attract many users who would otherwise not consider GNOME.
The ribbon is totally different case, btw – it’s an extremely complex design intended to present an absolutely massive number of actions. If anything, it validates our approach of making things simple and straightforward.
I agree with Allan – I consider myself an old-timer (was around in the Gnome <2 days), and use shortcuts and some customisations, but I'm definitely in the "less is more" school. Every choice you give the user, is a (usually unimportant) choice the user needs to waste time and attention on.
Give me sane defaults out of the box, and the option to change it through gsettings/dconf, but only if I absolutely, positively need to change it and my use-case is an outlier (<5% of the users would change this).
My ideal desktop environment is one that gets out of the way, and becomes nearly invisible in use.
Craig:
If you don’t like the present-day decision, please read my analisys and my proposals: http://mail.gnome.org/archives/gnome-shell-list/2011-February/msg00241.html
PS: My proposals are not the opposite of current decisions, it’s an extension more suitable for use of a human. ๐
You know Craig, people said the exact same thing when we moved from 1.0 to 2.0. We did the same minimization, and added 6 month release cycle. Nobody thought it was a success. After a number years of iterative work you see before you. The same will happen again for GNOME 3.0.
I beg to differ and totally disagree with this change. Once there is a functionality that people have gotten used to, it becomes a pain to switch to something new. Adding a functionality is welcome, because more the choices, more the popularity. As a design, may it is more convenient to make, but user’s need choices. So, my preference is have both. This is a classic case of designers not necessarily being the best judge of user experience.
cr,
So this is an interesting issue, and you’ve raised a valid point. Change can be difficult for some. At the same time though, you can’t never change. GNOME would have died a slow death if we hadn’t refreshed. Also, look at our competition: look at OS X, WebOS, etc – they are rapidly changing. There are plenty of things we can do to ease the transition, such as demo videos and hints in the UI, but not changing isn’t an option.
Don’t try make it look like a rule ๐ Actually some changes can be a blessing ๐
That would mean you can only add features. And the UI would quickly become a bloated mess with 15 ways of doing the same thing, in the name of preserving “the previous ways of doing things” that some subset of the users might have gotten used to.
I personally would hate this, because I only need to learn the new way of doing things once; while having to constantly choose between a plethora of choices every time would start to grate on me. I consider this true for both actions (“how am I going to maximize today”) and settings (“is suspend on lid close on or off for this laptop? Didn’t I change it last week? What _is_ going to happen if I close the lid?”).
Great writeup!
I recall when we I heard of the idea I was like “What, are you crazy?” but using it in action it works out quite well and the design actually gave me new, more effective VM habits.
How can we know that some activity has happened in some other window,
without the minimized windows. For instance, when I receive a e-mail
on gmail, the window title changes, and I know I’ve received a message
because the title of the minimized window changes. Is there any replacement
for that in a non-minimized-window world?
Leandro:
Yes, our notification system supports this change very effectively. You get a subtle popup at the bottom of the screen and you can click on the notification to switch to the window in question.
This is an interesting point – the notification system seems very well integrated, but what about things like web apps that don’t natively participate in that? Does the window manager provide notifications for changes to window titles, also in the minimized/hidden case?
Also, FWIW, I like this change a lot. Keep up the good work!
one issue i have with gnome3 is that it’s entirely about workspaces. there’s no other option in how you use gnome3. while i understand that many people seem to like them, i’ve never got on with them. i use a dual-monitor set-up, so i tend to have one monitor used for stuff i want to see all the time (e.g. conky, music player, visualisations, server monitoring, chat programs, etc.) and the other monitor is used on a much more dynamic basis instead: switching between whatever active task it is that i’m playing with at the time, whether it’s email, web browsing, development, videos, or something else.
the issue with workspaces is that this sort of split isn’t supported: workspaces treat both monitors as being a single entity. as such, if i have an email workspace and a web workspace and a development workspace it means that i can’t keep the fixed layer across all workspaces (well, conky might stick around, but any applications like my music player or download monitor or server status indicators or whatever would belong to a single workspace). i’d either have to duplicate (which isn’t possible with some applications) or i’d lose the ability to monitor everything.
as such, the only mechanism that suits me is the minimise/taskbar combination as it’s the only mechanism with the degree of control i require. so, unless there’s a method for having per-monitor workspaces (which i could probably make work for me) or it’s possible to make applications sticky across all workspaces (which i’m not aware of, so please correct me if i’m wrong on that point) then this workspace mechanism is of no use to me at all, and consequently i’ll have to ditch gnome for something else.
the other point i’d make is that minimising to a taskbar and bringing the application back to its previous size (as a rule, i don’t run any applications full-screen unless there’s a specific reason as i like being able to use the mouse to pull windows forward) can currently be done with a quick keystroke – alt-tab – or a single click (two if i want to minimize the previous window). i don’t need to wait for an animation and then select it from the hidden applications menu and drag it onto a workspace or whatever. maybe there’s a faster mechanism that i’m not aware of in gnome shell, but it seems to me that my edge case isn’t being considered.
i’ll still try it, and see how it works for me, but from what i’ve seen it looks like i’ll be going to something like openbox instead as that’ll let me work the way i want to work without trying to force me into using ‘workflow’ and ‘workspace’ mechanisms that don’t fit with my usage scenarios. if i’m wrong, then please feel free to tell me ๐
That’s a great point – also a dual-screener here.
While I generally like the direction Gnome3 is going in, and try to defend the designers’ appetite for experimentation, I’m also a bit wary of how multiscreen-setups are going to be handled wrt workspaces.
I guess April will be where the rubber meets the road – I’m looking forward to it.
I’m not sure how I feel about this either way. I’ll have to use it for awhile before making an opinion. Out of curiosity, is this something that is implemented through the theme or at a lower level? Can a theme override it if desired?
Pingback: GNOME 3 ๏ผโๆๅคงๅโโๆๅฐๅโ็ฅ้ฉฌ็ๆ่ฎจๅไบ | I, KDE
I agree with the removal of the minimize button, but I disagree with the removal of the maximize button. Why? Because of my years of observations/experience observing non-techsavvy users. I maintain GNOME-based computers for various friends and family members, and I can tell you from experience that while my users do not ever minimize windows, *none of them* knows that you “should double-click the titlebar to maximize”. Even if you tell them, they don’t remember it. It’s just not discoverable and it is not intuitive.
And don’t expect them to know/remember keyboard shortcuts.
If your problem is really about the balance of the titlebar, then make the “maximize” button go to the left, on the opposite end of the “close” button. Problem solved. And it is *more* balanced/centered than your current approach of having a single button on the right.
I can see the argument for the minimize button, but not for the maximize one.
This is a very enlightening article. I certainly understood the removal/hiding of minimise; and now I understand the reasoning for removing maximise.
I also agree with bochecha here, there isn’t enough emphasis on functionality being kept.
It’s also rather sad to see that for many years, people have said GNOME is not changing, and now it has, other people say “I want the same UI as before”.
Keep up the good work.
1) Drag-and-drop is very difficult on touchpads, and most people these days are buying laptops. Drag-and-drop is also undiscoverable.
2) Double-clicking the title-bar is undiscoverable.
Conclusion: maximize/restore button should remain.
I agree about the minimize button, though.
Sandy:
I think these potential disadvantages can be overcome. This kind of dragging behaviour is becoming much more common, and the way we advertise and communicate our UI can help to inform users. These changes will also hopefully act as a catalyst for work on better touch support.
The act of dragging will never be touchpad-friendly. But gestures on good touchpads could certainly alleviate this (3 or 4 finger swipe up to maximize, down to restore, or something like that).
But we are not living in the future, and these gestures don’t exist, so I don’t see the point in rushing into this change.
For those who are interested, Jon McCann (GNOME Shell design lead) has written a response to this same question on the GNOME Shell mailing list:
http://mail.gnome.org/archives/gnome-shell-list/2011-March/msg00005.html
I’m willing — and even curious — to give the new Gnome 3 features a try. That said, it’s more because I’ve got a personality type that enjoys novelty than because I think Gnome 2 is broken and needs fixing.
The comment above about MS Office 2007’s notorious “ribbons” bears repeating: Sometimes change is good (tabs in web browsers) and sometimes it is a colossal freakin’ pain in the brain (ribbons). And, clearly, designers are not always able to tell the difference.
Hey,
I just wanted to say, that I have configured Metacity to not show any buttons at all for a long time.
Closing an app is a very rare occasion for me (and there a multiple shortcuts for that), and since I run everything fullscreen, the other two buttons were also superfluous.
so I can only APPLAUD THIS DECISION
How do people find out about workspaces, overview, dragging and the like, how do they learn to use them, and how do you make them want to find and use them? Your reasoning makes a lot of sense but it assumes people know these alternatives exist, know how to use them and are inclined to change their habits (instead of viewing the changes as intruding on their work).
There are lots of ways to teach a new user these things in a nice playful way. So that’s what we’re going to do.
Good choice! I haven’t had those two buttons for ages even in GNOME2. I do hope the same flexibility in gconf-editor will remain, since I’ll probably want to have the close button on the left. ๐
Yes. What we call “removal” is actually a changed default setting, so you can still use gconf-editor to move the close button or add additional ones (there’s actual support for ten different titlebar buttons for the insane to choose from).
(Just note that gnome-shell overwrites the setting in /apps/metacity/general/button_layout with /desktop/gnome/shell/windows/button_layout)
Pingback: ุฌููู 3 ุชุฒูู ู ุชุญูู ู “ุชูุจูุฑ” ู “ุชุตุบูุฑ ูู ุง๏ปทุณูู” ููููุงูุฐุ ููู ูู ุงุฐุงุ! « ::ูููููุณ ูููู::
Pingback: ุฌููู 3 ุชุฒูู ู ุชุญูู ู “ุชูุจูุฑ” ู “ุชุตุบูุฑ” ููููุงูุฐุ ููู ูู ุงุฐุงุ! « ::ูููููุณ ูููู::
I agree with the minimize removal, but I disagree with removing maximize; for many of the same reasons others have listed.
As a thought experiment, what would it take to convince the gnome-shell developers to put maximize back?
I’m not a designer, but based on some of the recent blog posts I literally have no idea how to interact with the g-s team. Arguments based on familiarity seem ignored. Majority opinion is not a convincing argument. One can cite examples of other OS’s doing it either way. Personal observations of people using the new shell seem discounted in preference for user testing done by redhat (yet I can’t see the results of your testing). The g-s mailing list is a one-way street.
As a GNOME user I quite like shell. But as a GNOME developer I have no desire to hack on it, for the reasons I gave.
Anyway, perhaps you can address this in another post. You need to market this to developers too.
Hey John,
That’s a fair question. You could have participated in previous discussions of this if you had been hanging out on #gnome-shell and #gnome-design at the right times. I know that’s not easy for everyone, and it’s definitely not ideal, but it’s the best solution we have right now. As for the future, it’s unlikely that the decision will change for 3.0: we’re into UI freeze now, after all. Owen said that he’d be reviewing it in the future, though, so speaking to him might be a good way forward. (He might not write on the GNOME Shell list a lot, but I think he does read it, as does Jon.)
I’m not sure what you mean about the user testing comment – I’m not aware of Red Hat having done any. Personal observations are valid contributions, in my book. Generally speaking, though, it isn’t new pieces of evidence that swing these design questions – most of the factors are known fairly early on. What clinches it is the kind of reasoning that you’re doing with the available evidence, alongside the investigation of the various possible approaches. I’m certain that you’d get a seat at the table if you did want to hack on GNOME Shell, though. That’s what happens with the other devs, and it’d be great to have you on board.
Fair point regarding IRC, although my timezone is not the most convenient. Archives of channels would help here (and it is odd that the offer to archive these channels was not met favorably)
Perhaps I have misremembered that user testing had been done by redhat on gnome-shell users, although the absence of such testing makes me a little nervous.
My comment ‘what would it take to change this’ was not actually addressing this change, I understand that things are in freeze, it was more of a comment on how I am unsure how to interact with the gnome-shell developers.
Anyway, I will follow up with an actual point on the g-s mailing list.
John,
Oh! I’m a bit concerned you got that impression about the IRC logging suggestion – I’m totally in favour of that. I think it would be really useful. (Hrm, I think I could have expressed myself more clearly in that thread…)
How do you interact with the shell developers? Same way you would interact with any other GNOME devs. Only difference is that the design and development lead roles are held by separate people.
I already don’t use the maximize button for some time, on Ubuntu and on Windows.
It will be a little sad to see it go away, but it really have no use.