Archive for September, 2009|Monthly archive page

OpenSolaris on a Pavilion dv6

I decided to get adventurous and try out OpenSolaris on my HP Pavilion dv6 laptop. My goal: to find a solid OS that works out of the box or with little configuration on this fairly new laptop. In particular, sound and wireless are important criteria. My findings?

First of all, when I booted into the live CD, I got a horrible static noise from the speakers. It only took me a minute to think of plugging in my headphones to divert the racket. It turns out that the headphones don’t get any static. In fact, sound works perfectly on them (something Ubuntu can’t boast on my machine, try as I may to work through possible solutions). Lack of sound under Ubuntu was one of my main motivations to try another OS. But constant static is obviously worse than no sound at all, and I don’t always have my headphones plugged in.

Next, wireless support is practically nonexistent out of the box. The OpenSolaris community touts the availability of several wireless tools, but these don’t come installed and ready to go, which is one of my criteria. (I’m not the only one who has had this setback.) But wired ethernet works just fine. (In fact, I’m writing this post while still on the live CD on my laptop.)

Screen resolution is another disappointment. It thinks my widescreen is 1024×768 (which it’s not), and that this is the only supported resolution on my screen (which it’s not).

Nimbus

Nimbus

On the bright side, OpenSolaris has a nice GNOME theme: Nimbus. And the applications that come preinstalled are pretty standard: Firefox, Thunderbird, the usual GNOME tools. But if you want OpenOffice.org (or any office suite, for that matter), you’ll have to get it yourself from the package manager.

If you’re looking for a ready-to-go, easy to use desktop operating system that will support your hardware right from the start, OpenSolaris is not the choice for you. However, if you want some of the cool features it offers for server installations or robust workstations without these hardware issues, it may well be a good choice.

Google Docs and Dropbox

I’ve been using a couple of “online” products the last few days for managing my documents. The first is Google Docs. It’s a lightweight, online editor for documents, spreadsheets, and slideshows. Everything is stored on the servers of the ubiquitous Google. It’s (usually) readily accessible, but only as long as you have an internet connection. (No there is Google Gears for offline file management, but it doesn’t “officially” run on 64-bit linux, which is what I have. There is a package someone has put together, but I haven’t got it all to work yet…)

The other product I’ve been using in Dropbox. Basically, it allows you to sync files across multiple computers. It stores your files on their servers and even keeps revision and deletion history. You can set up the client on Windows, Mac, or Linux. Dropbox then synchronizes them all. If one of them dies, it’s simple to put everything back. And all of your files are accessible on your local machine if you don’t have an internet connection. And, obviously, you’re not just limited to documents, spreadsheets, and slideshows–you can put up any file you like.

What is my evaluation? Google Docs is a lot easier to use. No daemon to install, no separate account (assuming you already have Gmail). But if you need to work on a document offline and haven’t explicitly exported it or installed Google Gears, you’re out of luck.

Dropbox leaves everything in your hands. You have your own copy of the files, with which you may do as you please. No internet? No problem. And you have no vendor lock-in. You edit files using whatever programs you like. You keep them in their native format (which means no data or formatting loss during file-type conversions). Plus, you can even upload and download files using the web interface, making your docs accessible even on a computer where you don’t have Dropbox installed.

Final answer: Google Docs for the little things where I need a quick and easily accessible document. But Dropbox for reliable handling of everything else.

Want a Dropbox  invite? Shoot me an email or leave a comment.

Monocline grouping

The discussion on my previous post has necessitated a better explanation of the term monocline grouping.

A monocline grouping is a representation of data in a single layer (i.e., without a nested hierarchy). Let’s take my bookshelf for example. I have on the left religious books (including a few music books), followed to the right by Dutch and German books, and continuing on with literature and poetry books. And there in between are a few books that don’t really fit into one of those generalizations. And sometimes I’ve rearranged them out of their groups so they look nice on the shelf.

This is a very natural and understandable way to organize them. I can esaily access any book at any time, even if I’ve forgotten (or don’t care) which category I’ve placed it in. All the books are arranged in a single layer.

The problem with computer hierarchies is that they allow the user to nest objects of a certain type within objects of that same type: you can have an infinity of folders within folders which you must traverse before you come to a file.

Programmers understand this paradigm just fine; they have no trouble with it. But normal human beings are used to having things in monocline groupings. Even my file box is only one level deep: I open the box and there are all my folders. I don’t have another file box within that file box. (Now I do have manilla folders inside hanging folders, but the point is that I can see them all at once.)

Monocline grouping, as far as I can tell, is a term created by Alan Cooper, and it’s not very widely used by people not acquainted with his ideas. However, the concept is universal in its application.

As I mentioned in my comment (and as is mentioned on this blog post, a quote from Cooper’s book About Face 2.0), monocline groupings are not the end-all solution for everything. They can be very useful when applied with prudence.

Eliminating the hierarchy: GNOME Do and Google

This week I became acquainted with two applications: GNOME Do and Google Chrome.

GNOME Do is a program similar in concept to the Mac Spotlight. Although not quite as simple as Spotlight, it still allows you to find files, launch programs, and even search Gmail contacts.

GNOME Do and Spotlight both illustrate a concept Alan Cooper addresses in The Inmates Are Running the Asylum. (See my recent post on this book.) Cooper suggests how incredibly confusing hierarchial filesystems can be to users (see, e.g., pp. 9-11). Humans don’t think of file storage in a hierarchial way. When you’re writing something on a pad of paper, you might tear the sheet off and leave it on your desk. Or you might put it in your file drawer. That physical drawer has an advantage over a computer’s filesystem–it is much easier to see and comprehend the whole thing at once. You open the drawer and see all the folders inside it all together.

Now imagine your computer’s filesystem. You just wrote something on your virtual pad of paper. You “tear off” the page and want to put it somewhere. You click Save As…, and it opens to your usual My Documents folder. You put the file there and forget about it.

That isn’t so hard to deal with until you have to dig into the hierarchy of your hard drive. Imagine that you want to locate a file you worked on six months ago. It was a poster for the company barbeque you had in the spring, and you need it again. But where in the world did you put it? How are you going to find it now?

You could start clicking through all the folders on the hard drive until you find it. Or you could use a tool that eliminates the need to comprehend the hierarchial file structure in the first place, such as GNOME Do or Spotlight. Or the Windows search, if that’s the best you’ve got….

Those programs will let you search the file name or (more understandable for a human user) the full text of the file. Once it finds possibilities, you’ll still probably have to wade through a disorganized list to find the actual file. But at least you didn’t have to click through a hundred folders to get to it.

Google does a good job of implementing non-hierarchial file systems in their web apps, such as Gmail and Docs. You simply have lists of things, which you can further organize them with labels (and even use the labels as a sort of file-folder system if you really want to). And full-text searching is a standard, simple necessity.

Google Chrome also does an excellent job eliminating the hierarchy from the web browser: it has very few menus; your address bar, history, and web searching are all in the same box; you open a new tab and see a list of your most frequently-visited sites. No searching through menus of bookmarks or a confusing history pane. Just type in a keyword and it finds it for you.

After all, the computer knows where everything is anyway. Why not make it find things for you?

Inmates

I’m in the process of reading Alan Cooper’s delightful book The Inmates Are Running the Asylum. Cooper discusses the reason computer software is often so difficult to use. His main thesis: when programmers design software, they do it in a way that fits how the computer operates, not necessarily how a human being operates. It makes sense to them, but not to the average end user. This makes clear the need for so-called interaction design, as opposed to interface design. In order to be truly effective, this must be done by dedicated interaction designers, not by the programmers. The reason for this lies in the simple difference of how programmers think about problems and how normal people think about things. (Being a programmer myself, I can tell you that programmers really do have a different way of seeing the world. That view often doesn’t mesh with how normal people see the world.)

Cooper’s book dates from 1999. Things have changed in the realm of software interaction design since then. But he notes trends of the day that are still obvious in current software development. In chapter 5, for example, he discusses the concept of customer loyalty. He argues that Microsoft’s Bill Gates had tremendous business prowess and, as such, was able to get his company’s products to sell, imperfect or unpleasant to use as they may have been. People bought his things because they provided solutions for the problems they faced. They were driven by “economic necessity,” as Cooper puts it (p. 75). But as soon as something better comes along, the customers’ disloyalty will become apparent. They will be willing to switch to those better products without suffering withdrawl from their emotional attachment to Microsoft. Apple, on the other hand, has always had an eye for design. Their products were and still are attractive, and Apple has an incredibly loyal consumer base. Just think: how many people do you know who sport an article of clothing, bumper sticker, mug, or other object advertising Apple to the world? And how many people have you seen with similar products from Microsoft?

I believe that companies like Apple and Google have done much to drive innovation in the field of interaction design. Just think of the iPhone. How many smart phones have been developed in the last two years that look or act like the iPhone? A staggering number. But who thought of having such an intuitive, tactile touch screen before Apple did? And what mainstream email program is there that groups communications into threads besides Gmail? (If there really is one, please correct me.)

It’s issues like these that Cooper addresses in his book. I would highly recommend it to anyone desiring to improve the usability of their software. His current consulting company also has a blog discussing these topics.