Ionrock Dot Org

Sunday was day three for my little experiment and since I have a project due, that was my last day. While I can't say that I made any amazing discoveries, it was an interesting little experiment. The one obvious detail that came from my experience is the role of learning. I have done a bit of research on how learning plays a part in usability and my experience has confirmed this for me (on a personal level, btw). More specifically, the idea that learning a UI is not only about finding a comfortable work flow, but trying to avoid any major changes in the UI. In my situation, I found that trying to program in an editor that doesn't have the same key bindings as Emacs made me have to relearn my work flow. Today, when I started using Emacs again, I found that I wanted to hit the back button the browser with my mouse instead of using Alt-back arrow. This is a very small change but, I am positive it is a relic from my short time staying away from the keyboard.

What I think we can take from this is the more we can make applications consistent across the board, the better chance we have of making new applications usable. We already see this kind of thing in graphics applications such as in the Adobe Suite. All the applications emphasis the same basic organization of the work environment, which in turn makes all of them more usable by reducing the need to relearn or learn a different interface. This all may seem rather obvious but it clearly is not the trend. We do not stray toward using the same basic interfaces for similar applications. I would project this is due to the fact that free software is full of creative minds that don't want to stick an app's UI into a mold. I this is fine by the way.

I think there are ways we can start addressing this inconsistency in hopes of letting users rarely have to change their workflow. I will try to write my thoughts on this later. For now, I will disconnect my mouse and get back to Alt-tabbing and Ctrl-Page Up/Down lifestyle. On a positive note, I did find a bug in Firefox (1.07 that ships with Suse 10). When you click close the edge of the back button on any edge (top, bottom, right), the back button history drops down. I did file a bug report. I am going to test the newer versions to see if this is fixed.

One thing I have observed by using the mouse is the fact that it takes so much more precision. When I use the keyboard, I may mistype things but I always know about my error immediately. The mouse on the other hand, manages to hide as much as possible from me regarding errors. A good example is firefox. I try to click the back button and get the history menu in the back button. It seems that the area meant for clicking back is wildly smaller than I thought or there are bugs. I would file bug reports if there was any ounce of consistency, but alas, it is a mystery when it happens. There are even times where I click directly on the back arrow icon and I still get the stupid menu! I don't think this is all the fault of firefox of course. Some of the time I know I just miss the button and catch the menu button instead.

In addition to accuracy and precision, using the mouse requires more thought. This is not always a bad thing. Sometimes it can be helpful because I have to be sure I am on the right icon or menu item. This usually leads to less mistakes, which is a good thing. On the flip side, often times I find I have to think about trivial tasks such as focusing a window or changing workspaces. In fact, it is these tasks that are often the most frustrating because instead of seamlessly going from task to task, the jump from one application to another becomes more painful. So painful in fact, that I do think it potentially hurts productivity. I feel I rarely get in a flow. That said, I am pretty happy using the keyboard, so my feelings are really just frustrations. There is no reason someone cannot get used to the workflow, in which case doing work that requires thought really shouldn't be hampered.

One specific aspect I am noticing is the nature of work dictates the vast majority of my issues. For example, browsing the web in addition to writing code. Normally I am visiting documentation sites so I will position my browser and editor on the screen to help compare examples to my own code. The essence of this involves many changes from my editor to the browser and back again. Constantly having to change from the mouse to the keyboard is very disrupting in this case. I can imagine someone using the GIMP while browsing the web could have an easier time simply because the GIMP requires a user to use the mouse primarily. I am sure this has been tested a great deal in some way or fashion. It does make me realize the benefits of an IDE for programming outside of an editor like vi or Emacs simply because it requires fewer changes to other applications. Of course, there are Emacs users who would dispute this thought process, but being a person who uses many different programming languages, I have yet to use Emacs beyond a few primary functions.

I will probably continue this for a few more days. I am concerned that I am losing time simply because this has interrupted my work flow. My thoughts so far can be summed up with the following:

The most important aspect of productivity with regard to HCI is allowing a means of developing a work flow that is scalable and emphasizes accuracy.

We'll see how that pans out overall, but I think it is something to look at in more formal testing. I know we are looking into this in some fashion for BetterDesktop.org, so we'll see if my experience can help to come up with better ideas of how to test this sort of thing.

I hate this! I knew trying to take my hands of the keyboard when there is a perfectly viable shortcut would be annoying. The fact is, the feeling is downright painful! Well, that may be an overstatement, but it is annoying. The problem becomes clear when it is time to return to the keyboard. There is an initial state of reorganization that just can't be avoided. I can try to feel my way back to the home row keys, but when the typing begins and everything is one off, it makes me wish I had never left my beloved home row.

With that said, in some instances there is little to no difference in productivity. Overall, I would say that unless I am working on something specific such as an email or code, using the mouse is alright. In some cases, I would argue, that it is just as fast or faster than using the keyboard. Of course, I can't make any conclusions just yet. I must suffer a bit longer before bring back my Emacs and enjoying the magic of M-x never-leave-the-keyboard-land.

On the usability list there was a thread talking about shortcut keys and how they are displayed to the user. I was not following the discussion too closely. Well, one person mentioned that using the keyboard was actually slower and when folks disagreed, a link to an article by Tog came up. This sort of thing being of interest to me I took a look. I found I had read the article before but this time it got me thinking. Am I really faster by using Emacs with all its C-this and M-x some-command-that? One thing that makes me feel validated to contradict Tog is the fact the article was published in 1989. I don't know about everyone else, but I know I was not much for touch typing back then. In fact, I would think many schools still had a typing class... on a type writer!

My point here is that maybe it is time to revisit whether or not this studied result has changed. So often HCI people claim that user experience is very important in a users perception of how usable a piece of software or interface is. I think with the revolution known as the Internet, it begs the question of whether or not we can conclude that a critical mass of people have had enough experiences to change the previous "mouse is faster" mantra. I am not saying that this applies to all cases. When you talk about this sort of thing, most people when exploring an interface will and should use a mouse, while learning a few keyboard shortcuts can definitly be helpful. In other words, this issue is not either/or.

But, it does sound like a fun exercise! So, I will go away from my beloved Emacs for a week and see how it goes. I am thinking about trying Gedit for a while, since those guys are really nice ;) If anyone else wants to do the same, please email me at elarson (at) novell.com and let me know how things go. I will plan on blogging my experiences every now and then as well. Wish me luck ;)

If you are subscribed to the GNOME usability list, it should be apparent that it is not the most productive place. I am not saying that great ideas do not grace the email clients of those who are subscribed. I am also not saying that wonderful ideas do not spawn from the list. What I am saying is that the amount of code that actually stems from discussions on the list seems a bit less than it should be.

The root of this gap is pretty simple. FOSS developers are not required to do anything anyone on the list suggests. Of course, there is no reason they should be required to heed the words on usability uttered from the list. This would simply be crazy talk. But it does bring up the question of why is the list even around if no one really pays attention to it?

I don't plan on answering this. This problem stresses the FOSS development model in an extreme way. It brings up the fact that unless you can put up, you might as well shut up. What does this mean for the masses who dream of innovative UI design and interesting useful features? It means these people have an invisible hurdle that must be jumped before getting these ideas to those who will make them happen. By the way, this is a huge hurdle. It comes in the form of cvs, autotools, irc and everything else meant to make life easier for developers. These tools are obviously valid since there would probably be no GNOME without them. But, with these great tools comes the need for hand holding documentation, which is just not there.

I cannot see this hurdle disappearing anytime soon. In reality the learning curve to find out how to contribute is actually pretty reasonable (spoken as someone who is no where close to using these tools). What I mean is that since there are plenty of people using these tools very successfully every day. These people who use these tools have managed to show some sort of proof that they have some sort of qualification. This is what we need for usability discussions.

There is no obvious way to create this challenge that reveals that a person's skills are worthy of attention when it comes to usability and HCI. There are theories and the like, but there are really smart people who just have a knack for seeing problems or benefits of designs. Think of a high school kid who is a LUG president and has submitted patches to the kernel. Again, this challenge is not simple so I will leave it for others to think about.

What I will say is this. Usability and HCI research is still very new so we need to be aware of research about the research, which may shed light into what makes a person a good usability or HCI person. Does the person have a design journal? Does the person make mock ups especially annotated or read usability research? Does the person have a good understanding of project requirements? These may be a few indicators, but it is really tough to say. The important thing is that we need to develop good practices and see what is the relationship between a productive programmer and a productive usability expert. This will help us all use our talents more precisely I think, as well as get great ideas to developers in a way that they can and will use.

Finally, Better Desktop.org has been released. It is a good feeling that my work this summer is finally out there. I am also exciting about making changes and adding quite a bit of features. What I am not excited about is having to move things around and debug junk just because we didn't start on a Novell server in the first place. No use crying over spilled milk.

It really is a great project. The idea is really simple, but the ramifications are huge. There is so much data to collect on the videos that should be helpful to developers. While brutal at times, the videos showing people struggle with random tasks make it clear that there are consistent models and trends in how users work with computers. Of course there are also the videos that reveal basic bugs such as non working features or a bad text choice. All and all, I think any developer who spends some time watching the videos can really get a better idea of what users really do with software.

Oh yeah, and it was on slashdot too ;)