The Ambiguity of Hiding Windows

So, Ubuntu 10.04 LTS has been released and it is pretty damn awesome. Again I don't think it was entirely ready, I think more time could have been spent fixing video driver bugs because there are a lot of people complaining about hitting a "black screen" (see my brainstorm idea: http://brainstorm.ubuntu.com/idea/24727/ ).

Anyway, one of the features of Lucid is the new indicator applet, designed to replace the notification area with a consistent interface. I love the indicator applet, except for one thing, this:



The indicator applet replaces the menu functionality for the icon brilliantly but it goes a little too far in replicating the functionality of the notification area. This is a long standing bug bear of mine. Many apps on Windows, and then consequently other desktops, allow minimizing an application to an icon. Why?


To clear the window off of the desktop? That's what minimize is for. "But.. but.. then it clutters my taskbar!" I hear you cry, and that my friends is the point, the minimize to icon functionality is  a workaround, a plaster over the fundamentally broken taskbar. The main problem with the current window switcher is the size of the elements. Even with a widescreen monitor you can fill it up pretty quick because window titles take up a lot of space. Application grouping helps to some extent but each element still takes up more room than the icon would do alone.

But that's not the only reason for the existence of "minimize to tray". When you are looking for a window in a list of windows, the less there are the easier it is. That's why you don't want Rhythmbox, or your IM contact list cluttering up the bottom. So the flaws with the window switcher are:

1. Each element takes up too much space
2. There are too many elements

You can also add:

3. You can't read the entire titles on the windows

We can easily solve these problems. Windows 7 had the right idea by replacing the window items with icons. We have a decent alternative on Ubuntu too, it's called DockbarX.

Don't believe me, try this. Add the DockbarX PPA and replace the window switcher applet with DockbarX. Now, make your Rhythmbox visible via the indicator applet and minimize it. Now go ahead and work with your computer. What do you notice? It takes up hardly any room AT ALL, in fact you won't even notice it's there because every time you go down to that Dockbar you'll be going there for an application window and finding the application is dead easy when its icon is right there and there is only one of them. Hover over the application icon and bingo, up pops the list of windows for that application with FULL TITLES.

Rhythmbox won't get in the way because you won't be drawn to it you are looking for a bright orange Firefox window for example. And you can open a shedload of windows and still have plenty of space in the taskbar. If you wanna skip a track, or see what's playing then you can do, using the indicator applet.

So, if there is one thing I would do if I was in charge of 10.10 it would be this: replace the window-switcher applet with DockbarX and remove any minimize to tray functionality from the indicator applets. It removes the ambiguity of "where did I minimize that window to" and it makes life much MUCH easier and consistent.

Where I'd put the buttons

Recently during the Ubuntu 10.04 (Lucid Lynx) testing cycle, Canonical introduced new branding and themes. The themes are really nice, still a little rough around the edges, but come launch date they will be slick. However, sneaked into this re-branding was a change that was initially thought to be a mistake.


The window controls moved.


The window controls (Minimize/Maxmize/Close) moved from the right hand side of the window, to the left hand side of the window. Not only that, but minimize and maximize swapped places; just to confuse everyone that little bit more.
Now, the problems with this have been discussed many times over the last week so I'm going to be a bit more constructive on the matter. I'm going to explain what they should have done in my opinion (!).

Now, let's get a few things straight. Firstly, if a button is at the corner of the window it is easier to hit. Secondly, if a button is destructive, it should not be next to a common action (in case of a miss-hit). Thirdly, I'm going to ignore right clicking, and double clicking on the title bar, these things are visually non-discoverable you need to find them by accident, and just cause you know about them doesn't mean everyone does. Got it? Good.
 
The Close Button

This is the one. This is the real cause of the complaints from users. There are two things special about this button.

1. It's destructive. The only really destructive of the three.
2. It's the most used. Of all the buttons it's the only one that must be there.

(Note, obviously, most used is dependent on user habits which is why we need usability testing - which I haven't done. But according to my logic it must be used at least once, which is more than the other two.)

Why is it the only one that must be there? Well, because you can use the taskbar to minimize or switch applications or you can resize the window to fullscreen. You cannot (in a easily discoverable way) close all windows without that button being there (before anyone says it; not all windows have menus).

So, because it's destructive, it should be well away from other common actions on the window. Let's take a look at a window shall we:

So, where do we put the close button? Well, the left hand side has a bunch of common actions, so we should probably steer clear of that side (take note Canonical!). That leaves anywhere right of the Help menu... as an applications can have many menus and can be resized so they are smaller, it would make sense to put it as far away as possible – so yeah on the right.

Now, onto usage, because the close button is the only action that must be performed, it makes sense to have it in a corner, that way you can hit it more easily. So, let's put that one there:

So cool, that's that one done, now let's move onto the next one...

The Maximize Button

So, arguably this is the next most important button, the reason? Well, you minimize to get to windows behind the one you are using, which you can do with the taskbar. Maxmize can only be done by drag-resizing (a pain) or right clicking (non-discoverable). So, after close it's pretty important. So, where do we put it? Well, a corner would make sense, but what if we put it next to the close button anyway? Well, there you've broken one of my rules above, you've put a common action next to a destructive action. So, let's just put maximize on the other corner:

Now the final button (or is it?)

The Minimize Button

So, this one is easy. It's a non-essential, non-destructive button. So, following logic it can go anywhere that's not next to a destructive item. Well, that just leaves next to the maximize button, but it doesn't need a corner so let's put it the other side:

There, for balance you should probably choose a theme with a centered title. But still, this layout makes more sense. You reduce the risk of closing something accidentally, and the most used items are in the corners. As a side effect you also keep two related options (minimize and maximize) close together.

What About the Menu Button?

I'm a bit ambivalent about this one, I'm not really sure where it belongs. The other three buttons change the size of the window (or make it go away) and don't pop-up a menu. It doesn't really fit with the others, (also the functionality is available on right-click, albeit undiscoverable). If I was to choose a position, I'd put it next to minimize, but I think it's arguable whether it needs to be included at all.

Conclusion

I'm no usability expert, but if I was to redesign the location of the buttons, (which, I'm not sure they need redesigning and breaking that muscle memory) that's where I'd put them. Also it has the pleasant side-effect that the close button doesn't move from the “normal” arrangement. I'd be happy if Canonical changed to this way, at least there is some obvious logic behind it... obvious logic makes me happy.

OpenALSoft/Pulseaudio: it's not me, it's you.

I learnt a valuable lesson this week. If you have rewritten your code 3 times, and your tests all pass and you understand every part of it and yet it still doesn't work ... it's probably something not to do with you.

Last weekend I decided it was time my game gained some sound. I'd just finished the game menu screen and figured that some music would make it seem a little more complete. In an attempt to follow the KISS principle I decided to keep it simple, I'd write a class that just plays an OGG file in 2D. No multiple sources, no bells and whistles, nothing fancy, just load an OGG and play it. A quick Google search turned up this gem of a tutorial, so I figured it was a 10 minute job. When the time came to do more, I'd look for a decent high-level library, or just steadily build on my simple base code but for now, I figured, following this tutorial would teach me a little OpenAL then I could move on.

And for a little while I was right. I wrote my class, loaded an OGG file and played it with OpenAL by loading it into a single buffer and binding the buffer to the source before calling alSourcePlay(). It worked!


...


For about 2 seconds. Then it crackled and went silent.

I assumed that the problem was the track I was playing was too long to be bound in a single buffer, and instead I figured I should break it into smaller buffers and feed it into the source to play. Possibly a bad assumption, I guess I should've tried playing a smaller sound to see if that was actually the case - but I was having fun, and queueing the buffers looked simple enough.

So I got to work, I decoded the OGG stream into a vector of vector<char>'s the idea being that as room became available in the queue I could grab the next chunk of data and queue it up ready for playing. Again, it only sort of worked. The track would buzz for 10 seconds, then play a second or 2, then go back to buzzing, then play some more. Sometimes it would play a whole 30-40 seconds perfectly, then the buzzing would start again. I fiddled with buffer sizes, buffer counts, filled my code with logging statements (the buffer queuing just seemed to stall while the buzzing took place). I tried to simplify it, removing lines of code, reorganizing until the code was slim and streamlined, I switched from vectors, to filling out static char* buffers. It made no difference.

I downloaded the source code of various apps, SuperTuxKart uses OpenAL and apparently the followed the same tutorial as me! In fact all the examples I could find had very similar code to the same tutorial, and my code looked pretty much the same.

This is the point I should have realized something else was at work here, in fact I did try upgrading ALSA but that changed nothing, so what did I do? I came up with a new design, one that had many benefits and might, just might have the side effect of solving the problem.

The problem with the previous attempts was I was loading and decoding the entire OGG file in one go. A decompressed, high quality OGG takes up a lot of memory, it's REALLY wasteful to decode the whole thing and keep it in memory. The other thing I had to be careful of was that multiple sources could play the same stream without an issue. I decided instead to load and store the compressed file data. Then create an OggDecoder class which each source gets an instance of that decompresses the data from memory on the fly. The benefits of this approach are huge, you don't hit the disk while playing, you keep memory usage down, and multiple sources can play from the same compressed data, and the code is pretty small too. So I finished, stood back and admired my work and pressed "compile and run". It worked! I was relieved. But just in case, I ran it a second time (it had *occasionally* worked before, it just wasn't consistent). You can guess what happened, the buzzing was back. Repeated runs left me with the same problem.

I was about to give up, about half way through this process I discovered cAudio which was basically where unintentional feature creep was pushing my code anyway (while trying to load an play a sound, I'd come up with a whole multiple song streaming solution with pluggable decoders!), so I figured I'd dump my code into the "deprecated" folder that I keep, and just use cAudio. Just as I was about to give up I found a forum post where someone had similar problems and they solved it by upgrading the OpenALSoft libraries. I gave it a try and lo and behold, it works!

I don't know why it works and didn't before, perhaps an OpenALSoft conflict with PA? Perhaps a bug in OpenALSoft? I dunno, and I don't care, if the problem occurs on another PC at least I know how to fix it.

The only regret is that I didn't realize it wasn't me earlier. I'd literally rewritten the code several times in different ways while comparing to code in other projects. Alarm bells should have rung earlier. Oh well.

Further Scene Editor Progress

So as I've mentioned a few times previously, I'm working on a scene editor. The goal of which is to make it easy to produce content for the many game ideas I have :)

So far progress is slow but steady, I'm being a bit of a perfectionist so large chunks of the code have been written at least twice, sometimes three times and there are still things I'm not happy with.

I'm currently working on importing Wavefront *.obj models. I know I've got a partial obj loader somewhere, I just need to find it, and integrate it. These are the goals for the first release:

1. Load and save irrlicht scene files

2. Create, manipulate, delete cubes, spheres, meshes, lights and terrains

3. Create, edit, delete and apply materials

4. Cut, copy and paste meshes

5. Manipulate the scene tree (make parent-child relationships etc.)

At that point the editor can be used to create landscapes. The following release will add:

6. Custom entity positioning

7. Advanced object properties (invisible, transparent, etc.)

8. Skyboxes

9. Octree based culling

And then some time later:

10. Python integration

11. More file formats

Criticising the Koala

So, unless you've been living under a rock for the last month or so, or you've been busy with Windows 7 launch parties, you will know that Canonical launched the latest version of Ubuntu, version 9.10 the Karmic Koala.

I spent launch day in #ubuntu-release-party along with over 1000 other people anxiously awaiting the release. I, of course, was already running 9.10, on my desktop, laptop and work desktop. I haven't had a single problem with any of them, post-beta anyway.

Still, I can't help but think that this particular release was a little rushed.

The updated boot splash is a massive improvement, and it saw a lot of work over the weeks up to the launch, but even here, there are a few niggly little issues... even now I still get an occasional worrying "Waiting to mount home" message underneath the minimalist white Ubuntu logo. The new X splash doesn't fade out properly all of the time, on my home desktop it never does. The background image showed visible banding on my highest resolution monitor, although this seems to have been rectified now. Also, I haven't seen a disk check in a little while, but the last time I saw it - it was scrolling past each percentage point. All these things show a lack of polish that I'm fairly sure an extra weeks development would have solved. Before anyone asks, yes I checked these bugs were reported.

I'm actually pretty impressed with the log on screen, of all of the artwork I'd say GDM and the white Ubuntu logo on shutdown were the parts where I actually thought to myself - yes this can compete with OSX. That said, I did feel there were better background choices on the Ubuntu wiki, and I do understand when users say it feels cold... because.. well it does, it's hardly sunshine and flowers is it?

Now, after log in is where everything falls apart. The introduction of the Humanity icon set was a step forward, but whoever decided that a bright orange background would look good with the new boot splash was frankly off their head. Why didn't they just use the same background as the GDM? Yes it's still dull and brown, but at least it would have been consistent.

The GTK theme changes were just a mess, the window borders have changed to a dark muddy brown, the previous Human colours at least would have matched the orange background slightly... the whole desktop theme seemed like a last minute rush because all the time had been spent on boot. Again, a week longer and we could have had that extra polish that Ubuntu deserves.

Still, this is just the beginning of the design work, hopefully 10.04 will get this stuff sorted once and for all.

Generally speaking, functionally Karmic is running well for me. My ATI based desktop still has slow minimising when Compiz is enabled, I really hope this is fixed soon as it makes the whole desktop feel sluggish. I've grown accustomed to the way that notifications are displayed, however I still believe that positioning them at the bottom of the screen would get in the way even less, and I stand by my feeling that the position should be configurable, because no matter where the notifications are, they will get in the way of some application that a user regularly uses.

Pulseaudio has really improved this release, I haven't had a single sound issue so far, however it does sadden me that Ubuntu still aren't paying attention to upstream (e.g. the removal of rtkit) although I've heard there is more communication going on now.

Empathy. If there was one thing I would say was a complete bloody mess in 9.10 it is the premature replacement of Pidgin with Empathy. I know that Empathy is the future, but that future is not here yet. Empathy is still buggy, it looks like a mid 90's throwback and it still lacks the many features that Pidgin offers. I don't understand why there was such a rush to replace Pidgin before Empathy was ready? Still it's easy to swap it out for Pidgin so I guess I can't complain too much.

The indicator applet is nice, although I do wonder why I can launch applications there when there is a perfectly good applications menu. I thought introducing more than one way to do something was bad from a usability POV? It makes the whole point of the applet ambiguous. Leave the launching of applications to the applications menu, and leave the indicator applet to well, indicating notifications.

The Software Centre is a massive improvement over Add/Remove, I do wonder whose idea it was to give it a blue background though. So now we have black, white, brown, orange and blue. Talk about consistency! I thought Mark employed a design team! I also still don't agree with the "Close" menu option though, it should definitely be "Quit" IMO and I don't buy the excuse I was given on the bug report. "The Ubuntu Software Store has no need to require users to know whether it is "running" or not"... what? Course they do... they opened the bloody thing.

So lots of little issues, I'll continue running 9.10 but I don't feel that this was Ubuntu's best release (9.04 was) but there have been a lot of changes (new GDM, GRUB 2, Xsplash etc.) that will hopefully mature over the next 6 months to form a solid base for 10.04, being an LTS, this is the release to watch.

Scene editor progress...

So, I've decided to focus my spare time on a couple of projects rather than continually fiddling and investigating the source code with a myriad of OSS projects (Wine, notify-osd, ATI Linux drivers, etc. etc.) I've set myself an end goal: to write a decent 2.5D platform game.

There has been this idea for a game on my mind for some time (and I've blogged about it previously). I know how it's going to work, I know what/who the main character will be, I've thought about all the intricate details of the gameplay. So now, it's time to actually get coding on it. I decided to use Irrlicht as the graphics engine, but (as I've mentioned before) it wasn't long before I hit a little road block. Irrlicht's main scene editor is IrrEdit - a Windows-only closed source editor which unfortunately doesn't run under Wine. I did look at patching Wine, but it's not a trivial fix.

There are other methods of content generation for Irrlicht; Blender, Deled etc. But Blender was more complicated than I liked, and Deled suffers the same problems as IrrEdit.

So, I decided to brush off a project of mine that had stagnated a bit; my scene editor - Kazscene.

Previously I'd written it using wxWidgets, but I suffered quite a few issues with wx's GL canvas widget. So I ported it to Gtk+ and used GtkGlExt which is working like a charm, using Glade as a UI editor is awesome too and the whole application seems snappier in comparison to the wxWidgets version.

So, porting took quite a bit of time, but since I've focused on writing a lot of the underlying infrastructure, (re)organizing the code and coding features. At the current state the application is still essentially useless (it doesn't load or save yet). But at the moment it has the following:

• A scene graph
• Terrain generation from a heightmap
• Cube creation
• Rotation and translation of objects (still buggy)
• Selection, mouse-over highlighting
• A virtual file system (allows reading from directories or zip files, with help from PhysicsFS)
• Smooth and flat normal generation

What I'm working on at the moment:

• A texture manager and material editor
• Python interpreter integration (using boost::python)
• Ogre and Irrlicht file loading/saving

Here's a screenshot:



It's getting there, once I get material editing and scene loading working, it'll look more impressive :D

When will the music industry get it?

So the illegal file sharing debate is continuing to rage on and I guess really I just wanted to throw my opinion out there, because unfortunately the industry still doesn't understand. They don't understand the technology, they don't understand what's at risk and they obviously don't even understand their audience.

Let's get the first most important myth out of the way. A shared file is NOT a lost sale. How any one can believe that's the case baffles me. If an artist has a good album, I will go out and buy it, probably physically on a CD, then at least I have something to show for it, or perhaps from Amazon on MP3. Now, if I'm at work, and my newly bought album is sitting at home, I will feel no guilt WHAT SO EVER about downloading it over bitorrent, I've paid my money to those concerned. Of course that's not the only situation, some people will just sit at home downloading the tracks from bitorrent and not buying anything, but wait, file sharers actually buy MORE music than non-filesharers. Granted, there will be a minority that don't pay, but those people can't copy the experience of a live GIG can they? Which brings me to my next point. File sharing is the single best method of promotion out there!

The Internet has presented right at the feet of the artists is a network of free advertising. Leak a track onto bitorrent and EVERYONE will be talking about it and the majority of those people will then go and buy the album. New artists can build a following on file sharing sites that will attract people to their gigs and to buy their merchandise. Lily Allen, an artist I have a massive amount of respect for, who built her career from MySpace, apparently can't even see that file sharing is essentially the same thing: a free method of advertising. 50 Cent gets it, hopefully more artists will aswell.

Now let's get to the important issues. The technical side of this, imagine the Internet as a massive postal service, except literally millions and millions of letters are sent EVERY SINGLE SECOND all around the world. These letters are known technically as "packets" of data. There is no way on Earth that anyone can do all of the following:

a.) Monitor all this traffic
b.) Determine which traffic is file sharing
c.) Determine that said file sharing is illegal

Torrents are used for many many legitimate causes, including software distribution, free music, videos, and images, etc. blanket banning it would be like banning all phone calls because you might insult someone. Even if it is possible, you really want someone snooping all your emails and messages? If illegal filesharing in it's current form is stopped, then everything will just move to encrypted methods, there will ALWAYS be a way.

The real problem is this, the music industry is broken. The music industry needs to adapt to changes in technology just like everyone else, they can't just sit there trying to force through legislation that makes 1 in 10 people a criminal just so they don't have to change their business model. Recordable cassettes didn't kill the industry, file sharing won't either. The only thing that will kill the music industry is itself.