Gnome 3 First Impressions

Last week, I decided to pull the trigger and install Gnome 3 on my Ubuntu laptop.  I made an attempt to embrace Unity when it was first released — that didn't last long.  Aside from a few configuration disturbances, my first impression is that Gnome 3 rocks.

Time for change
So why change at all?  I've been using a Gnome 2 desktop environment for years.  It looks good, it works as you'd expect a desktop to work, and it's open source — all good enough reasons to stick with Gnome 2.

However, things change.  Sometimes a radical departure from the norm is necessary to spearhead innovations.  This is true of any discipline — not restricted to desktop environments, nor information technology in general.  Every field occasionally partakes in a drastic shakeup.  Otherwise, be become too complacent and nothing ever happens.

Ubuntu recognized the potential user experience improvements — improvements in how users engage the operating system.  Not minor tweaks, not smoothing out rough edges, but an exorbitant change in the fundamental workflow.  Ubuntu introduced Unity as an enhanced desktop experience.  Not a new desktop environment, but a guise for the traditional Gnome 2 environment.

I was intrigued by this idea and was looking forward to what Unity would look like and how it would change my daily routine — hopefully for the better.

The failed experiment
Once the shock wore off — the shock of my desktop being transformed into something completely foreign — I started to familiarize myself with Unity.  At first, it seemed like it had potential.  While I was still acquainting myself with the new Ubuntu, I started to listening to some of the frustrations voiced by the Ubuntu user community.  The unanimous question about Unity seemed to be how do I turn it off?

Hearing almost nothing good about this new environment, aimed at making life easier for users, I found it difficult to ignore.  Granted, many complaints about Unity I was taking in were a little nit-picky and couldn't relate to.  So I carried on, determined to change how my desktop worked for the better.

I must say, I admire the ambition behind the project — Unity definitely had potential but there were just too many minor issues.  Aside from the bugs, Unity just didn't mesh well — didn't feel like part of the desktop.  So more than just subtle bugs — Unity was a failed experiment in desktop experience.  Once I switched back to Gnome 2, in it's traditional form, I felt home again.  It was like I had gone on a vacation and had everything go wrong.  Switching to Gnome 3 felt like a permanent vacation.

Almost, getting there...
I used the traditional Gnome 2 environment happily for about four months after turning Unity off.  Then my restlessness desire for change kicked in again.  I knew Gnome 3 had been released, why couldn't I try it out?  It seemed like the logical evolution for my desktop environment.  Luckily, I found a guide that helped me get Gnome 3 going in about an hour.

This was last week, so I'm still a new citizen here.  Gnome 3 has a semblance to Unity only it doesn't feel like an addition to the desktop.  The enhancements in Gnome 3 truly feel like part of the whole experience.

One common goal both Unity and Gnome 3 have is to better utilize the screen space.  This means that you don't have a static task bar that shows the user all their currently open windows.  The idea instead is to only show the currently running applications when it really matters.  Like when I want to switch windows.  In Gnome 3, I just click activities in the top left of my screen.  This gives me a nice preview of what I have open at the moment.

Let's say I want to launch a new application.  I can click activities again to see my favorites pane where I've added my commonly used applications.  However, there is also the application menu, beside my currently open windows.  I can click here to browse applications by category.  This is handy if I don't know off hand the name of the application I want to run.  Alternatively, when you click activities, you can just start typing the name of the application — this will bring up matches for you automatically.  I've found this to be an incredibly powerful feature.  I hardly ever use the favorites pane in favor of just typing a few characters and hitting enter to launch something.

In this era of streamlined desktop environments — one where space is of virtue, it's sometimes difficult to find your way around.  I don't think these radical changes brought on by Unity and Gnome 3 are workflow defects, just something new and different.  We've been using the standardized desktop layout for a really long time.  So even if this is the sub-optimal approach to desktop computing, it's what we're used to.  We've grown attached to the way we do things in our local environments, I know I have.  Change is difficult, but Gnome 3 makes it a little less painful.  It isn't perfect, but I truly believe it is a step in the right direction.

Cannot Reproduce

So what exactly is the course of action when a development team cannot reproduce a bug that has been reported? Do they simply tell the customer they are out to lunch and that everything is working fine? Well you obviously can't tell them that if you expect to keep them on as customers. That would be like a doctor telling you that you're fine because nothing showed up in his tests. You know your not fine.

And that is how the customer feels when they encounter bugs. They don't need to hear that your tests cannot replicate the same problems they are having. Their pain is real. Even if your unit tests are telling the team everything is in perfect working order doesn't make it so. A customer coming to you with problems can mean any number of things. Your unit tests could themselves be buggy. Or they could just simply be missing something. Humans create software and so the software is prone to human error.

Customers are also humans and just letting them know that you are genuinely concerned about their experience with your software will get you a long way. Even if it takes a while to track it down, the problem does exist. So step-by-step, work it out while keeping the customer posted. And if there isn't a bug in the software, the user is still complaining about something. Otherwise, you would have a perfect product. I've never seen such a thing, so there is always something to aim for.

Busy User Interfaces

There are good user interfaces and there are bad user interfaces. It is hard for users to explain what they like about the good user interfaces. They are just good. Designers who create these user interfaces often know when they've built something that is, just, good.

It is easier to talk about what makes bad user interfaces bad. Some, are just plain ugly. There are zero visually appealing aesthetics about it. This is becoming a less frequently encountered issue though because CSS makes theming applications much easier. The colors and shapes and general layout can start off right, and be made into something bad.

User interfaces transform from something good into something bad usually because of over population. It simply looks too busy. The naturalness of the interface is overshadowed be features. And many of these features probably aren't even needed.

However, eliminating features simply isn't practical, or even possible, in most cases. So all the user interface designer can do in these circumstances is migrate the overpopulated visual elements somewhere else. The current page, the one that is too busy, can often benefit from containers. It is an easy way to hide things that add to the current chaos.

A popular container type is a tab. They are a very intuitive construct for the end user and are easy for the designer to make look good. One still must be careful when using tabs though because they can also be overpopulated. The last thing anyone wants to see are two dozen horizontal tabs across the screen. Another thing to watch out for are sub-tabs, tabs within tabs. Try to avoid these wherever possible as they are hard to get right.

There is a balance between the total number of container elements and the total number of elements within the container. Too many of either will most definitely yield a bad user interface. But if the designer can strike the best balance possible while maintaining the visual appeal, that is when it is time to start talking about removing unneeded features.

Moving Away From Open Source

This entry over at IT world discusses some of the forces behind users that fully intend on using an open source application and make the jump over to the proprietary software world instead. It seems counter-intuitive that any user would will give up something that is free just to pay for it. But as the entry states, there are many reasons users do this. Open source applications tend to have a lack of support, lack of features, and lack of documentation. Oddly enough, there are some open source applications that share the same qualities as their proprietary counterparts. They both have a great feature set, documentation, etc. But like all software, the subtle differences can simply make one application better than the other.

The biggest stumbling block is installation and initial configuration of open source applications as far as I'm concerned. Proprietary installation and configuration procedures are generally a more enjoyable procedure. This is the first step to using any application and is important to get right because it gives the user an impression of what the rest of the application experience is going to be like was it actually gets installed if ever.

Rich clients are still better than the browser

It seems to me that the user experience one gets when using a browser-based front-end, leaves something to be desired. That's not to say that the browser front-end hasn't come a long way, I just don't think its quite there yet.

The main issue I've come across when building or using web browser interfaces, it the lack of cross-browser support. The browser is a lot like an operating system in that there will never be a common ground between your users. There will always be Windows users and there will always be Linux users and there might always be Mac users (there aren't any die-hard Mac users anymore are there ;)).

The difference being, of course, that with rich clients, the main difference is in how the GUI library of choice is built. The implementation generally stays the same. Even if two browsers support the same feature/syntax, it is never guaranteed that the feature/syntax will remain functional. Just because your rich client is not delivered over HTTP and rendered by a browser, doesn't mean it can't function as a web application. As you probably know, there are countless rich web applications in existence today.

On top of it all, rich clients are much more reactive to user input. This is because there is no javascript to execute which is terribly slow (although it has come a long way). The user experience could potentially be bench marked by test users. Your application could have a web front-end, as well as a rich client front-end. Your test users could then be used to inform you of which experience delivers the better experience.

I thing the browser will eventually be able to deliver a user experience at the same level of quality as a rich client can today. Just not yet. And I'm not going to attempt a guess at when that time will be because these estimates are generally wrong in this business.