Wednesday, February 29, 2012

Building Software for People (A Challenge to the Open Source Community)

A few years ago I was having a play with Blender. To those unfamiliar with it, it's a 3d animation tool. You build up models and can then animate them (though I never did get to the animation parts - preferring instead to build some amazingly cool looking scenes instead).

There's a problem with it though. Blender, while incredibly powerful and results in some amazing results, suffers from something that I comment on from time to time. Occasionally I'll be asked about an open source equivalent of X program. Google is my friend (so long as I allow them to try and run my life and provide them with all sorts of information about me - I'll do a post on this at some point). I search for it and come up with a recommendation. More often than not though, I'll install that recommendation and within 2 minutes find myself saying those god awful words.

"It's built by nerds for nerds".

Back to Blender. Probably the most complete documentation for Blender is a tutorial called "Blender 3D: Noob to Pro". The bit which really annoyed me I think has since (and not before time) been removed. In the introduction they ranted and raved about how great the interface to Blender is and how you'll wonder why the same interface isn't used on every piece of software.

The reason isn't so foreign to most users. The problem with the interface is that:
  1. It's counter intuitive.
  2. It requires a great deal of memory. i.e. coming back to Blender requires trying to figure out all of those magic keys you knew at some point.
In programming, magic numbers are discouraged. If you must use numbers, assign them to variables so that they're named. For example, you never have 0.15 to represent the 15% for gst. Instead, you'd make a variable (or constant) called GST_RATE or some such thing. So every time you need to represent the GST rate in your code, it makes some sort of sense.

Magic keys are the same sort of thing. Sure, we have shortcut keys. We've always got long ways of getting there. And there are established standards for shortcuts (like Ctrl-Z - undo, Ctrl-X - cut etc.) so, while they might not be immediately intuitive, it's fairly trivial to learn more shortcut keys the more you use an application.

So recently I had a look at the program Comic Life. It's horribly basic. When I asked someone about it, the comic functionality itself is really horribly basic but kids LOVE the word art type stuff. The functionality can be replicated, and is in some ways better, in Scribus - an amazingly cool piece of open source desktop publishing software.

The problem with Scribus? It's not really made to be simple. To position an image within a frame, you can't drag the image with the mouse. Instead, you deal with x and y positions accessible via spinners. Selecting objects can be a hassle if the boundaries of objects cross. Text styles are a bit of a mission to establish - and without them, text can become quite mangled.

The results though are really amazingly cool. I could probably use it to make a comic strip. I would hesitate to recommend it as an easy tool for kids to design their own comics.

So if Scribus is around 90% of the way there and really, removing a bunch of features (or simply hiding them) should be fairly trivial, why is the FLOSS community not building loads of variations for people to use?

Scribus could be built to loads of different purposes which are easy to use rather than one application that does everything but uptake isn't great because with all that flexibility comes complexity. Open Office could be something fantastic if you could make it work in smarter ways (get rid of the character level formatting controls and allow the user to just use styles).

There's been this whole discussion on money and FLOSS. How do you make money from FLOSS? I sincerely believe it's by making the software start to work for people. People will pay for something to be developed that works intuitively for them. In which case, I think FLOSS software needs to start thinking in terms of an engine and interfaces. Here's the functionality. How that's compiled and presented in the interface is an entirely different matter. This means that the majority of the code is still a single code base. The only thing that changes is how it's presented to the user.

The GNU/Linux stack already does this with X. X-Windows sits underneath. On top of that is a Window or Compositing Manager (Metacity, Mutter, Kwin, Compiz etc.). And on top of that a desktop environment of some sort - Gnome, KDE, Xfce, Fluxbox, Enlightenment etc. In other words, the user has choice while using much the same technology and code base.

I guess, all it really needs is the theory to be tested. If you build it in a way that multiple interfaces can be used, and make it simple for the end user, how great will the uptake be?

No comments:

Post a Comment