One of the things that the GNOME design crew have been focusing on recently is creating a new approach to application design for GNOME 3. We want GNOME applications to be thoroughly modern, and we want them to be attractive and a delight to use. That means that we have to do application design differently to how we’ve done it in the past.

Design is always an iterative process, and the new GNOME application design approach has been steadily evolving for some time. There have been lots of design ideas and mockups, and there has been plenty of testing of prototypes and of proper implementations. This process has resulted in some design patterns being consigned to the scrapheap while others have come to have an increasingly important place in our hearts. Slowly but surely, things are starting to fall into place.

As the new GNOME 3 application design approach has stabilised, we have been able to pursue the development of more new applications. GNOME Documents and Contacts have been joined by Boxes, Web and Clocks. We also have designs in the works for many other new applications, including Mail, Videos, Chat, Photos, Calendar and more. Each of these new designs utilise the application design approach that we have been developing. We are also starting to document our new application design approach in a new version of the HIG. This will help application developers to create their own GNOME 3 apps.

In what remains of this post I’m going to try to give you a taste of the new application designs, as well as give a bit of background about why they have been designed in the way that they are.

Maximised Windows

Displaying multiple windows at the same time means that screen space isn’t used efficiently, and it means that you don’t get a focused view of what it is that you are interested in. Windows that aren’t maximised also create additional tasks for people. Often you need to adjust their size, or you have to move them around.

These are just some of the reasons why GNOME 3 applications have a particular approach to windows. In general, their primary windows will maximise by default, and they will lose their titlebars when they are maximised (smaller utility applications will not be affected by this). This will mean that the screen will be dominated by the window that you are focused on. It will also mean that the maximum amount of screen space will be devoted to useful stuff (like content).

Views

Each window of a GNOME 3 application can display different views, so that you can navigate to different parts of the app within it. Breaking up an interface into different views makes it more efficient and more pleasurable to use. It means that the content and controls that are displayed are always relevant to the task in hand, and means that superfluous interface elements are kept to a minimum.

The designs for the GNOME 3 Music app are a great example of this. It contains a view for browsing and a view for looking at a particular album, artist or playlist. Each view only contains content that is relevant to the current activity, meaning that each experience is enhanced, and that you travel through the application to the functionality that you want, rather than having it presented to you all at the same time.

Primary Toolbars

In GNOME 2, primary toolbars were like a toolboxes. They were a mixed bag, containing a variety of things that might or might not be useful to you at any given time. There was also a lack of consistency between apps, and the layout of toolbars often didn’t help you to understand their functionality. Together, this gave toolbars a high cognitive overhead and meant that they lacked visual elegance.

GNOME 3 primary toolbars are a bit different. They will only contain a few elements, and they will be much more consistent across applications, making them much easier to use. Their contents will also follow common alignment points, so they will look much nicer.

Primary toolbars in GNOME 3 also play a navigation role. They take over the job of labelling the view from the window titlebar, and they are at the top of the user interface’s hierarchy, framing content and providing key mechanisms for interacting with it. They’re object orientated.

Selections and Contextual Actions

The design pattern for making selections and acting on them is the result of a lot of work. It has been through quite a few iterations. Jimmac even created a whole series of html prototypes to help determine the best approach. There’s still one online that you can try.

Selections and contextual actions revolve around the checkmark button. Pressing it activates an overlay that allows multiple items to be selected and acted on using an overlaid toolbar.

The new design makes selecting multiple items possible without the need for a keyboard (since shift and alt modifiers aren’t required) and is touch compatible. Providing a separate space for contextual actions also guides users by providing a consistent mechanism for acting on content.

Search

Search can be an incredibly powerful tool, and it is central to GNOME 3 application design. Search will be ubiquitous and instantly available within GNOME 3 applications. If you are not editing a text field or a document, all you have to do is start typing to initiate a search.

Search will also be accessible using this nifty pull-down search design. This is a nice way of making search always available without having search boxes attached to every single grid or list of content. There are also variants of the design pattern that will allow you to use predefined filters on your content.

And more

There are many other application design patterns that we’ve been working on, including application menus, a new grid view for displaying collections of content, in-app notifications, new models for dialogs, nice full screen controls and a sidebar list pattern. Together, these provide the opportunity to create applications that efficient, modern, elegant, and a pleasure to use

The design patterns that I’ve introduced in this post aren’t the end of the story though. This new approach to GNOME application design is still evolving. We’re still testing the patterns we have come up with, and there are still missing pieces to this new application design approach. We are still investigating how to make maximised windows work well on very large screens, for example.

As the new GNOME applications develop, so will the design patterns. Everyone who is working on these new applications – both developers and designers – are helping to determine the shape of GNOME’s next generation of applications. And if you want to contribute you can also play a part.

Edit:

Judging by the comments it would seem that there is a bit of confusion about what is meant by maximising windows by default, so let me try and clarify:

Not all applications will use this behaviour – only those that have been designed to do so. If an app won’t work being maximised, it won’t be.

Although these applications will maximise by default, it will still be possible to unmaximise them. If you want to be able to view more than one window at once you will still be able to do so.

There will be mechanisms put in place that will adjust the behaviour to compensate for large screens. We are currently investigating a number of options here, including not automatically maximising windows on these large screens or adjusting their layout to make best use of the extra space. Everyone involved is well aware of the need to work well with large screens!

Hey Lionel! Good question. My advice for now would be: hold tight, and remember that we love you. 🙂 It shouldn’t be too hard to use these patterns for GTG, but there are still a few pieces that need putting in place. (It will also be easier once the new version of the HIG is ready.)

This is all great stuff. I really like the searching and the new item selection method. The one direction that I question is the elimination of minimization. I understand that each desktop shoulp have it’s own app but I’ve come across many situations where that became very cumbersome. Each of my desktops are dedicated to a task but a task doesn’t equal a single app. It might include many apps, some of which need to be minimzed. Has there been discussion about restoring the minimization functionality?

Except on a maximized window with the title bar hidden, you cannot access that system/window menu to minimize the window.

The same problem occurs when trying to restore a maximized window that does not have a menu bar and hides the title bar — there is no way to drag the window to restore it to a non-maximized state (I have raised a bug for this).

There has been some discussion about ways of ‘dropping’ applications to lower workspaces or bringing them back, but nothing like hiding applications. Of course, minimization is still there, and gnome-tweak-tool allows you to add the button back to the titlebar.

One think I’ve found useful with mice is middle-clicking the titlebar. This effectively drops the current window out of site without making heavy use of Alt+Tab.

From what I’ve read, the design team is content to leave minimization behind, but has been interested in effective alternatives since day 1.

Does a rationale exist for this somewhere? While I personally can just hit alt-F4 or set an alternate close-window keyboard shortcut, I wonder how you expect people to close windows under normal circumstances? When someone thinks “I want to close this application”, what thought process do you expect them to follow to reach a mechanism that allows them to do so?

Will the new UI elements/styling be available in the GTK+ API? I have noticed that you can get the joined buttons by using the “linked” CSS class in 3.4, but will things like the search bar, the selection behaviour and the prev/next/play/paused iconography be available?

I am also interested in how the layout of the Music application will expand when maximised on large screens in a way that is aesthetically pleasing. I could see that working if it went from a two-pane (info, playlist) to three-pane (info, playlist, lyrics) UI, otherwise there is too much whitespace.

It is not clear from the screenshot how tracks with long names will work — do they get clipped (with a tooltop)? does a scrollbar appear? I have hit this issue with my application and am using a tooltip. Likewise, for albums with a large number of tracks, will a scrollbar appear?

The screenshots of the Music application appear to be indicating which tracks will be played (showing the ones that will not be played in a light grey) and the currently playing track in bold. I like this, but I am wondering how user item selection works with this, especially when selecting “play just this track” / “play all tracks from this one until the end”.

My only concern with the maximized-by-default behaviour when using those apps on a large monitor with very high-res. Maybe apps should maximize by default only on displays up to a certain resolution? Just thinking out loud here.

Apart from the screen estate limit and going windowed that you mention, another path that we’d like to investigate is a smarter way to lay content out. Similar how responsive design works on the web, spanning accross multiple columns instead of one, providing direct access to the content list/grid while showing an item (instead of navigation). But indeed, high res displays pose a challenge.

I typically don’t even maximize most windows on my 14″ laptop screen (at 1600×900). For instance, if I maximized my browser window, the majority of websites would either have huge blank areas on the side (because they’re fixed width layouts), or be wider than I find pleasing. On something like a 1920×1200 monitor, I might want them to be about the side-by-side size, so that might work out.

The music application seems like it’s going to have a similar phenomenon. I’d have 60% more horzontal space, but it won’t do anything with it.

Anyhow, I don’t think you have to get particularly large to make maximizing everything unappealing, especially with the widescreen monitors that are ubiquitous these days.

Yeah, on my 15″ laptop (1680×1050) I never maximize anything. Which is as much to do with the aspect ratio as the window management issue… everything just ends up being too wide to feel comfortable, and for things like web browsers it’s mostly pointless, as no readable web page is ever going to take up the whole width of the screen.

Anyway, just as long as you don’t end up making a mess of the dual-display scenario, like Apple did with Lion…

I can certainly see why you might not want windows to maximise on very large screens. I’m not sure about your point about space being pointless though. Whitespace has its uses, and it is often better than noise.

@Allan Designed whitespace is a good thing. Whitespace that just happens to be there because there’s not enough content to fill the space that’s been designed for content, is really just a waste of space 🙂

(Or, to put it another way — a well-designed web page already has all the whitespace it needs designed into it. So just adding more whitespace by maximizing my browser gives me no additional benefit, and often just unbalances the page with too *much* whitespace…)

Allan, I think what they mean is that a lot of web pages, when maximized turns out to be column of text instead of taking up the real space. There would have to be something that changes the font dynamically to fill out the whole page to really make that work properly.

Otherwise, I get a maximized screen and only half of it is filled witih content.

Hey Sri, sure, I get that. What I was trying to get at is that (often, but not always) having other windows or wallpaper in view doesn’t add anything to the experience. That said, making it work for different screen sizes is a challenge and large screens are somewhat different. I’m confident that we can adjust the behaviour to accomodate that though.

The sad thing is you don’t even have to go that high of res to not want things maximized. I have a 24in monitor. One one virtual desktop I have Firefox taking up most of the space with a column to the right with empathy contacts and empathy chat. An another desktop I have a terminal taking up half the space and either a text editor or the application I’m testing take up the other half.

To me, maximize by default is a cop-out of design. A window manager that exposed tiling support + floating windows in an intituitive manner would be the ideal way I think. Two tools that help hobble it along currently are (1) Unity’s ctrl+alt+numpad which sizes and places windows according to which direction on the num pad you press and (2) A compiz plugin that would maximize to available space allowing you to place some windows manually and then take up the rest with the main one. To me an ideal solution would be how Visual Studio does window docking, providing drop spots for docking when moving windows.

On my system I usually either tile multiple windows or columnate my text. With three columns of text, you may even fit three screenfulls in one.
Not having to scroll is a surprisingly astonishing benefit, as you don’t even have to keep a hand on an input device anymore, but can just lay back and read. This is most useful for full articles, but even pages with shorter posts could benefit from comments floating to the left side as the viewport/window gets wider.
Columnating is a document viewer issue of course, but tiling the main raison d’être of window managers. Even on the Windows box I type this, I tile three windows so no overlaps another.

++++++, specially if desktops are to become more and more workplaces rather than media consumption areas…
Plus I disagree that a full screen app makes better use of space, fit’s law alone would say differently, each app has its optimum size, sometimes it might be full screen, (probably because its optimum size is bigger that your screen resolution).

I have the exact same issues with Gnome 3, it just doesn’t work well in a multimonitor setups or setups with high resolutions. And I really dislike the application menu moving to the top bar like a Mac. I understand what they are trying to do here, but I just don’t happen to agree with it, as not everyone wants a single function environment. I want my overlapping windows even it does waste space, I want my menu bars to be on my window, not up at the top. I typically have information from several sources on my screen at once and I need to be able to arrange my windows so that I can work effienciently with it. If the desktop is limiting what I can do, it will just result more swearing, as the task is already difficult and I don’t need to be fighting with the computer at the same time.

Just a general note for those with large monitors: you might want to try portrait orientation (though not if you watch a lot of video). I’ve had my 22″ monitors set up portrait for a year or so now and it’s miles, miles better than landscape for most uses. It particularly solves the ‘single column of text’ problem neatly: 1920 or 1680 is, as noted, far too wide for most web sites, but it’s never too *tall*. If you use portrait orientation, your width will be 1080 or 1050, which is just about right, and you’ll have a great big vertical view on the page – you can see far more text without scrolling. Try it, it’s great.

How will maximize-by-default interact with applications using the USPosition hint to specify user-supplied geometry, such as with the command-line -geometry option? Will the window manager respect that geometry, or override it by maximizing?

Please don’t forget mulit-monitor and high resolution systems. When “productive” is defined as “facebook”, maximized windows increase focus. When “productive” is defined as “browser for documentation and other windows for creating stuff” then maximized is a horrible idea.

The problem is that the window manager and application support for doing so will be neglected more than they already are. If the development of Nautilus is an example, what little support there is will be gone after a few releases. This isn’t really about multi-tasking so much as it is about having to use multiple tools to get a job done. Sometimes there isn’t an app for that.

Another random observation… without the buffer of the application menu bar or window title bar, some of those toolbar buttons are awfully close to the Activities and user menu elements of the shell, which I can imagine causing a few problems, especially on a touchscreen. And as well as making the toolbar buttons harder to access (by stopping them being Fitts-friendly as well), the top menu bar itself now looks a bit weird to me, because it’s so much narrower than all the other “horizontal bar” elements on the screen…

Please i really really dislike the maximized by default idea, well atleast put an option so i can change that behaviour. And regarding the fullscreen windows (Where does the menubar go?)
It start to look the Elementary project – and i tried it and really really disliked it. So please make these things optional.

How much does it make to make maximise the standard way to display window son high res monitors. Keep in mind that hdpi displays are on their way, and when you full screen almost any app on such a monitor the waste of space is enormous.
Even on the ldpi monitors shown above, the music app has massive amounts of useless space, Now, I am not advocating a “busy” interface, but these designs have to keep in mind that these displays are coming and when they get here, these maximised app interfaces are going to look odd.

Some of this looks great, but I’m the kind of person who likes to keep an eye on something muttering to itself in the background while I use an app, so I almost never maximise anything (I no longer need that for IM thanks to Empathy integration in Shell, but I have absolutely no desire to have that behaviour on IRC channels or terminal windows.

Therefore, I’d very much like to see an overview of how these applications look and behave when they aren’t maximised. Also, if I unmaximise something that’s maximised by default, will it remember that next time I start it or will I have to keep hitting it like with the stupid default news feed ordering on Facebook?

Recent versions of Epiphany already have the new look. If that’s any indication, when unmaximized, it looks pretty much the same except it gets a window title bar with a close button (no other buttons). It doesn’t get an old-school menu, the controls are still up in the Activities area.

Actually figuring out how to unmaximize is a bit of a trick: you have to alt-drag the window away from the top of the screen.

Make fullscreen the default behavior for screen sizes up to 13″ inches diagonal or so. For bigger screens, let applications be fullscreen by default only if they need to, like Blender. Otherwise you might as well call customers dumb for purchasing computers with big screens!

The applications need to be great for mouse and keyboard input, not for touch. Those two input paradigms are so different from one another that you can’t design one application and hope it will work great with both. It won’t. And on a technical perspective, you can’t even do mediocre touch interfaces with GTK, let alone great ones. Not even with the multi touch support that’s landing. Actually, trying to write a touch application with GTK should be a criminal offense in regard to all those that worked at creating amazing user interface technologies for touch at Palm and Apple.

And, it is not just that GNOME as a desktop needs a new wave of beautifully designed applications, but each one of them needs to be much better than what’s on competing platforms. It’s not worth spending time on crappy applications. I mean, take a look at Quicktime and Totem, it’s blatant that whoever designed one of them didn’t really care as much as they should.

My reply looks a bit harsh. But just consider the remote possibility I might be right 🙂

What about workflow where we need to refer to content from different applications? I often need to have two or three windows open on a large screen when writing reports or articles. Or typing meeting notes while in a video call and opening another document to reference. Somebody designing something may want to have a few mockups to reference also.

> I often need to have two or three windows open on a large screen when writing reports or articles.
Use the split-page view. Drag one document to the left, one to the right.

> Or typing meeting notes while in a video call and opening another document to reference.
Meeting notes in one window, reference to the right. Video call fullscreened on a different desktop maybe? It’s an odd usecase but the “doing one thing and using another as reference” is covered by the side-by-side functionality.

FWIW, being able to view a video, a reference document and write an essay on a single screen is a killer app. And no, manually resizing the video so it isn’t overscaled and carefully positioning and sizing each window so that all fit on the screen doesn’t cut it. Window management should be automatic.

A good desktop doesn’t optimize for the “common” behavior at the expense of punishing others.
No one is saying these problems are easy but these solutions seem…simplistic? That is, they only take into account the simplest use cases. Those cases, by their nature, are the easiest to deal with, regardless. It seems much time is spent on getting those cases, which are probably the most common, 5% nicer than they currently are while ignoring the rest to the point that are made 40% more difficult.
An interface that optimized for the complex use case would be difficult
but would also be interesting, and it wouldn’t mean that the consumption
oriented cases would’t also look great. As I said, by their nature those cases are easy to deal with.
I say this with nothing but hope because I use G3 and I just want it to be so much better. Currently it simply isn’t a compelling alternative to Win/Osx (not to say that it’s worse, mind you). It doesn’t make work easier, and sometimes it makes it a bit harder. Please, just consider that spending so much time getting that extra 5% at the expense of other common enough situations maybe doesn’t make sense. I know working on that extra bit of polish is fun, and doing something new is hard, but think about how proud you might be of the end result!

Hi guys. I us a similar setup using openbox + tint2. It doesn’t have any polish at all but it works great. I could not use gnome 3 because of the way it handles windows and title bars are a waste of space, but I created a nice setup anyways. It would be great to see gnome take the same route. [Screenshot](http://i.imgur.com/pRRhb) and [Github](https://github.com/demizer/dotfiles).

I was a happy Gnome user from Red Hat 6 (1998ish) till Gnome 2.32. This full screen approach seams to work well for devices which have screens the size of my Nook, but never for my 27″ home monitor, or my 30″ work monitor. There is nothing you can say that will convince me that running full screen apps is better, or helps ones focus, or better utilizes real estate. How many people have the gnome foundation alienated? Was it worth it to shit on your best cheer leaders? I seriously doubt that gnome is going to ever go anywhere when every 8 years or so they throw away the whole thing, and start over from scratch. You’ve lost me as a user, and advocate to your technology.

So, important question. Will there be at least a partial HIG available for GNOME 3 before we finish building this new paradigm of design? I really want to get started, but my designs have very much been in between GNOME 2 and GNOME 3 (search in the toolbar at all times, Application Menu instead of menubar, small content icons in view, etc.). It all seems like a hodge-podge of ‘modern’ approaches, so I’d like to just start anew on something that’s fully GNOME 3-ified.

After reading your reasons for many of these changes, I feel a lot more comfortable with them (the part I love is the ‘just start typing to search’- I almost thought I’d have to drag that bar down with my mouse!). I’m a bit concerned about my grandmother finding out how to close a maximized window, especially since the application is maximized by default. The quickest way would be to click and hold on the Application Menu and release on ‘Quit’, or a keyboard shortcut. I think we’ll definitely have to iterate this to find the optimum solution.

However, with this style, GNOME 3 will run very well on tablets, as well as providing a richer experience on laptops. I think we’ve found a golden combination in these designs. With this, we can have a tablet OS that’s more functional than iOS, and a desktop OS that’s more elegant than OS X. It’s all coming together better than I could have dreamed.

We have to start somewhere. Of course, we could just leave it to WebOS since it’s open, now. I think there is a lot of unexplored value here, though. There are plenty of great options for people if they don’t want to go with the GNOME stack, so I think it’s a risk worth taking.

mazz, I’d recommend that you read my blog post on touch, if you haven’t already. It discusses why we need to have applications that are designed for desktops and laptops but are also touch compatible. Designing for touch can actually enhance the ‘desktop’ experience.

And anyway, I don’t speak and understand English at all, and I could not have grasped the meaning of your post, but from what I undersood, the work is focusing to prepare for new devices, which should integrate different types of input devices (multi-touch, keyboard, pointer). But does that penalize users of classic desktop that won’t able to benefit from this combination of input devices?

If one of the overall design goals is to have fewer windows sitting on top of each other in a stack and reduce wm chaos, I think that the Gnome Shell team needs to embrace more efficient tiling to make the UX fit screens across a variety of resolutions. The gTile extension is imho the best effort so far:

Sounds good! Tiling window managers have been available for some time, surely there are benefits that can be incorporated into GNOME 🙂 Would be the right time to look at them also, because I think that tiling has design consequences: applications need to look “good” and remain usable regardless of how they’re tiled (very narrow when tiling side-to-side or very squashed when tiling top-to-bottom), although given the minimalist design mockups, this shouldn’t be too hard for GNOME applications.

The problem with that extension is that it is a bit hard to use, and it doesn’t make the necessary changes to the window’s chrome. So, the more windows you tile, the more wasted space you have.
That said, tiling is something that should be used by default. They just need to use window hints and screen size to create initial layouts and remember how the changes we make. IOW, the WM needs to be loads more sophisticated. Not easy, but it should be a goal b/c it would end up auto-optimizing itself over time based on the changes users make.

Hi, I like your blog because it provides some clues on the reasons Gnome has chosen to go the way it is going. I wish you luck, but I also hope in 5 years time you’ll look back and realise that you made som big mistakes. For one thing, I believe you rely on assumptions about what is best for the user or what the user wants that certainly do not hold true in my case, and I suspect many others. For example, I work with many windows open at the same time, some overlap, some do not, I type things in one window and it causes something to happen in another window. I want to manage windows myself, and I do not want some software do it for me because it will do an awful job. It seems to me that the new Gnome is making things a lot more difficult for people like me who do not use GUIs the way Gnome thinks we’re supposed to. I’m just saying this as an opinion, do not take it badly please.

Nobody said that you no longer can have overlapping windows. The “new apps” are just maximized by default. The windowmanager will work as at always did. You can move and resize windows; have them overlap; tile them etc.

I see no improvement in displaying lots of empty space in one maximized window, hiding all the other content that should be visible (and would be, were the active window not maximized). This gets worse the bigger the screen. The screen could be virtual (Xinerama) as well.

for selection i think the checkboxes are nice but it would be even better if it could be allowed AT THE SAME TIME to do rubberbanding and use space to toggle selected/unselected for several items at once.

Maxmimze by default is a huge fail. I often run something in one window (for example, pulling payment information out of our accounting database) and copy/paste it into another (an OpenOffice spreadsheet, for example.)

I do not use GNOME regularly. I prefer KDE. I have tried GNOME Shell for weeks at a stretch, but cannot get used to the full screens.

I multitask. I have a big monitor. I drag and drop. If I am in the GIMP, I often have my file manager or RAW image editor open as well. I like to compare photos, side by side. On the internet I often copy and paste and have multiple applications open, posting a photo or video from one application, previewing it in another, etc. I cannot get a workflow that satisfies me in GS. I have tried and it just does not suit me. It seems to be way too much effort (too many mouse clicks, too much typing, too much time to transition from mouse to keyboard, etc.).

Things are big, yes, but often too big. My eyes are not bad. I do not need large icons and large text boxes or everything to the maximum size. I do not get it. I am in GS now but find myself resisting the urge to logout and into KDE.

If it is any consolation, I find the same things about Unity. I see the design of both GS and Unity to be a huge step backwards. Users should not be required to type anything to use an user interface and mouse clicks should be kept to a minimum. Both DEs seem to be of the mind that users want to remember keyboard shortcuts, type commands or Alt-tab to switch between applications which are set to run at full screen. Unity is better in that it can manage windows better, but then you have to deal with the global menu. Both seem to think that users have tiny screens and only can manage one thing at a time.

I’ll keep checking and I always have an open mind to changes, but the bottom line for me is getting the most done with the least effort. GNOME is the least flexible DE for me.

Gnome Shell can already do windowed applications very well, you can overlap them and create as big a mess as you want.This new ‘maximized windows’ direction is not removing your ability to do windowed apps. It’s just maximizing your apps on launch.

Arguments over whether you want your apps maximized by default or windowed by default seem silly. It’s just as easy to argue the other side. “Why does my application start windowed and then I have to interact with it to maximize it every time”.

This new direction does not “hurt” large screened PC desktops and is pretty much a requirement for small screened tablets or phones. So it seems a no-brainer.

Personally since using Gnome Shell I’ve changed my windowing habits and now live mostly in 50/50 split window world and the rest of my windows are often maximized. My desktop feels clean and organized. I use a 1920×1200 24″ monitor and do software development (in Vim).

I imagine my behaviour once the ‘maximized windows’ arrives will not take much adjusting. I will start an app (maximized) and in many cases immediately grab it and slap it to the left or right side of the desktop for 50% width view.

I am presuming though that the same behaviour from 3.2 to unmaximize a window stick around? i.e. pull the window by the “top” and have it unsnap from a maximized view and let me move the window freely around? And can I still do the opposite; drag a window to the top of the screen to auto maximize? I love those paradigms. They feel natural and quick.

Agreed- organization is phenomenal in GNOME 3. We should have the program remember the last mode/size your window was in, of course, as we do now. If someone always wants ‘Web’ maximized, they won’t be pulling it down (if they do, it’s an easy fix). If someone pulls it down, they likely don’t always want it maximized, and won’t care to bring it back if they did it mistakenly.

Keeping it maximized despite changes every new start, not merely the first, is of course a very illogical decision. I hope that’s not what’s going on- it’s very unclear to me.

So I built 3.4 from jhbuild the other day and I’m really satisfied with regards to the window management. Like really, really satisfied. Great work there!
I also enjoy everything maximized. I never understood the deal with overlapping windows. 🙂

I really like the design of the gnome 3 apps, especially that the apps look clean and not cluttered (which is why I originally switched from kde to gnome some time ago). However I also see the problem of wasting space on “large” screens. Even on my 13″ laptop I do not always maximize windows but I’m heavly using the automatic tiling function. I also see the problem that you should not add functionality just to avoid white-space in fullscreen mode.

For the music app (and this might be applicable to other apps as well) I could imagine that the app is divided into separate modules (e.g. playlist view, library view, now playing view, album view, …) and depending on the size the app shows different modules. e.g. if the window is “small” then the app should look like in your mock-ups. If the user enlarges the window the library view could appear on the left. For the mail app you could show the folder few. Well, not sure if you understand what you mean.

Another concern that I have is that you should not make the laptop/desktop pc a second class citizen. I think it’s a good idea to think about howto use the apps on touch screen devices, however having to use the mouse to click on a symbol in the corner and then go back to select items is really a touch-only solution, imho. On a laptop you should also support the traditional Ctrl/Shift/whatever selection method.

Besides that, I like your approach a lot and I’m looking forward to seeing these apps come to life.
Michael

Hi! Sadly to admit it, but Gnome goes farther and farther away from the real world into the world of fairies, elves and tablets. What’s even more upsetting is the fact that developers seems not high opinion on mental faculties of users. Simplification of anything and everything probably will be enjoyed by children and grandmothers, but alienate those who know how to use a computer and, moreover, use it not just for sitting in Facebook, but for some serious work.

Moreover, all presented mockups are clearly designed for tablets and are totally unsuitable for the desktop. For example, that’s how the new interface would look on my display: http://postimage.org/image/uq8ij9l8r/ and that waste of screen space for sure.

I apologize if my post sounded rude, but it has already become painful – OS X, Windows 8, and now Linux desktop environments – all become crazy about tablets… Soon, normal people would have nothing for comfortable work.

The only thing I really like is fact that developers have finally decided to make the system look more pleasing in the details.

Hey Gris, not sure whether you noticed it or not, but read the adendum I added to the post – the plan certainly isn’t to maximise on all displays without adjusting the window layout. We’re still evaluating what the best solution will be, but whatever happens it won’t be like in your mockup.

Ah, I see now. In any case, I think it would be better if user will be able to choose behavior of environment (behavior of windows, application menu look and placement etc.). In addition, it would be nice if the settings can be switched to “advanced mode”. This way you could meet the needs of both beginners and experienced users (as is done in VLC, for example).

Good thing that the look & feel of Gnome is finally becoming competitive. =)

Maximizing windows by default is a wrong approach for a screen > 7″!
It’s a huge step backwards (20-30 years), because the whole idea behind windowing was to make many things visible at the same time.
For example, I always like to keep 3-4 windows visible. I NEVER maximize my browser (and that’s why I do not use unity… I hate, when unity maximizes firefox automatically and I can’t turn off this kind of behavior).
I always try to choose the window’s size so, that I see only relevant information.

And as mentioned above… try better to integrate gtile and make it better.

Even on smaller screens, “maximized” often is a poor experience. On a tablet as big as an iPad, a lot of applications could comfortably share the screen with another, letting me more easily keep two things in context. And on my laptop, I frequently want to view a bit of one application at the same time as I watch another. And the applications that have a lot to display, and thus benefit most from “maximized by default”, are the very ones that I want to share data with (spreadsheet, email client, word processor, browser).

It is true that a *phone* can generally only comfortably show one application at a time (if that!), though some are pushing the envelope on that.

I admit that I’m happier with Gnome 3 than I thought I’d be, but I still think it was designed by people who never used it, and certainly by people who don’t think about things like the motions involved in a command (making us move the mouse from one extreme to the other for simple tasks). And Gnome 3 designers had a huge blind spot for people who remember where things are kept or what they look like, but not what they are called.

This doesn’t make sense for a lot of applications. Maximising skype would be unhelpful. Maximising my audio player, also unhelpful. Maximising my file browser, sometimes unhelpful (drag and drop file Im looking for into program I am currently running).

Mostly, the logic is to restore the last user’s session. I hope this would not be overridden

On my 1920×1080 I never maximize. I adjust Firefox width for two or three sacades per line. Then I may have a terminal 80 characters wide displaying a man page, another below it to compose a sed command, a fourth text editing an input file, a fifth viewing the output. I want to see them all at once and for each to have its menu in the window. Global menus are not workable. Automatic maximize when I drag a window to the top is really annoying. I need the close, minimize, iconize and roll up. I need to suspend, hibernate, restart or shut down with no fuss. So Gnome Shell, and Unity are both useless to me. I have taken refuge in the currently sane XFCE.

Bear, did you fully read the blog post? I did say that we are still working on getting the right behaviour for large screens. We might not even do automaximisation on these types of displays. Also, this has nothing to do with GNOME Shell – the maximisation behaviour is specified by individual applications.

I just got here when googling about gnome3 apps… Is there any plans to create a “libgnome3” (i know people hated libgnome2) to make applications with these styles easier ? At least every project i know are embeddeding a lib called gd to easily get one of these styles.