Brains are Object Oriented

Following on somewhat from my browser UI rant, an important thing to realise when designing interfaces is that the brain is used to realistic, real-world things. It gets confused by magic, tries to reject Quantum Physics, and so on. In other words, the brain is Object Oriented.

To be Object Oriented simply means that there are a bunch of "things" which can each do stuff and each have stuff. For example, a ball is a thing. It can bounce and roll, and it has size and colour. Being Object Oriented means breaking apart some things which seem to logically go together, like verbs (or in the case of a computer program, functions). However, with really huge projects it is clear that separating like from like and instead combining things based on context (into an object) is less confusing, since this is more understandable to our brains.

With user interfaces there is magic and quantum "spooky action at a distance" which the brain does not like. This is where changing one thing affects another. For instance, the up and down arrows on a scroll bar. These arrows are not connected to the slider, so how do they manage to move it up and down? By magic. How often do you drag the slider on a scroll bar rather than press then buttons? This is because the brain thinks of moving down as a method of the slider, rather than the arrow being a function which moves the slider. For this reason I propose that arrows be taken off scrollbars (some themes to it already).

Another problem is toolbars. They contain precisely that, tools. In the real world when we want to join two pieces of wood together we think about putting a nail through them. In order to do this we get a hammer, but that's just an implementation detail. If we could push the nail in then we would do. Thus toolbars are bad because they are a kind of magic. They contain functions, ie. they perform actions, like save(document). However, the interface *should* provide methods, ie. the documents should be able to perform the action, like document.save().

A key thing to realise is that your application *is* the GUI. Therefore your GUI should be Object Oriented as far as possible, and should itself act like an object. Developers often think of their code as being the heart of an application, with the graphics as a glossy veneer on top. Users, however, think of the graphics as being the heart of an application, and the code just sticks it together. There are far more users going to be using your software than developers (you should hope :P ) so keeping this in mind is important.

Efficient vs Approachable (choose your phrase carefully)

I am very interested in human computer interaction (HCI), and I like to follow the trends and experiment with new innovations, plus I try wherever possible to commend developers who make different and interesting things, regardless of whether they are any good or not, since experimentation is key to finding better ways of doing things than we have now. Afterall, the same processes which turned slime into us are responsible for birth defects and fatal genetic diseases, you can't have the good without the bad.

I find a big problem with the phrase "easy to use", since it covers many varied situations. "Easy to use" and "hard to use" can both describe the same thing at the same time, since the words used are so vague; "use" covers a lot of ground, as do "easy" and "hard". Therefore I try where possible to use more specific words. The most common ones I use are efficient/inefficient and approachable/confusing. Why are those more descriptive? Here's an example: Compare the Vi text editor to the Leafpad text editor.

Vi is easy to use since its keyboard commands mean you never have to take your hands off the keyboard. All formatting, editing and control functions can be accessed the same way, via a few button presses. This could also be called efficient.

Vi is hard to use since it doesn't have any buttons and nothing is labelled. The whole interface must be learned and you have to look in the manual just to find out how to quit. This could be described as confusing.

Leafpad is easy to use since buttons are labelled and organised in a menu. Different tasks are given different places, structuring the interface. This could also be called approachable.

Leafpad is hard to use since it requires a whole graphical environment just to start. To make selections and issue commands you need to constantly swap your hands between the keyboard and the mouse. Some things take longer to do than others, because they're buried in menus. This could also be called inefficient.

As you can see, both can be described as easy and hard at the same time, even though those words are mutually exclusive. That means the words easy and hard are wrong to use. Whilst we can't really draw much meaning from saying "Vi is easy but hard", we can say "Vi is efficient but confusing". Likewise we can say "Leafpad is approachable but inefficient". Both have their advantages and their disadvantages. To someone who spends a lot of time in a text editor, for example a programmer or a journalist, it would be sensible to invest the time to learn Vi. However, for a general audience Leafpad would probably be more appropriate, thus the default text editor on a mass market operating system should be Leafpad rather than Vi. The same argument can be used for Blender, since its own peculiarities make it very efficient for someone who knows what they're doing, but make it confusing and unwieldy for someone who doesn't want or need to spend the time learning the interface. The only difference here is that I don't know anything as capable as Blender to contrast it with.

Regardless of what experienced users and developers may prefer, the approachable option should always be the default. Saying "I prefer XYZ" doesn't particularly matter when you know how to use a package manager. The defaults should be chosen to suit those who don't know how to use a package manager, or even what one is, since those are the users who will be using the defaults no matter what (because they know of no alternatives). Please make their lives easier.

The end.

A little toy for you

If you want to play about with a little toy I've been messing around with then you can find it here (but probably not for long, since that's a temporary storage area).

It's a little Python app (requiring pygame to be installed, on Debian systems like Ubuntu this is provided by the python-pygame package) which, when given a band name, connects to last.fm and gets related artists, and their related artists, etc. putting them all in a graph weighted to their relative strengths to make a map of musicians (for an explanation of the algorith see below).

This is very buggy, unbelievably inefficient, and could likely cause a lot of stress for last.fm, so use sparingly (remember, if someone wants to DOS attack last.fm this is not the most efficient way of doing so, so don't think of it at warez or anything because it's not meant to be).

To use:
Extract the archive, then run the file Visualiser.py. I would recommend running it in a way that can be killed easily (for example from within the Geany IDE, which has an Execute and Stop button), since it is an experiment with threading for me and killing those threads can be annoying if (when) the (increasingly complex) graphics thread dies (although if you do run it from a commandline then you can give it a band name directly, like "./Visualiser.py Children of Bodom")

When the window comes up click on the Artist Entry field to select it, use backspace to get rid of the default text, then enter the artist you want to start with and press return. The program should then start downloading images and relationships between artists, adding them to the graph as it does. The deeper the relationship matching the more accurate the map, at the expense of coverage, the more artists modelled the more accurate the map, at the expense of speed (there's a stupid-ass bug in the total artists down button at the moment because I'm an idiot). You can choose to see images (which, if disabled, will also disable image downloading), text labels and the underlying web of connections (the lighter the strand the stronger the connection). Note that enabling and disabling images shifts the nodes in the rendering of the web only, it doesn't affect the modelling in any way (the artists are modelled with their position as the top-left corner of the image/text, which doesn't change).

What it's doing:
The artists exist in a python dictionary, with various different lists of the keys existing for different purposes (the main one being usableArtists). Connections between artists are stored in a separate dictionary, and pairs of artists with no connection between each other are stored in another dictionary.

The Handling thread goes through a list of artists which are known to exist but who are not yet modelled. It then puts each artist in turn into the dictionary and appropriate lists, creating connections as far as the link depth goes (a link depth of zero only connects the most related artist to each artist, which makes forming closed systems easier (eg. Edguy is most related to Avantasia, Avantasia is most related to Edguy, resulting in only those two being modelled for a link depth of zero)). After the connections have been made it sets up a repulsion between the new artist and every artist which it is not connected to. It continues like this until there are either no more artists left to process (a closed system has been made) or until the total artists limit is reached (cutting short a complete modelling of the given variables).

The Image Fetching thread, as long as images are enabled, fetches images for those artists which haven't been assigned one yet. The Relation Fetching thread does the same thing for artists without relationship information.

The Drawing thread draws the graphics and handles user interaction.

The Force thread goes through the list of modelled artists, setting the force on each to zero and halving their velocities (which gives a little bounce to the system). It then goes through the list of connections, assigning an optimum distance apart for the artists (100% similar artists should be close, 20% similar artists should be further away. The distance is direction-independent), then adds a force to each based on how far away they are from this optimum distance, further away means greater force, and the stronger the connection the stronger the force. This means that weakly related artists will tend to move a good distance apart over time, but if other factors can easily overpower this tendency. The list of repulsions is then gone through, forcing apart any not connected artists which are closer than a certain distance.

The Linear thread constantly updates the movement of the artists, calculating their acceleration based on their experienced force and a set mass, from that calculating their velocity and from that calculating their position (which in turn feeds back to the Force thread)

Well, that's basically it for the time being. There are many bugs with it (due to the repulsion's cut-off point some arms of the map can arc around and become close to other areas to which they have no relation, non-English alphanumeric characters cause problems, the total artists down button is broken, there is a rare tendency for the artists to shoot off and crash PyGame by having extremely massive coordinates and probably a lot more needs seeing to as well) but it is purely experimental at the moment.

And the point of this? Well, firstly I think it is pretty cool. Aside from that I think it would be a nice way of browsing one's music collection. By hooking into the multiple genre tags that last.fm gives to artists then this information could be used to map out genres, thus letting users select an area of music they want to listen to, rather than having to specify Speed Metal OR Thrash, and playlists could be defined by drawing a path through the map, moving gradually from one genre to another without obvious jumps. Anyway, that is work for the future. At the moment have fun watching the pictures bounce aroud on strings :)

Warbuntu in the works

Well, I have had this idea for a while. I want to make an Ubuntu-based live CD of my own. It will basically be a testing ground for crazy new user interface ideas that I have. Since my programming skill is not particularly good it might take a while, but just as a taster here is the kind of thing I want to include (remember, this is purely a research type thing, which is why it is only a live CD and not an installable thing):

GNOME Display Manager (logon screen) and Screensaver:

I wrote quite a significant comment on this in some Ubuntu Wiki pages, but it seems like they are going for crazy 3D-ness (nothing against you Mirco, loads of people have said how cool the Cairo Clock on my desktop is ;-) ). I wanted to test this idea for myself, and Warbuntu would be a great place to do it. Here's the basic idea; the GNOME logon screen doesn't really fit in with the desktop when it is in "themed" mode, but the non-themed mode looks ugly. Also, there are far too many ways to switch user, and I think locking a session shouldn't be appear any different to other system users than if you've logged out. So here it is, my quickly done Gazpacho mock-up for the login screen:
Here nobody is logged in (although that shouldn't make a difference). The GTK theme is just the one I made/use by the way so this should be made customisable with a default theme. The text at the top is the system message (currently the default is usually "Welcome to [hostname]"), so it can be changed to something more appropriate for large systems, and obviously the face browser can be replaced by a username entry box. The mockup above should be pretty usable for home systems though. Maybe another option would be to change the shutdown button to a "System" button with crazy network logon things and such.

When a user locks their session the screensaver starts like normal, but when asked to unlock it instead of the boring GTK selector currently used the same kind of thing will pop up (maybe using the locked user's GTK theme, maybe not) and will look something like this:As you can see it is basically the same. Importantly the user is shown to be logged in, so any "AAA! My work wasn't saved and it logged out!" scenarios are reduced, maybe an "emblem" type picture could be put on the face browser to indicate this. The notifications in green were just an after thought, but may be useful (and should be easily enabled/disabled for privacy). Also, keep in mind that screensaver hacks can run in the GDM background, so the UI difference there is not too drastic either.

So there you have it, the first mock up I want to make for Warbuntu (please note that the name "Warbutu" is a mix between Warbo (me) and Ubuntu, and has nothing to do with killing people. Also note that Warbuntu is pronounced "WOAHBUNTU!", as I will probably explain when it gets its first incarnation).

Please leave any thoughts and remember that this is a little experiment of mine, and not directly intended to replace the current system, just to encourage more out-of-the-box thinking (ewww... I just said "out-of-the-box thinking"). Also, if Canonical want to give me their UI job then I would be damn pleased :D http://www.ubuntu.com/employment

Update: I thought I may as well link to some other user interface things I might put in Warbuntu. First there is my Usplash proposal: https://wiki.ubuntu.com/Usplash/EdgyPropositions (at the bottom), then there is my idea for an APT "Service Pack" maker, ie. an easy way of installing loads of Debian packages at once (personally I think my idea [scroll down] is easier to implement, easier to use and more powerful than the main one being discussed in that page, and this may be the first one of my mockups to come to fruition). I might add some more if I can remember them :) Oh, and a big thank you to Steve Jobs for the EMI non-DRM thing. I might pay some people to get me some non-DRM songs from iTunes for me, to show my support (also, I assume they expertly tweak their encoders to get much better quality than I could hope for with Grip since I just press "Go" :-) )

Another Update: I also have the GNOME preferences thing to work on that I comment on here. Toodle pip.