The Flow Of Ideas

I have been thinking a lot recently about the flow of ideas in and around Open Source projects. A few days ago I asked for feedback about how we can better structure interaction ideas. The blog entry gathered some great feedback: thanks to everyone who contributed. With this work I am keen to understand the bottleneck between a well researched, well specified and documented interaction concept and its ultimate implementation. It is this contention between walled designers and walled developers that causes so many great ideas to be lost, never seeing the light of day.

Understanding and resolving this contention is important for GNOME. If we compare and contrast the KDE and GNOME approach to revitalised desktop interactions (read: KDE 4 and GNOME 3), we see two very different approaches. The KDE team discussed, designed and documented a big picture approach. They mapped out a design of what they wanted to see and then encouraged the community to implement said vision. And you know what, they did a damn good job. Although still a touch rough around the edges, KDE 4 is a huge achievement of defined direction and coordinated implementation.

But that approach is not the GNOME approach. GNOME is a playground for experimentation and ideas. We need to stop trying to take the KDE approach of mapping the big picture and rallying the troops to implement it. It just isnt going to work that way: we have tried to do this for the last three GUADECs and have produced relatively little.

But look at what innovation we have produced. Tomboy. GNOME Do. Beagle. Empathy. Abiword. The Slab. The new FUSE applet. Deskbar. Gimmie. Dashboard. F-Spot. Banshee. The list is endless. The GNOME community has a history and culture of experimenting with ideas and approaches. Some of them sink, some of them swim, but there are two important attributes in each of these ideas – they are small, self contained units and code is available. Just look at Owen’s recent post as an example. We had all read Vincent’s post with interest, but when Owen showed us some code that we could check out and play with, the idea really started to develop legs. Another example is GNOME Do. I think most of us were a bit sceptical of the idea of GNOME Do at first, but the subsequent implementation and positive reported workflow experiences has made people sit up and not only take notice of GNOME Do, but its primary interaction characteristics.

So, it is clear that the GNOME community is an incubator for lots of small experiments and ideas, some of which work well and some of which don’t. Our challenge is in how we continue to encourage the flow of ideas and how we merge the flow of successful ideas into the central body of what we call GNOME

If we decide this is the right approach, we need to not only foster an open environment that encourages experimentation, but we also need to foster an environment that encourages useful experimentation. We want to ensure that successful experiments can be merged easily and quickly at a technical level. One potential approach to this is to encourage uses of popular and agreed infrastructure. We have this to a degree in the project already (languages, toolkits, source control systems etc), but I suspect this will shake out naturally and we will continue to see dominant technologies such as Python, Mono and C being used, and increasingly new technologies such as Clutter and Telepathy.

For this approach to succeed we need to think carefully about the workflow of an idea moving from the functional experimentation phase to the merged phase – the technical implementation and maintenance, the politics we want to avoid, the decision making process of how we evaluate ideas etc. This is where I feel we should be focusing our debating glands. Lets flesh out these processes and encourage this environment of experimentation and exploration, Just imagine what we could achieve if we could figure out effective methods for communicating interacting concepts effectively to developers, developers hacking on small implementations of those ideas and the those ideas garnering popularity and being merged into the desktop. In many ways this is a very Free Software approach – scratch an itch, refine it with collaborative development and then merge. If we can figure out these questions together, our new GNOME could actually happen.

  • http://lucumr.pocoo.org/ Armin Ronacher

    GNOME is moving into the right direction. The core technologies are slowly replaced with better equivalents but not all at the same time (gvfs, dbus, gtk3 etc.) so the transition is smooth for developers. The mono support is outstanding which makes GNOME an incredible productive environment for developers.

    Also users have the same interface for a long time and feel right at home in new releases. Before something is changed the developers think a lot if that’s a good idea and this is definitively the way to go.

    On the other hand some limitations survive longer than they have to be. The open dialog is still a very problematic thing and I have the feeling nobody has the balls to try to improve it because everybody will rant about that again :)

    The future of GNOME will be especially bright when compiz has become standard. That will enable smooth animations and new interface concepts that depend on that (docks for example and even to some extend gnome-do).

  • Tom

    Good luck with shipping the GNU Network Object Model Environment with MS/Novell Mono apps.

    Stranger things have happened, but it will be hard and very messy.

  • bkor

    Real code is what counts, yes. However, there was a longstanding assumption that never ever something should break. So first you need some positive feelings about doing something different (among devs), then planning (UI hackfest), then code… at least this is how I feel this was started.

    Regarding interaction and so on: You only know if it works if you can play around with something (agree code rocks).

    IMO the people working on this are experienced enough that everything will work out. If something feels ‘off’, it mostly seems to be caused by a misunderstanding.

  • http://lucumr.pocoo.org/ Armin Ronacher

    Many people have the problem that they are unsure about the licensing situation of mono.

    Jono: You should really interview Miguel or someone from the Mono team about the licensing thing. There is so much FUD around (thanks to boycott novell and other websites) that it would be a good thing to have someone from the official team talking about the issue.

  • http://weblog.obso1337.org seele

    “I am keen to understand the bottleneck between a well researched, well specified and documented interaction concept and its ultimate implementation”

    To be fair, even industry doesn’t know how to do this well. These are big shoes to fill.

  • jono

    seele – agreed, but wouldn’t it be cool if we figured it out? I think there is huge opportunity to understand this. We have the breadth of experience across different domains – many developers, usability engineers, interaction designers and more, if we can identify where our lines crossover, we could try and resolve some of these questions.

  • jono

    bkor:

    IMO the people working on this are experienced enough that everything will work out. If something feels ‘off’, it mostly seems to be caused by a misunderstanding.

    What do you mean by “works out”? Do you mean that quality programmers will never really make bad interface decisions as their experience will see them through in the right direction?

  • sulfide

    I’ll definitely agree with Tom on this one. I recently migrated all my desktops to KDE4, for many reasons.. the low quality mono/C# apps is one of them.

    To tell you the truth I feel like I’ve been missing out all these years now that I am finally using KDE. Although I had to switch to Fedora because Kubuntu is very poor for whatever reason, I have read some instances where the community complains about the lack of attention canonical has toward breaking things they rely on in releases. (not sure how much of that is true, read it on a planet somewhere).

    Anyway, I hope all the GNOME developers and users the best of luck. I don’t mean to rain on the parade, I just had to post my thoughts when I saw all the talk of these great applications that I find to be the most annoying and unintuitive.

  • jono

    sulfide:

    Although I had to switch to Fedora because Kubuntu is very poor for whatever reason

    Have you directed your comments and experiences of Kubuntu to the Kubuntu community? Maybe they are either fixed or can focus on fixing some of the problems?

  • ethana2

    ‘A picture is worth a thousand words’ I think mockups would be better utilized if the conception was separated from the visualization. The people that can think awesome things up aren’t necessarily the people that can express them elegantly. Bringing those people together for the expression of ideas as they relate to applications, I think, has the potential to be an interesting thing. Also, I’ll bet, with big companies, that a lot of their UI design is trial, error, and statistics. When one group codes one product and then pushes it out to everyone, I don’t think you get a lot of that. Forking is often an option, but most people prefer to avoid the politics.. Perhaps bzr and quilt could come in handy there? I’d love a ‘try out these changes’ link on Ubuntu QA..

  • ethana2

    Wait, so…

    We have to use HTML just to leave coherent comments?

    This is a test…

  • ethana2

    Jono, I request that that ‘little detail’ be at least added to the ‘few quick tips’ above the comment form.

  • jono

    ethana2:

    We have to use HTML just to leave coherent comments?

    You don’t need to use HTML – there are a few simple markup techniques available. If readers find this a pain, let me know and I will investigate a GUI formatting doobrie. :)

    Oh, and I did add some tips above the comment form. :)

  • Aaron Seigo

    I obviously can’t comment on “what GNOME should do” (I lack the necessary contex to do sot; anything I suggest would be vague, general or just wrong), but I will say this:

    It is absolutely, unarguably vital that a project finds its own methods that work and then stick to them, luxuriates in them. There is no One Universally True Method(tm): there are many methods in the world, though there may only be One Method That Works For You(tm). Finding it is key, executing on it crucial.

    In this blog entry, you spend a fair amount of time looking back on what you consider to be your community’s successes. If they are, indeed, what you wish to replicate, then that’s a terrific approach IME. Story telling the past (tradition) can be a very strong and effective tool.

    I wish you the best in charting your way forward. =)

    p.s. thanks for the kind words regarding the processes we have been going through in KDE.

  • http://dborg.wordpress.com Daniel Borgmann

    One thing I’ve always been wishing for is that the GNOME community would be a bit more open to variations. No one desktop shell can be perfect for everybody, and our architecture makes it fairly easy to mix and match. In some sense, even XFCE can be considered a fully compatible GNOME variation.

    With variations, alternative approaches and tools would have a much better chance of being used in an actual desktop environment, than when you have to make the (highly political) decision of whether to include something in the GNOME Desktop release. It would also allow us to form more educated opinions about what works and what doesn’t, instead of just arguing about it endlessly.

    And then of course there is the immense importance of high level languages for interface design and prototyping. Vala could bring some of this experimentation-inviting rapid development to libraries and core components too. It just doesn’t matter if it runs 5% slower, when it gives us 50% more time to work on performance improvements.

    I think we are on a really good track all in all. The one thing I am most concerned about is the toolkit, and that we might have to re-think how interfaces are constructed. Gtk has not exactly been a fast moving target over the recent years. And then there is clutter too, so things might become very interesting but also a little uncertain.

  • jono

    Aaron Seigo:

    Story telling the past (tradition) can be a very strong and effective tool.

    I entirely agree – I am a firm believer that stories are methods in which we document and identify patterns in our communities. Of course, the magic is in that they vary between communities, as we can see between KDE and GNOME – two very different approaches, both have produced fantastic desktops in different ways.

    Daniel Borgmann:

    I think we are on a really good track all in all. The one thing I am most concerned about is the toolkit, and that we might have to re-think how interfaces are constructed. Gtk has not exactly been a fast moving target over the recent years. And then there is clutter too, so things might become very interesting but also a little uncertain.

    Yeah, I think the toolkit is a serious concern. Clutter seems really exciting to me – it presents a new approach to building interfaces. Part of me has concerns about accessibility, but it would not surprise me if more and more developers collect around clutter as a method of driving these experiments forward. I think that the key is that applications can only dictate the direction of underlying infrastructure and toolkits.

  • http://www.ndeschildre.net Nicolas Deschildre

    Another point that separate designers from developers : designing is damn easy, developing is much longer and harder. Especially when the designer has no technical background and is asking you for a technical pyramide. And I really dislike that. Like this designer who submitted me a crazy photoshop file as a design for a website… So there is indeed this feeling that, since we are doing all the dirty work, why should we listen to these people?

    In my opinion, the only way to make these two groups together is to bring them to use an intermediary interface that benefits both of them. An interface, with a non technical side for the designer, and a technical one for the developers. More precisely, to bring designers to use a design tool that can generate a skeletton of code using existing and implemented frameworks. In the web world, that’s call WYSIWYG editors (Dreamweaver and so on. Implementing a web design in form of HTML files is a piece of cake!). In the heavy client world, we got… Qt Designer, Glade, the design interface in NetBeans. They are not perfect, especially for the designers (a little too technical) but that’s currently the best tool. If we were to improve this developer-designer relationship, it’s on these tools that work would need to be done.

  • Tom

    @sulfide: I never said Mono apps are poor quality. On the contrary I think some of them are really great.

    All I’m saying is that if you want to ship MS-technology with a project that has GNU in its name you better get a unlimited supply of fire extinguishers :wink:

    More on topic: I think tools like Glade have to be reinvented to really be usable by designers.

  • bkor

    jono:

    What do you mean by “works out”? Do you mean that quality programmers will never really make bad interface decisions as their experience will see them through in the right direction?

    I wasn’t talking about programmers when I mentioned people. I meant everyone involved. Further, I do think programmers will make various bad UI decisions. Then either another programmer (note: I don’t consider most developers just a programmer), or just someone else actively involved with GNOME. Still, you don’t truly know if something is good or bad until you can play around with it. It is is a long time since apps defaulted to bad UI. Just don’t expect perfection in the first version.

  • http://thorwil.wordpress.com/ Thorsten Wilms

    To Nicolas: designing is easy?

    It is not, because to do it well, you often will have a lot of things to consider. You wouldn’t say coding is easy because many people can manage to write a Hello World, right? ;)

    But I agree regarding tools, of course.

  • http://linuxcanuck.wordpress.com LinuxCanuck

    I use a mixed environment because I refuse to be limited by the vision of either project. I use K3b and Amarok in Gnome because they are simply better than anything that Gnome can come up with. Likewise I use Gnome/GTK applications such as Pidgin, AWN and Screenlets in KDE 4. What Gnome lacks that KDE 4 has going for it is QT 4 and plasma which makes KDE applications run snappier and just plain look better. I hope that the Gnome developers have taken notice and update the look and feel of Gnome which looks so yesterday in its native form. The best OS right now is Kubuntu with Gnome installed as well. Even when running Gnome you can use KDM and take advantage of KDE 4 fonts and decorations. You can tell that I like the most of everything. Why limit yourself if you don’t have to? I agree with the comments expressed about mono. No matter how good Evolution, Tomboy or Banshee might be I refuse to use them because of mono. You can’t sleep with the enemy and pretend that you are a patriot. To pretend that Gnome and Ubuntu support open source and use mono at the same time is hypocrisy, IMO. The fact that Novell champions mono should have been a clue to steer clear. They would consort with the Devil if it would increase revenue. What is different about using mono and installing restricted drivers and codecs? You can’t be half of a hypocrite. You might as well go all of the way.

  • http://www.ndeschildre.net Nicolas Deschildre

    Thorsten: Right, I oversimplified :) Designing is not easy. If done consciously, it can be an difficult and intensive work. What I wanted to say is that on the overall the required development effort is higher to much higher than the design one. It depends of course of the project.

  • jono

    Nicolas Deschildre:

    Thorsten: Right, I oversimplified :) Designing is not easy. If done consciously, it can be an difficult and intensive work. What I wanted to say is that on the overall the required development effort is higher to much higher than the design one. It depends of course of the project.

    I disagree – design work can be even more intensive. From assessing and documenting needs, developing and researching ideas, formulating them into a design/spec, gathering feedback, merging feedback back in and prototyping, its incredibly intensive work. I think comparing it development is like comparing apples and oranges.

  • Segedunum

    Armin:

    Many people have the problem that they are unsure about the licensing situation of mono. Jono: You should really interview Miguel or someone from the Mono team about the licensing thing.

    Whilst these issues are somewhat off-topic, I’m afraid that would be a waste of time with the Mono people just pointing to their FAQ which doesn’t answer many questions. They try and tell everyone that the ECMA covered stuff is safe. .Net’s core technology, including things like the CLR, is governed by a RAND license granted by Microsoft and it is only there because the ECMA requires it. The question is, how long will that license last and can it be revoked? Nobody knows that, and the Mono guys have consistently side-stepped it over many years. A letter from Microsoft, Intel and HP was even talked about regarding this issue some years ago, and it has never materialised.

    Having said that, if you want to write GTK and Gnome applications today, Mono is the most logical, pain-free method. Alas, rather than take what was interesting about .Net and then look at the enterprise world of Java and the open source development world of Python, Perl and Ruby and come up with something new that would benefit everyone, the Mono guys chased .Net compatibility. I feel it was a good opportunity lost.

  • http://www.jonobacon.org/?p=1467 The Gritty World Of User Interface Exploration | jonobacon@home

    [...] a fascinating discussion that happened at FossCamp. A little while ago I wrote an article called The Flow Of Ideas. The basic gist was to encourage the development of user interface ideas and the opportunity for [...]

  • http://www.bedavafilm.org bedava film izle

    Good luck with shipping the GNU Network Object Model Environment with MS/Novell Mono apps.

    Stranger things have happened, but it will be hard and very messy.