Sunday, November 8, 2009

OpenOfficeMouse: An Epic Fail in Usability

Having been down for the count with a back injury for the last week, I'm a little behind the curve in keeping up with the news. I just learned about the OpenOfficeMouse, an open source mouse designed for use with the OpenOffice.org office suite. Upon seeing the picture, I couldn't believe my eyes and didn't want to, either.

This mouse is a usability nightmare and it's so ugly, it's oogly. If you don't want to mess with the press release, I'll give you the lowdown: it's a mouse with 18 buttons, 3 modes, a joystick on the side with 3 modes of its own, tons of optional extras, and tweakability beyond anyone's dreams or worst nightmares. When I first saw a picture of it, I couldn't believe my eyes that someone would come up with a product this bad. Warmouse did.

I've seen quite a few comparisons with Apple's Magic Mouse. I'm not going to go there -- it's been done -- but what I will do is detail what's wrong with the OpenOfficeMouse. There's quite a bit wrong with it, too, and I'm not even referring to its appearance.

The buttons... oh the bevy of buttons available on the OpenOfficeMouse... where should I begin? It's almost as if OOM is a cross between a keyboard and a mouse, possessing two groups of seven buttons with the two primary buttons on the outer corners. The only differences between any of the buttons in each group are minor: slight shape differences, location, and, in the case of the primary buttons, color. It would seem that the designers forgot that a mouse is generally used by touch, not sight.

One original mouse idea went around at the Xerox Palo Alto Research Center (PARC) where it was designed. The concept, if you ask me, was very forward-looking: its three buttons had a different color and texture so that you could tell which button you were pressing by how it felt under your finger but easily specified on screen, e.g. red-click. Aside from the mouse becoming more rounded to fit the hand, not much else has been done to significantly change mouse usage since its inception at the PARC.

Button collections aside, there is also yet another major flaw in the mouse: the abundance of modes. Changing application behavior based on a button press or a checkbox is not generally a good idea because the user needs to adjust his actions according to the mode in use. Adding more kinds of modes places more mental load on the user. More technical users generally don't have a problem with this, but the difficulty they impose increases with the user's lack of expertise. Without appropriate feedback on the current mode -- considering the design flaws elsewhere in the design, is unlikely to be the case -- the different modes available both on the joystick and on the mouse in general will probably cause plenty of input errors, as well.

The intention behind the OpenOfficeMouse is to improve the experience of using the OpenOffice office suite faster and/or more easily. Unfortunately, unless you're an incorrigible tweaker, this mouse isn't going to help. The solution is to fix OpenOffice. Software is MUCH more malleable than hardware.

Wednesday, November 4, 2009

Pondering the Next Moves for Paladin

It's been quite a while since I reported on any development I've been up to. There hasn't been much, but I have been doing some Paladin hacking. For probably a month now, I've been attempting to figure out what direction Paladin development should take. The development branch has received some changes to add support for different project types. If I remember correctly, BeIDE had something like this which it called stationery. There is also a code library feature which has pretty good potential, but I've noticed some major architectural issues in its synchronization code and also in other areas. The only problem is that there is other code, such as the Project class, which needs significant changes in order to make it work well, so I've begun doing some experimental refactoring. The nice thing is that I'm building in some more flexibility into the code. It should make for a more powerful build system... it should also be interesting to see how well all this works out. TTFN, dear readers. :)

Friday, October 30, 2009

Karmic Koala is out...shrug

I was really excited last April when Jaunty came out. This time...not so much. Don't get me wrong, I like the new release, and the machine I'm typing this from is upgraded to it pretty quickly, but from the perception of Joe User, it seems more like an LTS upgrade. Here's what I've seen that's new:

First, there is the usual shiny. The icons are different. This version includes some nice wallpapers, and the boot process was made shinier by replacing Usplash with Xsplash. Of course, there is just this odd-looking Ubuntu logo while you're waiting for it to appear. The Xsplash screen is just plain gorgeous, but vaguely-beige logo that shows up beforehand is at least one step back. It's just ugly.

Once again, boot times seem to have been improved. I can't put my finger on it and I haven't bothered to time the differences, but it certainly feels faster.

A few new apps and some changes to existing ones. Network Tools adds some standard tools like pinging and port scanning, but nothing that wasn't already easily installed by those who needed it (or skipped if using bash). The Disk Utility is a nice addition, but it's only a mild improvement over gparted -- SMART information and a different way of looking at the partitions. The Ubuntu Software Center is even simpler than Add/Remove Programs was. As if IM using Pidgin was hard, as far as I can tell, Empathy makes A/V chat easy. A bunch of programs received upgrades, such as Firefox to 3.5 and OpenOffice.org to 3.1. Aside from these kinds of things, nothing earthshaking.

One notable exception to the otherwise nice-but-not-groundbreaking list is Ubuntu One. Now by default there is cloud storage. For cheap power users like myself, the 2GB storage is just a drop in the bucket and with the US economy being in the toilet, spending $10 or $20 a month for extra storage just isn't an option unless you *really* need it. Dropbox has the exact same storage costs and is cross-platform, unlike Ubuntu One. If you need cloud-base file synchronization with at least one Window$ box, this is a much better option. Still, Ubuntu One is nice, too.

Maybe I was expecting more because some of Canonical's previous releases have been major improvements. Karmic Koala is more of an incremental improvement. There are other big fish to fry, such as simple remote desktop access with FreeNX or a decent entry-level desktop publishing -- sorry, Scribus doesn't cut it in this case. Yes, these are "merely" apps, but there are plenty of improvements that can be made. I'm hoping Lucid Lynx makes some real headlines, but for now, I'm quite content with Karmic.

Saturday, October 10, 2009

One More Feather in Haiku's Cap

At the end of last week, I ordered a new computer that came about the middle of this week. It's an Athlon II 2.6 Ghz quad core system. I was so excited about it coming, and now that I have it, it feels like a Ferrari compared to either of my other two machines. Zeta doesn't run on it very well, so that's a small bummer, but Haiku runs perfectly... no, unbelievably. It just gets out of the way. How well? I ran 4 instances of the Haiku3D demo at the same time, and all 4 CPUs were only at 50%. Compiling the Capital Be beta from source with the development Paladin took what seemed like no time and didn't even come close to maxing out all four cores, and as far as I could tell, it couldn't compile faster because gcc was I/O bound. Not only the Haiku run well on old or low-power hardware like netbooks, but it is even better on fast machines.

Sunday, October 4, 2009

Making Up for Lost Time

As if it weren't already obvious, I'm not off the radar yet. ;-) Just one day after the 1.1 release, I spent this evening hacking on Paladin and adding support for project templates. I never really bothered with it until tonight when I wanted to hack together a quick-and-dirty development tool and wasn't happy that I had to write some more boilerplate code. Bleah. I'd toyed with the idea long ago, but didn't bother for some reason. It's nowhere near what I'd like for customizability, but works pretty sweet for saving some initial project creation time, so here's one nice feature for 1.2. :)