Design Center

Or should it be Design Centr to be both hip and US/UK neutral?

There has been talk on the ubuntu-art mailing list about creating a replacement to our wiki section for submitting artwork. To lower the barrier and for making it more manageable. Tracking request for artwork has also been brought up.

There’s the DesignHub project, thought up by Máirín Duffy of Fedora.

SpreadUbuntu could be suitable, though it’s positioned a bit different.

There should be good reasons, if you start yet another project, instead of joining or building on existing ones. But before you join or build on existing projects, you should think hard about whether they are or can become what you really want or need.

I have been thinking about what the underlying goal should be:
Foster quality and quantity of design efforts and outcomes in the Free Software and Open-Source realm.
or perhaps:
Foster quality and quantity of open design efforts and outcomes. Open design efforts shall mean ones that favor collaboration, meritocracy, sharing and permissive licensing.

If there’s going to be a project to build not-that-trivial infrastructure, I think it shouldn’t be tied to Ubuntu.

How could one go about reaching that goal?

  • Offer a place to go for open design projects
  • Increase the visibility of design efforts, outcomes and participants
  • Make design more enjoyable, make it happen easier and faster
    • remove technical hurdles
    • shape social interactions in a positive manner
    • encourage feedback. silence hurts
  • encourage constructive criticism, discourage unspecific and unfounded criticism
  • encourage participators to pay attention to constructive criticism
  • avoid and protect against flaming, trolling and vandalism
  • apply automation
  • assist in managing various aspects of design projects
  • Offer guidance and education to enable more, and more capable, participators
  • take care of deployment/packaging/distribution

Proposal for the concrete part of the briefing:

Create, deploy and maintain a website for managing design processes and assets.
Where assets are any kind of content wrapped in files such as images, audio and video recordings or compound (text and images) documents.

Web Frameworks

Ubuntu Wiki

I did a lot of editing and organizing the Ubuntu wiki section of the Artwork Team. I saw enough traces of people not understanding how to use the wiki, attaching images to random pages without telling anyone. Lots of struggling with the markup. Writing a step-by-step guide for how to add wallpapers and accompanying text made it even clearer to me that there is a significant hurdle that shouldn’t exist.

The strictly hierarchical structure is an issue, when what you would actually need would include things like: show me GTK+ Themes for 10.10. VS show me everything for 10.10. Faceted navigation, please.

If you have too many images on a page, you can get to know the surge protection (the wiki refuses to deliver the page and uses a timeout penalty).

Add the fun you can have with locking/warning and edit conflicts.

A fellow experienced contributor had no clue that you can bring back a deleted wiki page, if you just know its path. A deleted page looks just like one that does not exist, except that prior versions are accessible via the Info link.

The Ubuntu wiki is much better than having nothing comparable, but it’s not exactly user-friendly. There should be WYSIWYG editing. I’m well aware that it can get in your way, but people shouldn’t have to learn markup and shouldn’t have to deal with the edit-preview-save cycle. You should be able to drop images right into place, optionally appearing as thumbnails. With previews for SVGs.

Etherpad-like immediate editing, collaborative in real-time, would streamline editing and get rid of edit conflicts. Though branching and merging could be useful, too.

Manual Project

There’s this idea of putting the Ubuntu Manual online and making it editable. Edits would have to be approved. Translations should happen online, too. All based on Docbook or maybe a similar custom XML format. By far not the only project that could benefit from an online documentation editor/viewer. I think Etherpad-style editing could do wonders here, too. Doing translations is a very interesting user interface design challenge by itself.

Artwork team

Oh how I wish it was called the Design Team. Aside of what I mentioned already regarding the wiki, there are additional needs or wants for handling artwork and design assets:

  • Mandatory specification of a license and author(s)
  • Enforce a minimum size of uploads (for wallpapers), maybe even one of a list of fixed resolutions/aspect-ratios
  • Manage source files such as SVG and XCF
  • Link derivatives to originals
  • Versioning, perhaps by tying in Launchpad
  • Comments per version of a submission, ideally nested
  • Add notes or scribble on top of images to provide clear feedback

A Common Platform

The specific needs vary, but all 3 could sit on top of a platform that handles, accounts, concurrent editing and allows to structure pages in components.

One could think there has to be a CMS with concurrent editing. In absence of such a thing, what would be the best language and framework to implement it?

Frameworks

There are terribly many frameworks out there. I would rule out everything PHP based. As impressive as some projects build with it are, it looks more like a running gag than a programming language to me ;)

Django or Pylons/Turbogears look like a safe choice, generally. All Python.

Looking for frameworks that are designed with AJAX/Comet in mind, I came across Lift, very full-featured, written in Scala.

Nitrogen (Erlang) features an even-driven model, same syntax to build or update a page …

Weblocks (Common Lisp) and Seaside (Smalltalk, Pharo) are interesting for their use of continuations, among lots of other interesting properties.

Now if only there was a easy/quick way to determine if the features of one of those less well known languages and frameworks would lead to a net win …

What I’d be looking for is:

  • Very low noise-level, no or little boilerplate/glue code
  • secure by default
  • serialization turned into a non-issue
  • excellent support for AJAX/Comet
  • ideally existing, open implementation of concurrent editing
  • good documentation
  • Unicode support

Flattr

Users of the online service Flattr pay a small monthly amount and then click buttons associated to things to share out the money among the authors of those things. A thing can be anything you can link to, but is meant to be about specific content or a project.

If you don’t give, you can’t receive.

The minimum is 2 Euros per month. Flattr itself takes 10% of the revenue, to keep the service afloat, as they say (I hope they will lower it, once there are more participators) . You can add money to your Flattr account via Moneybookers and PayPal.

I had been considering to take part already, and then andrewsomething suggested it in a comment, saying it seems to be all the rage these days.

For now, I just added one button for my blog, also appearing in this post, but you might want to think of one of these as a reason to use it ;)


Flattr this

There’s a number of Free Software projects registered. For example SparkleShare. If you’re into music production on Linux, Ingen and Qtractor could become things of your appreciation.

Every flattr will be appreciated! I might well end up sharing it all out again.

Ubuntu Artwork Crisis

Some people who care are not happy about the state of the Ubuntu Artwork team and mailing list.
Saleel’s take on the Ayatana list (good read, as off-topic as it might be, there).
Vish’s take on the Artwork list (you can see a lot of thought went into this.

Seems like a good opportunity to offer some reflection on how things developed and how at least one particular contributor ticks.

First post

My first post to the Artwork list happened towards the end of 2007, in roughly my fourth year of creating logos and mockups in the FLOSS-realm. After switching to Ubuntu, it seemed just natural to get involved there. I just loved the Circle of Friends symbol, though I never thought much of any other part of the official presentation.

Motivation

I have to admit that increasing my chances of being hired by Canonical was part of my early motivation. Well, that didn’t work out. A constant part of my motivation, besides quite simply enjoying the creative process, is gaining experience, training and getting portfolio pieces out of it. Note that this can complicate cooperation, because under this aspect, it may hurt me if my work is altered outside of my control, or if it becomes unclear what exactly has been my part in a larger effort. Of course, experience with teamwork and having examples of it, is valuable, too.

Discussions

Back then we had long discussions on the list. Many opinions, many words, not many results. There have been phases where we saw many theme mockups, but only ever a few theme implementations. Can’t fault anyone there; I also only created mockups and no themes. It’s just so frustrating, a lack of control coupled with hard to understand gtkrc files. But thanks to only few people, a community-themes package happened. Nothing new there, for this cycle …

The mailing list used to be noisy at times, but has been rather dead as of late. Though we will likely see some live now thanks to Vish’s post.

Direction

There was a lack of direction. I once tried to address this issue, by writing about design methods, target audience, desired tone and message on the wiki. There was some interest, but after a while it became clear there was no one else to work on that level and I didn’t have the energy to pull it through to results on my own.

Design Team

Later on, the formation of the Design Team at Canonical made all of that pretty much pointless. That’s also when I really buried the hope of having chance of creating a default wallpaper. It had been dwindling before already. Used to be motivating for a quite a number of people. The Hardy heron wallpaper was a success. The Ibex not so much. The author wasn’t happy with the result, his vision had been perverted by forcing it into another direction. Might be part of the reason why he ceased to be active. Though maybe he’s just to damn busy as a freelance designer, like I should be, too, if only I had my priorities straight :).

I wouldn’t hand it to a bunch of hobbyists either, if there’s a trained full-time designer in direct contact with decision makers. Sorry, I mean it would be embarrassing if that was a competition. Though the outcome is full of things that leave me puzzled.

Once in a while someone shows up with the assumption that the artwork-team is responsible for Ubuntu’s default look, still.

Wallpapers

For Karmic, I took care of the wiki and put a lot of effort into organizing wallpaper submissions. Still proved to be hard for some people. The wiki “surge protection” kicked in, because of to many images on a single page, refusing to load. Complaining about that often enough led to ticket in tracker that predates Launchpad, but that’s all. Then the Flickr group took off. So I created the policy that we would not accept wallpaper submissions on the wiki anymore, knowing that they wouldn’t make it into the selection, anyway. All this also highlighted that the wiki is just not suitable to collect work from contributors. Too hard to edit, too much management effort required, doesn’t scale.

Mockups

People used to add mockups to the wiki that went beyond theming into interface and interaction design territory. Usually unrealistic, never possible within a release cycle, even if there would ever have been developers to implement it. To not have those mixed up with things that could work for the upcoming release, I created a place that is basically a concept graveyard :/.

There are a few other things I could mention, but I better wrap up for now.

What works?

First what doesn’t work:

  • Unguided discussion on the list
  • Creating themes without iron willpower
  • Artwork submissions on the wiki

What does work:

  • Collecting wallpapers on Flickr and selecting a few per cycle
  • Countdown banner contest

Why do these work? Likely because of:

  • visibility of what’s going on.
  • low barrier to entry on Flickr.
  • clear mission and deadline for the countdown banner.

What else?

54 active Members in the Artwork team, according to Launchpad. One can really wonder what most them actually do, regarding artwork.

There’s an Art & Design forum. Currently it doesn’t look too bad when compared with the list, but I think like all forums, it encourages useless single line statements, terrible quoting habits and costs even more time because you have to actively go there, instead of just pulling messages. The need for email notifications in forums should tell you something …

Oh, and then there’s ubuntu-artists on Deviantart. Deviantart doesn’t even do email notifications, because going there to check your messages in addition to your regular email is so much fun.

Keysigning Party Aftermath

I have been at FrOSCon and participated in the keysigning party. About 60 people evaluating each others IDs was … interesting.

My prior exposure to this whole PGP/GPG key business had been just the minimum required for a Launchpad/BZR account and signing the Code of Conduct.

Now the task at hand is signing all the keys where I’m reasonably sure about the ID of the owner and mailing the signatures to them. While there’s no way around going through not just every key, but every uid (a name and email address associated with the key) interactively, everything else about this calls for automation.

The command line tool caff has been recommended and it seems to be the only game in town. It’s in the signing-party Debian/Ubuntu package. No GUI and no out-of-the-box solution in Ubuntu. One could conclude that building a web of trust is not essential ;)

The easiest way to allow caff to send out emails seems to be to set up ssmtp. Installing it caused the removal of the exim packages. Well, there was no way I would deal with the more than 1000 lines long configuration file for exim. Getting ssmtp to work with my account did cost me a few attempts, but wasn’t too hard. It’s a little sad to have a configured account in Evolution and having to use something entirely separated for sending mails from the command line or via scripts, though.

No matter what I do, caff always tells me it can’t import the keys I want to process. It asks if i want to continue anyway and defaults to aborting. Only after trying a lot of things, I decided to choose continue and it looks like the script can do its job nonetheless!?

Meanwhile, I imported and signed the keys via gpg directly, instead. Signing on a per-uid level is really cumbersome and could be much faster with a GUI.

caff assumes the keys are not signed, unless run with a flag to not sign keys. Using that, I did a test run with a single key. Since I couldn’t think of another way to check if the email had the right content and got through, I did send another one via Evolution to ask the recipient.

No answer, yet. This morning, I decided to pick another single key. I’m not aware of any relevant changes on my system, but now caff claims that it can’t find a signed uid for any of the keys. The gpgsigs tool tells me there are signed uids for all keys in my list, so the signatures most definitively did not disappear. Any idea what might be going on?

My inbox shows that several participants got caff to work.

I could help with the interaction/interface design, if somebody decides to write a graphical tool or to extend one of the existing key managers. I wonder if and how this should be integrated with whatever is the default email application of a distribution, though.

Distribution Upgrades and Version Control

I have been alternating between 2 partitions for installations, to always keep one working system while overwriting the outdated one with the newest release. It might be worth a thought to explicitly encourage / support this approach.

This time it took a month until I actually made the switch, going from Ubuntu 9.10 to 10.04. A pile of custom settings and manually build software made me reluctant.

A journal of configuration changes could help a bit, but would be more interesting for system administration in general.

If I remember correctly, there’s already the option to import emails and settings for Evolution and at least bookmarks for Firefox during installation. That’s nice, but not enough. Handling this on an application-specific basis will likely always mean that this stays incomplete. It’s also not exactly reliable, as I found out once, where I would have wanted to use the settings of the installation to be replaced with the new one. Yeah, I know what and how to backup, but just imagine you would have to explain all that to a not so technical minded user …

There should be backup my settings and matching import features. In the case of an email client like Evolution, it would help if emails were stored as separate files, so they could be backed up and restored with other data, easily.

What if installing a distribution release would be like creating a (shallow) clone of a repository? You could commit your edits to configuration files and thus have a log of the changes. You could generate a change-set, do an upgrade and apply it and have all your customizations restored, as far as possible. With a list of the changes that can’t be applied anymore, so you know what you have to investigate or simply live with.

Process/Infrastructure/Stack Dream

I think I have a reasonable understanding of how things got to where they are regarding software on local systems vs web applications. Same for the way FLOSS projects are run, what related online services do and don’t do and how GUIs are designed. But if you forget history and inertia for a moment and just look at what is there, what has been shown to be perfectly possible in principle, you might start to wonder how a better process, better infrastructure, a better software stack, could look like.

Design process online service

Imagine an online service for software projects. Where you can create a project, using one of a number of templates for various needs. The service might guide you through an iterative process, perhaps with briefing, research, requirements gathering, conception, implementation and evaluation stages. You start with a mission statement to capture the essence of the project. The service offers explanation on how to best go about this, just like it does for every piece of writing inside the template structure. You can also quickly compare with the mission statements of other projects right there.

You can create, edit and manage mind-maps, a hierarchy of goals, personas, use cases or the simpler user stories, requirements, flow-charts, and mockups.

As project owner, you can invite others and grant read and write permissions. There’s real-time collaborative editing similar to Etherpad. No blocking or edit conflicts, although you can branch and merge parts of your documentation if you want to.

Is there a FLOSS framework that would make it straightforward to implement such Etherpad-like functionality?

Flowcharts can be linked with mockups to deal with structure on 2 levels without break. Mockups can be made somewhat interactive, with working tabs and menus.

You do not have to rebuild the same layout in another tool or via code, because the step from mockup to actual layout is taken by simply switching away from the wireframe theme.

GUI-builder

Thinking a bit more about this mockup/GUI-creator, it should be a bit like the Flash authoring tool. Rich support for vector and bitmap graphics. Ability to define interactive areas as such. Animation. Scripting.

But different from Flash as I got to know it, there should be a layer between logic and rendering to realise theming. A separation between the What and How of drawing. All widgets should be reusable components created in the same way, to be rendered on a shared canvas. A canvas that might fill your screen, controlled by local software, or one in a browser window. A single toolkit for the desktop and the web, where a canvas is not a special widget, but the base.

Related: