As a long-time GNOME module maintainer and as a team lead within Red Hat, I often get people coming to me for advice about some technical issue or another. And no matter the issue, there’s one question that I’ll almost always end up asking at some point: “what does the user see?” Code, APIs, protocols are all just means to the end-user experience. Discussion of the future of GNOME should also start with what the user sees.
Mark argues that GNOME should be a place where we have internal competition. But his idea of internal competition seems to be competition between different end-user experiences. His entrant into the competition is Unity, an environment with a user experience designed completely in isolation from GNOME. The other entrant would, I suppose, be the GNOME 3 desktop that GNOME has created.
This competition doesn’t make sense to me: what would be left of GNOME if Unity “won” that competition? Not even the libraries are left, because every decision that is made about what goes into library should be driven by that same question “what does the user see?” No widget should go into GTK+ unless it makes sense in a GNOME application. GNOME cannot cede the user experience and still work as a project.
The sort of internal competition I’d like to see within GNOME is competition of ideas. Competition of mockups and prototypes, and even entire applications. We know that we need better file management within the GNOME Activities Overview for 3.2. Is that organized as a timeline? Does it involve tagging? Is it best implemented with Zeitgeist? With Tracker? With both? Those are things that are still open, and the more people that are working on different designs and approaches, the better off the final result will be.
The basic constraint of any sort of internal competition within GNOME is that you have to be willing for some of your ideas to win and some of your ideas to lose. If you are starting out with the premise that you have complete final control over the user experience, then you aren’t working on GNOME, you are working on something else. So far, this seems to be the approach of Canonical. In the past, they took GNOME, modified it, and presented the modified result to their users. Now they are taking some GNOME libraries, building a new desktop on top of that, and presenting that to their users. But I’ve never seen Canonical make the leap and realize that they could actually dive in and make GNOME itself better.
Diving in means a commitment – it means fighting for your ideas at every step of the way, from the design level, to figuring out how the code pieces fit together, to the line-by-line details of the code. But the thing about open source is that the more you engage at this level with a project, the more you win. You become more in sync with the other contributors about end goals. You learn how to communicate with them better. And soon enough you no longer think of yourself as an outsider. You are just are another insider.
Make no mistake: I’m very sad to see further splintering of the Linux desktop. I think GNOME 3 is going to be amazing, but how much more amazing could it have been if the design and coding talent that is going into Unity could have been pooled with the work being done inside GNOME? An application developer can create an application that works both within GNOME and within Unity, but we’re adding extra barriers to the task of creating an application for Linux. That’s already far too hard.
No matter what happens, all desktops on Linux need to continue to work together to try and provide as much cross-desktop compatibility as possible. But we have to realize the limits of freedesktop.org specifications and standards. Many of the early successes of freedesktop.org were in places where there was broad user interface consensus. Drag-and-drop of text from one application to another made sense in all toolkits, so we made it work between toolkits. But if there isn’t consensus on the user experience, then the specification isn’t that useful.
For example, appindicators start off with the proposition any application should be able to create an icon with a drop-down menu and make it a permanent part of the desktop. (I’m simplifying somewhat – the original Status Notifier specification leaves the user experience quite unspecified, but that’s the way that Canonical was using the specification.) If you don’t have that user interface concept, it’s not clear how the spec helps. So that’s what made the Canonical proposal of libappindicator strange. They didn’t engage with GNOME to make the user interface idea part of future designs. They didn’t even propose changes to core GNOME components to support application indicators. They showed up with a library that would allow applications to display indicators in a modified GNOME desktop, and proposed that GNOME should bless it as a dependency.
(From the GNOME Shell side we were never considering whether appindicators were useful for their original designed purpose; we were considering whether they were a useful way to implement the fixed system icons we had in the GNOME Shell design. In the end, it seemed much simpler to just code the fixed system icons, and I think that decision has been supported in how things have turned out in practice. We’ve been able to create system icon drop-downs that match our mockups and use the full capabilities of the shell toolkit without having to figure out how to funnel everything over a D-Bus protocol.)
So, by all means, we should collaborate on standards, but we can’t just collaborate on standards for the sake of collaborating on standards. We have to start off from understanding what the user sees. Once we understand what the user sees, if there’s a place to make an application written for one environment work better in another environment, that’s a place where standardization is useful. Of course, the more that designers from different environments exchange ideas and go down similar user interface paths, the more opportunity there will be for standards.
Is collaboration on standards and on bits of infrastructure, and friendly exchange of UI ideas the way forward for GNOME and Unity? Are they completely separate desktops? Perhaps it’s the only feasible way forward at this point, but it certainly doesn’t make me happy. Mark: any time you want discuss how we can work together to create to a single great desktop, we’re still ready to talk. Design choices, technological choices, the channels and ways we communicate in GNOME, are all things we can reconsider. The only thing to me that’s untouchable is the central idea that GNOME is ultimately about the experience of our users.
fishsoup 
29 Comments
Hi Owen,
As always, a wonderfully written and thought provoking piece, sourced from an extensive body of knowledge.
I would love to see solutions to these challenges, and I would love to see more collaboration at the design and technology level. It feels to me like tensions are too high on this topic right now, but in a few weeks when things calm down a little and everyone has their heads back, I would love to organize some calls to see what opportunities we can find to collaborate better.
Keep up the great work. 🙂
Jono
Way to go, Jono! That’s the spirit! 🙂
Yeah it’s really sad all that time is spent on unity instead of gnome3. Still sure gnome3 will be awesome though! I’m still blown away from time to time of how awesome gnome 2.30 is. 🙂
Unity is a shell, so it competes with Gnome Shell, not Gnome 3.
AFAIK, GnomePanel is another shell too so there is already internal competition here.
Be sure that at least some people don’t like Gnome Shell. I personally welcome this competition and every new comer (not only Unity but also Elementary’s “Pantheon”).
Gnome should see this as an opportunity, a way to extend it’s diversity/possibilities and so it’s potential market share.
And if internal competition is that bad, why Banshee and Rhythmbox (2 similar music players) are both part of the Gnome Project? Isn’t it internal competition?
The only alternative to internal competition is external competition. Actually, I’m sure this would be the worst thing for everyone.
This is a common misperception. That somehow the work we’ve done on GNOME Shell is somehow separable from the rest of GNOME 3. The work on the GTK+ theme and the window manager theme is done on together. The work on GNOME Shell is done together work work on System Settings and on the internal gnome-settings-daemon and gnome-session components. Of course, you could replace GNOME Shell with something else, but in order for the whole to be coherent that “something else” would need incorporate many of the same UI ideas we’ve implemented in GNOME Shell. The gnome-panel we’re shipping in GNOME 3 to use in fallback mode has many changes that make it, in some ways, more like of a no-acceleration version of GNOME Shell rather than an exact copy of the GNOME 2 panel.
The developers of Unity certainly understand that it all fits together on the design level – if you look at discussion about what the Unity developers are working on, it’s not just about launchers and window managers, but involves all sorts of stuff that extends down to applications – how scrollbars work, how menus work, how you quit (or don’t quit) an application. There’s no disagreement, I think, that the UI of the desktop has to be designed as a whole. The question is where that design is done. I think the design has to be done collaboratively in the GNOME project in order for something to be considered truly a GNOME desktop.
“it means fighting for your ideas at every step of the way, from the design level, to figuring out how the code pieces fit together, to the line-by-line details of the code” I think it’s there you’re wrong. That’s why the Ubuntu community is so much growing, it’s because you do not have to fight and fight always for your idea. You propose it,(on the ayatana mailing list, example), it’s discussed, and if it’s good it can be adopted. In your approach, it seems to be a wall you always have to climb, and it seems to be what canonical reproch to Gnome. They think they are not enough “open minded” to new ideas. They proposed app indicator as an external dependency, but was rejected (it was just an “EXTERNAL dependency”, and there lot of bugs reports, coming from canonical ( from didier roche example), wich are in bugzilla, and never get any comment, status changes… nothing. Is it because they didn’t fight enough ?. Doesn’t it seems stupid? Then I think canonical made mistake, a lot, too. They often correct them, even if i think it’s too late (Banshee case example). I personnaly actually use Ubuntu. I tried Unity and Gnome Shell, I love them both. The only thing wich help me choose Unity is because of Ubuntu One that doesn’t exists on others distros ( it’s the fault of canonical not working to port it? but they do not have time, with so few employees. It’s the fault of others distros, of Gnome, because they didn’t do it? But Ubuntu one client change to fast, so without canonical help it’s too much work. Here is what I really would like. Not to see canonical nor Gnome winning, nor loosing. It doesn’t make sense. It’s to see them both, and with KDE too, showing they are adults, and sitting around a table, and discuss, as civilized peoples. Because today, they are more like two dogs fighting, and they are both ridiculous.
Your right that “fighting” implies a level of unpleasantness. I don’t think that unpleasantness is usually there in the GNOME community – certainly flamewars have occurred, but in general, personal nastiness is simply not tolerated. So, you can read “engaging” as a softer alternative. The point is the same: you have to be willing to work closely with the other people in the community to get your work in. A piece of code or an user interface idea won’t be make its way in just because it’s out there to be harvested. This is true of every open source project, not something that’s distinctive about GNOME.
Jono,
Instead of private calls how about some form of communication that can be _archived_ for digestion by people not in on the call. A call run as a panel discussion would be perfectly fine…as long as the discussion is archived for consumption by those not on the panel.
if you run a set of private calls, how can you be sure that all the people who need to hear the discussion are going to be on a small group call? How can you be sure that the views expressed are faithfully re-broadcasted into the respective communities unless the discussion itself is archived? Transparency sort of matters..it sort of matters a lot.
-jef
In Dave Neary’s own detailed analysis, he also notes that too much is done “off the record” and how damaging it can be later on.
Too often the approach of some people here seems to be “right, let’s organize a call, send me your Skype ID” or whatever.
Why can’t it happen in the open? This is a public collaborative project, there shouldn’t be the need for so much to happen behind closed doors.
Interestingly, it quite makes sense that if GNOME didn’t subscribe to the visualization concept proposed by the Canonical folks that they choose to implement their own concept of visualization. But, as you acknowledge, the proposed spec does not specify visualization. That was on purpose: To accommodate different UI/UX visualizations.
It is simply not meaningful to talk about this proposed spec and fd.o in general and only talk about Canonical and GNOME. The spec was proposed by folks from KDE. Oh how I would like the status icon of the KDE app that I develop, be properly integrated into GNOME Shell status/notification areas without violating all the hard design work that clearly went into the way status and notifications are visualized and without having to maintain separate code paths.
The spec can be modified, improved or a counter-proposal offered. If there are specific areas where the proposed spec has limitations that might outweigh the benefits, then it would be nice if *all* interested parties, not just Canonical and GNOME, could work towards consensus or compromise. Again, that does not necessarily have to mean GNOME accepting libappindicator. It just means implementing a common spec to keep the application ecosystem from fragmenting around status and notification handling. There are working, real-world examples and use-cases already available that show substantially different visualization approaches and which could serve as concrete starting points for such a discussion. It-won’t-work and imagined-far-corner-case responses that no-one has ever implemented or expressed any desire to implement are less helpful to that end. (Those problems tend to take care of themselves anyway. Some crazy WM developer could also implement a design that destroyed the window when the maximize button is clicked. I can’t imagine many reasonable people using that WM.)
I want to believe this can be eventually be resolved without a permanent forking of the way status and notifications and other issues are handled. I want to believe that the more general issue of collaboration can be resolved. I want to believe that this will happen, even if the issues between the GNOME and Canonical don’t sort themselves out soon, though I genuinely hope they do.
I really don’t want to spend a lot of time talking about the history of appindicators because it’s been pretty much discussed to death. If Canonical had been helping us write GNOME Shell in 2009, and wanted to work on that part of the puzzle, they would have been free to use it as a technology. Without that assistance, we had to make our best technical judgement.
Beyond that, I’d take a patch today (ok, not today, but after GNOME 3 gets out the door) that added support for displaying Status Notifier notifications in the GNOME Shell message tray as a configurable optional dependency. We already display system tray icons there, and Status Notifier icons with a menu would work slightly better than that.
But the gigantic caveat there is that putting a Status Notifier icon in the message tray does not produce a good user interface experience. It doesn’t produce the user experience that someone writing a KDE app was expecting – perhaps they thought that the user would be able to see when the icon changed, and the user can’t because it’s hidden by default. And it doesn’t match the user experience that the user gets for all the other icons in the GNOME 3 message tray. The icon isn’t paired with a banner that popped up when the event or the activity it represents started. So even if we had this support, it doesn’t make the app authors life any better – they still can’t write one piece of code and use it across desktops and get perfect integration. The only advantage is presenting the user with some fallback if the app author hasn’t tested on GNOME.
(I’m likely going to get pushback on accepting such a patch because it does make it easier for authors to ignore the issue and present their users with a suboptimal user interface within GNOME, but I’d take such a patch anyways.)
Correct integration with GNOME Shell is achieved by the notification specification, which is a cross-desktop specification as well. We certainly haven’t done a good job discussing the small additions to the specification we needed, but it’s not at all hard to write an application that use this specification to work correctly across desktops.
Just thinking about this… I don’t know the details of the spec, so i don’t know if this is possible, but what if when an icon changed, the the message tray made the changed icon visible for a few seconds?
> perhaps they thought that the user would be able to see when the icon changed, and the user can’t because it’s hidden by default.
That’s what the spec has a way for the app to say the icon should be automatically unhidden for. Plasma’s system tray also auto-hides inactive icons.
Now the spec doesn’t REQUIRE you to follow the hint, but to give the user the experience intended by the application’s author, you really should. At least unless the user asked you to do otherwise. (Plasma allows the user to force an icon to always shown or always hidden.)
I spent an hour or two looking at how much work it would be to implement the status notifier specification in GS. My conclusion was; to implement the spec as written would be a few days. To implement the associated DBusMenu spec that is now heavily used would be a few more. To untangle all of the (AFAICT) undocumented org.ayatana services and additions to the spec, and see if it actually works with random libappindicator using applications – who knows…
Thanks so much for taking the time to explain some of the concerns. As an app developer I’m mostly hopeful for common specifications. Like you, I’m far less interested in the bikeshed of the history libappindicator.
The Status Notifier icon isn’t necessarily shown in KDE by default either unless the app provides the appropriate semantics in the data that the visualization uses to decide when to show/hide it. In fact my app uses those semantic to respect the visualization preference for hiding certain icons. So if there’s a visualization need to hide the icon, maybe those semantics are shared across environments. Maybe some agreement can be reached on enough issues and the spec potentially updated to accommodate those needs. Maybe any overlap that may exist between the the Status Notifier spec and the notification specification can be cleared up and some agreement can be reached on using the appropriate common specification for the appropriate purpose.
Anyway, we can’t and probably shouldn’t attempt to resolved these issues here. However, based just on this exchange alone, I’m convinced that there are less fundamental differences here (at least with respect to the specifications) than are insurmountable. I look forward as an app developer to the positive future improved collaboration between GNOME, KDE and others.
peace and much respect.
It sounds like that’s something someone would want to explore when adding compatibility support for Status Notifier specification to GNOME 3. We already show the tray briefly when a legacy System Tray icon first appears, we could definitely do the same thing if a Status Notifier item transitions to the Requesting Attention state. But that still doesn’t really give the user experience we’ve designe. We don’t the user to look down and have to figure out what icon appeared and then click on it to see what happened, we want to the show the user a banner that allows them to glance down, see what happened and either react to it immediately or go back to their work. Could you build additional protocol on top of the StatusNotifier specification to create this experience? Yes, definitely, in the same way that the DBusMenu protocol was built on top of the StatusNotifier specification to give the ability for the container to use a native menu. But that wouldn’t give us cross desktop compatibility for applications until and unless other desktops thought we had a great user interface idea and copied our lead. We thought it was better to build from the notification specification. The notification specification already was connected in other desktops to an experience pretty close to what we wanted.
I thought the spec. allowed for changing of states that the tray could then respond to, e.g. an icon that wants attention. The icon asks for attention and the tray decides how best to implement that. Failure to implement that at all isn’t a weekness of the spec., as it already works in Ubuntu and KDE quite sanely: Ubuntu changes the icon colour (as tray icons are always visible), KDE automatically hides and shows the icon. If anything, this is a GOOD thing: it lets you guys, as the people writing your workspace, decide how the icons should behave with regard to the rest of your desktop. If the icon is autohidden (which is up to you to choose) and doesn’t show when it requests attention (which is up to you to choose) or respond in some other way when requesting attention (which is up to you to choose), then the failure is in your implementation, not in the spec. or the developer’s code.
As a user I must say I love Unity and Gnome Shell and I believe this post is a real attempt to talk in the open to folk on Canonical and KDE and look for solutions regarding all this trouble. I would love to see some ideas from Unity in the Gnome Shell. Currently I use Unity most of the times because it fits my work-flow, but it would be nice to see some agreements in some point to make both shells become one or to improve both of them, at the end we the users would be very happy to see both Ubuntu and Gnome flourishing.
“The only thing to me that’s untouchable is the central idea that GNOME is ultimately about the experience of our users.”
Sorry, put that’s bullshit. There’s a whole mailing list (gnome-shell) disproving this: whenever the users’ feedback wasn’t positive, you just ignored it. Just see how many people in the last two years suggested that they weren’t comfortable with the new shell’s methods for switching applications and how they were ignored or badly treated.
I’ve been using gnome for years on all my computers, and I’m sorry to say I also moved to it relatives, friend and co-workers, but my feeling now is that Gnome is about the holy design document, not about the users.
My opinion about Gnome and Canonical, is “a plague on both of your houses.” I’m using ubuntu now because they’ll keep 2.32 for the next release, after that I’ll move to another distro and DE, unless bot gnome shell and unity crash and burn and they bring with them all these self-described designers and ui experts.
We know pretty well how to make tech savvy users happy. Make something that is highly customizable and highly tweakable. Which accommodates many different patterns of use. However, that doesn’t necessarily create a great desktop for everybody. We’ve pushed hard with GNOME 3 to figure out something that’s more streamlined. Where you can pick it up and immediately start using it in an efficient manner. And I think that’s where a lot of the feedback you are seeing comes from. Because when you start asking GNOME 3, you’ll be frustrated if the first question you ask is “how do I make this work like I think a desktop should work”. The question we want people to ask is “how does this work”? We hope eventually to cater to people who want to customize with the extension system, and certainly some people are already tweaking GNOME 3 to their needs with it, but making the extension system really slick and obviously available isn’t something we’ve been able to put the cycles into at this point.
Now, most people on gnome-shell-list realize where we’re going. It’s been pretty much the GNOME mantra over the last 10 years that more options, more configurable isn’t better, after all. A lot of people just have their own ideas about how best to streamline the user interface. These are often great ideas, but it’s been pretty hard to find the time to try and harvest from them. Design is a bit different than code. If someone wants to completely reorganize the code-base they are going to have to put months of work into it, and they are unlikely to start doing that unless they’ve discussed it with the project. But a talented individual can produce a slick polished mockup in a weekend that implies a complete reorganization of the user interface. It’s still going to take months or years to implement. Incrementalism is key. gnome-shell-list hasn’t worked out too well as a venue for design contribution, and we’ve really been encouraging people who want to help out on the design side to join the #gnome-design IRC channel. See what people are talking about, bounce your ideas off other people, see what makes sense and what doesn’t make sense in the current context.
And almost certainly in some areas we’ve made mistakes in the GNOME 3 design. Big changes imply mistakes. Moving forward from GNOME 3.0 we’ll need to keep the good ideas and identify fix the mistakes. But in the end, the point is that we should be judged on the user experience. Not on what libraries and protocols we’re using.
@Giacomo: you don’t design for everyone, because that leads to a mess of conflicting design tenets. at the end of the day, if you feel you’re not the intended target user, then there is nothing the shell and the design teams can do.
by the way, passive-aggressiveness like “I’ll have to switch to another environment if $THIS doesn’t happen” does not put anyone in their best mindset to help you. at some point, anything you use will not suit exactly your workflow — most of us just re-adapt themselves, taking advantage of features to improve the workflow.
at no point the GNOME maintainers will put a gun to your head, and force you to keep using GNOME; there are lots of other projects — use them; and, much more importantly, contribute to them.
Is everyone forgetting, that when we saw GNOME Shell proposed (we users), we said, “no.”?
Did everyone forget that we suggested as a majority, to explore something else? Did no one realize that there isn’t much excitement behind this, because we are tired of Open Source Project teams just ignoring such feedback?
It’s too late now for any change to come of the situation, but hopefully in future, when the community lends their opinions and such, it won’t be falling to the ground 😦
Even if Unity never existed, there would be one big internal competitor – GNOME 2. What users currently see, is a major break from GNOME 2. I wonder, was the work on GNOME Shell preceded by usability research? Are the result available somewhere?
GNOME 3 is a pretty big break from GNOME 2; it’s basically a new design. So detailed usability research on GNOME 2 isn’t necessarily directly applicable. That being said, results of user testing on GNOME 2 and the areas that have been shown to be problematical – such finding applications or navigating between workspaces – were definitely one source of design inspiration, along with published academic research and a broad study of the user interfaces of different operating systems.
I’m just trying F15 with GNOME 3 and I must say it’s pretty and seems to evolve into a really nice GUI. I can see ordinary people love it. Two things: we need “Places” (or something) so that we don’t have to find Nautilus/Files manually. “Places” was a great feature of the old GNOME. Another idea I had was to let the panel on the left hover in when we touch the left of the screen. This would allow quick opening of new apps and switching to already open ones without having to resort to “Activities”.
> (From the GNOME Shell side we were never considering whether appindicators were useful for their original designed purpose; we were considering whether they were a useful way to implement the fixed system icons we had in the GNOME Shell design. In the end, it seemed much simpler to just code the fixed system icons, and I think that decision has been supported in how things have turned out in practice. We’ve been able to create system icon drop-downs that match our mockups and use the full capabilities of the shell toolkit without having to figure out how to funnel everything over a D-Bus protocol.)
So considering these applications work in Plasa, if I’m a KDE Workspace user how will these icons display? Will they display at all? Will they be themed by Plasma, have Plasma tooltips and use Qt-style menus? Will they auto-hide and auto-show in a sane manner? Or will KDE have to implement your specification, despite having a specification that is tested and proven to work?
Fixed system icons are icons for things like power, volume, bluetooth, networking. They aren’t applications, they are bits of UI that usually tie closely into the GNOME System Settings application. We would expect KDE to have its own ways of doing the same things – e.g., even when it was possible with the system tray protocol, KDE wasn’t using the GNOME network manager applet.
Yes, but that doesn’t actually answer the question. The question is: previously, I could expect the Gnome volume applet to work in KDE, and I could expect other applications for Gnome to work, such as Empathy or Rhythmbox. The specification as laid out by KDE and adopted by Ubuntu and Elementary still maintains that promise. Considering the facts that developers are using trays in this way (oft to expose a minimum of functionality that doesn’t mandate the full application interface), and that users are content and even enjoy using this UI paradigm (users don’t need all the functionality of all applications all the time: see changing status in Empathy/Pidgin, simple Previous/Next/Pause/Stop controls in Rhythmbox), how is Gnome willing to accommodate, and will applications written for Gnome 3’s tray be compatible with other tray implementations?
tl;dr: will the damn thing work or not?
e.g., even when it was possible with the system tray protocol, KDE wasn’t using the GNOME network manager applet.
Actually, I think a lot of KDE users *do* use the Gnome applet for NM.
Under current versions of NM, there’s simply too much logic in the UI that should be in the backend, and so other clients don’t typically support all the features that the default (Gnome) one does.