DoctorMo's Blog

I sent this to the Ayatana group and I’m posting here to my blog to invite any designers who are not in that group.

This is an invitation to all designers who will be at UDS-M soon to talk about reducing the resistance in the community to Ayatana developments and directions. So I want to kick off a discussion here and then carry
it on at UDS:

We’ve seen in the wider community resistance for a number of decisions that have been taken by the DX, Design and Ayatana groups in both Karmic and Lucid cycles. Various things seem to generate irritated users who are naturally not pleased about change.

As a community leader I don’t like this kind of fighting. So I’ve been thinking more about how to reduce the problems through better communication and conflict resolution.

I believe better communication doesn’t just mean talking in more places or going into more depth about the technical details of a design. It means using certain inviting language and designing the communication
for the audience, making sure that your course correcting each time there is a conflict of interest so the next communication includes as points what has been brought up before and doesn’t lead to duplication.

The observed culture has had a tendency to consider conflict as a bad thing, an all or nothing affair to disprove ever tenant. I’d like to encourage the view that conflicts are not about going all one way or all
another way but are about considering and factoring in the consideration into a variance so that the outcome is not exactly like either party predicted.

Some of that good dialectic goes on here in this mailing list, but that’s not communicated much outside where it would do good to calm people. I believe some of the problems stem from language of outside
publishings, e.g: “We’ve made this choice because we believe it’s better for normal users, there are no options and if your an advanced user, we’re not really thinking of you when we made this choice so please
don’t ask for us to add options.” (hyperbole, but you get the point)

Basically an invitation to get irate and not much of an invitation to come and help factor in various different positions and considerations. Not that this is the intention, I believe that the people writing these articles are really trying to communicate to the users. But language and ability to cope with user’s opinions seems to turn an opportunity to advance the design of Ubuntu into a flame war that ends up turning users off.

A few of my community circles react to Design Team news with a *sigh* and “Oh god what have they done now”. The teams reputation is low and it’s over shadowing the really great work that’s going on. How can I
convince people to trust decisions or even get involved if they don’t trust that the discussions are fair, balanced and considered? So I’d like to be able to build up social relations so that we’re not just on par with other teams, but surpass their ability to bring people in and form their world view into solid multi-consideration design.

I want people to think of Canonical and think of an awesome company that really get involved with it’s users (downstream) and it’s suppliers (upstream) and is really clever at blending everyone’s positions into something awesome. MPT is a perfect example, very good at considering and communicating effectively with the community. *cheer* Thanks! You’ve been great at calming various people.

Thoughts and Responses best put onto the Ayatana mailing list or held for UDS.

I had a TEDTalk recommended to me a few months ago called “The Paradox of Choice” and it’s one of those must read books for people who want to do effective UI design. It’s a very good scientific explanation of why presenting users with millions of choices is a bad idea.

The first problem is that we can end up paralysing users with choices they can’t make because they don’t have the information or skill available to correctly decide what to enter.

The best way to solve this of course is to make intelligent choices on behalf of the user. Either by not presenting them with dialogs at all (thus not blocking their progress) or by setting reasonable defaults in all boxes. There is a third option, which is to make each option an idea and mix together using dialectics: so non-compatible options are not shown at the same time, symmetrical choices are collapsed and non-essential options deprecated from view but not eliminated.

The second problem of course is that the more options we present to the user the more unhappy they will be with the choice they finally do make. Because the choice puts an expectation in the user’s mind that the result should be perfect.

Take for instance the number of choices available on Gnome Look for window decoration and themes. The problem is that there are thousands of possible themes to choose from and no matter what you pick, none of them are going to be perfect.

What’s more damaging to the spirit is the difficulty of trying out all these options, there is not automatic installer for them, they’re not packaged correctly, most of them are hosted on unreliable sites, everyone of them is different and confusing to set up right.

If we want to allow users to make good choices to suite their tastes, then we must make those choices easy to experience and discard. The experience of choosing can’t be inconsistent as in the case of gnome look as that just makes us feel worse that we failed because we weren’t able to put up with the problems more in order to find the perfect theme. Lower the barriers to change and people will be a little more happy with the choice.

Now to the dark side of limiting choices. Of course removing all choice can be bad and my example is Canonical’s Ayatana group. They have proven that it’s very easy to get confused between removing blocking choices (where the user can’t proceed without making a choice) and removing all choice completely which limits experimentation. Gone is the good design of choice and in it’s place is the policy of eradicating it systematically.

But there are users who are more experimental and they want to see options and choices because they want to poke at the system and see if they can come up with a more useful, more efficient, more poetic interface than the default. What ends up happening though is that by removing all options we force opportunistic experimenters to become programmers*. Most do not want that kind of burden and will simply not experiment at all, to the detriment of advancement in design.

I believe these opportunistic experimenters are a healthy part of the community, they bring new ideas and thoughts into the community dialectic system. We should encourage non-blocking, non-visible options as much as possible to foster this community.

What are your thoughts?

* Editors take existing things and rework them into something new, Artists take a blank canvas and create from their mind. Bug fixers are more editors, project creators are more artists, but everyone does both to some degree.

There was an announcement today about the Ubuntu theme and branding change. I’m letting the theme digest for a day or two before I blog about it in any detail. Instead this post is going to talk about the logo branding:

I really like this new logo and apart from the logo inconsistency inherent in some of the draft uses of the new logo; the logo is sharp, professional and well designed in my opinion.

There was a concern amongst some Ubuntu community members that dropping the brown and orange, earthy crunchy, brand indicates a departure from a Home Desktop, human focused distribution and a re-badge to make the Ubuntu brand more acceptable to various new partners. I think that the orangey colours were very nice and I liked that we could tell an Ubuntu machine from across the room.

Although “precision, reliability, collaboration and freedom”, guys, that’s not a meaningful mantra. It’s not as catchy as “Free as in Speech” or “Of course! don’t you know anything about SCIENCE!”

What are your thoughts on the new brand?

My friend leftyfb over on his blog has highlighted an issue with gnome that I always thought was a genuine oversight. i didn’t think that the gnome developers were seriously and deliberately removing the icons from certain menus. For the past few months, every time I went into the System menu, I thought the missing icons were because some bug that no one could find the time to fix, had crept in.

Apparently not. according to records it was a discussion by developers to remove visual queues and make Ubuntu harder to use for dyslexics like myself. Forcing us to read words which we can very easily misread and not letting us use icons in which a combination of shape and colour can act as reinforcing cues for the noun of these menus.

I know dyslexia isn’t a fun disability like blindness and deafness, but a little consideration would have been nice.

The exact regression aside, Mike points out in his blog another worrying facet that I’ve seen myself all too often in the gnome developer community. A community of disagreeableness. As I was saying yesterday in my blog post about disagreeable filtering: Being nasty and obnoxious is a poor man’s user contribution filter compared to being patient, understanding and using dialectical tools to work out problems so they can achieve as many wishes as is possible.

I don’t expect devels to say they’re good at design when they are only good at systematics. If you’ve worked out some of the science or some basic principles of design, it doesn’t make you a designer. It’s not always parcelled into simple rules and regulations. Sure, sometimes they help, but they’re at best guidelines and a good starting point and you’re not expected to use them as iron clad regulation. Of course this is an obvious warning sign that the coders have taken to design before learning anything about servitude let alone elegance.

I’m not pleased with gnome developer’s attitudes. Yes, sure, users are annoying, but why aren’t you asking them for money in exchange for listening to them? Instead you’re pretending that you’re an open community that welcomes contributions from unskilled users, but in fact want to cut yourself off from all users. A sort of Unenlightened self interest, the bastard brother of Enlightened self interest who is responsible for cutting ties between developers as users and pure users.

This is why I protest that we MUST start being honest about how progress is funded. You only have to listen to the people that control the purse strings, listening to anyone else is charity and is not guaranteed in any way. If we want to have users making a real difference in the community and ultimately getting the software that they want to have, then we MUST make sure those users have a way to pay for such services.

If we want to have users making a real difference in the community and ultimately getting the software that they want to have and not the software that we think they ort to have, then we have to listen to them and be able to ask them to pay for the time of developers.

One of the ideas for allowing branches to have extra functionality is the addition of some kind of functionality which adds buttons for doing extra stuff to a branch.

For instance if you have a Makefile type project, then instead of ground control detecting that and presenting a ‘compile’ button, we’d let the author of the branch decide to offer that to ground control users and they could add a script call to a file in say .gc_methods with an appropriate button label.

This would allow even the learning materials branch to offer a compile feature, while being separate and not tied to ground control per say, the functionality would work though the existing button bar that appears.

This would put the burden of offering such functionality to project maintainers, and if you find a project maintainer who hates ground control, they may not be happy about adding a file full of script pointers to their trunk branch for newbie contributors.

Another option I saw someone mention was some sort of UML file which could specify the internal project workflow and somehow that could be used to help users edit projects correctly.

Thoughts?

Hey everyone, I’ve released version 1.0.6 of ground control into my PPA, this is a fairly stable Beta which I hope everyone will give a good testing.

For new users: Ground control is a project that hopes to bring the collaboration of launchpad and bazaar branches to every day users abilities. It does away with the need for a command line and has removed a lot of the complex distractions leaving a simplified workflow for users to follow. It uses all the existing libraries and practices of the community, so if you need to move back to the command line you can continue were you left off.

It’s also flexible enough to allow you to manage your existing bazaar checkouts via nautilus. If your want to.

To show you what it can do I have done a video (you have to click into my blog article to see it):

[blip.tv ?posts_id=3161227&dest=-1]

What I need now is more testing and perhaps a design review to make it easier to use. Let me know your ideas, thoughts and if you think this will be useful for getting course writers into the Ubuntu Learning project, comment below and bug reports here.

If you do have a problem and it crashes at some point, do create an empty file in your home directory called groundcontrol.log this will quickly fill up with a useful log of what’s going on and you can attach it to the bug report.

Update: I’ve made sure it’s available for both Karmic and Lucid releases.

Here is a preview screenshot of the current commit screen, it doesn’t yet allow you to choose which things to commit and which not, or show you any diffs, but it does commit files and auto add any new ones.

Thoughts?