Multiple Ways to Do It

By do it I do not mean sex! What dirty dirty minds you all have. Infact I want to talk about the dual of limiting user choice. My post on limiting the number of choices a user has to make, has an obvious corollary in that you want to give the user multiple ways to accomplish a task.

A classic example are the cut-copy-paste operations. Windows/Linux/Apple all have three distinct ways to cut/copy/paste.

1. Select the text and goto the edit menu and select the cut/copy operations. Similarly goto the edit menu to paste.

2. Select the text and then use the right click menu to select the cut/copy operations, ditto for paste.

3. Use the keyboard shortcuts for the cut/copy/paste operations.

There are the three different ways to cut/copy/paste because, depending on the user they will prefer one way or another. Also if there was only one way to cut/copy/paste many users would never figure out how to cut/copy/paste.

Also the keyboard shortcuts are for power users (you can see this by observing run of the mill users who almost never use the keyboard shortcuts).

I want to make clear that the purpose of having multiple ways to do a task is to allow for the variance in how the users of your application think. As designers we want our application to be appealing to all of its users. This implies that we must have multiple ways to accomplish tasks because our users have different mental models of how the components of our application fit together. For example in Firefox you can create a new tab by (1) File-> New Tab menu, (2) Ctl-T Keyboard, (3) right click on link and click New Tab. Firefox needs all of these different ways to create new tabs because some users want to use the File menu, some want to use the keyboard and some want to right click. Any one of these ways is the “right-way” but the only way to keep our users happy is to include all three.

This post is almost the dual of the my post on limiting user choice. A big part of creating a good user interface is in finding the best balance between limiting choices and having multiple ways for users to accomplish their tasks.

Advertisements

Database Wrapper Objects

It’s common to use small wrapper objects around database tables. One object represents one row in the database table. For the sake of clarity the following is a simple example:

Database: Documents table, with columns (Id, FileName, Data). Where Id is an identifier for the object, I use a <a href=”http://en.wikipedia.org/wiki/Guid”>Guid</a&gt;.

A simple wrapper object for the Documents table would have the following pseudo code

class Document {
property Id
prpoerty FileName
property Data
}

The only issues are how to create new Document objects, how to save Document objects, and how to retrieve Document objects.

Since I’m young and stupid I had the wrong solution for all three problems.
First I created a separate Database class with static methods for Retrieving, Adding, & Updating Document objects. This becomes unmanageable when the number of wrapper objects for the database gets above 10.

The correct solution is to
1. Create a Save() method for the Document class that intelligently either adds the document to the database or updates the existing document in the database. Thus the user of the document class doesn’t need to remember if they’re updating an existing document or creating a new document.

2. Have a single constructor for the Document class that accepts an Id. This constructor then creates a new Document object if that Id does not exist in the database or retrieves the existing Document object from the database if that Id is in the database.

By doing the above the creation and saving of Document objects is entirely consistent. This reduces the cognitively load on users of the Document class so they don’t have to think about the details of how Document objects are created and stored, instead they can concentrate their effort on other things.

User Interface Design

The below post has absolutely nothing to do with mathematics but it’s my blog so I can post whatever I want 🙂

So you’ve got this great business application. It has all the the greatest features, it does everything but clean the house.

The only problem is it’s way too complicated for your poor users to figure out. It has twenty different tabs just to change an email address. This is where good user interface design can make the difference between a successful application and one that your users (if you have any) absolutely despise.

One of the principles of UI design is to not give users too many choices. This comes from the
Paradox of Choice. Thus as designers we need to ensure that the user does not consciously make choices. One way to do this is to limit the number of choices for the user based on the context (typically the page they are currently at). The below image from Picasa Web Albums illustrates this by not allowing users to click on the current tab.

In the below example from Golden1’s website you can’t even tell which tab is currently selected.

A great example of reducing choice to improve the user experience is Gnome vs. KDE (which has configurations up the wazoo).

This is just one small example of what goes into UI design. For more info see http://ometer.com/free-software-ui.html, http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html, etc.

CGAL

I’ve been absent mostly due to lazyness (also I’ve been having lots of fun outdoors see http://picasaweb.google.com/Bryan.W.Bell). I’ve tried using CGAL. But everytime I end up quitting in disgust after looking at code like the following

template<class Kernel, class Container>
Polygon_2<Kernel, Container> rotate_polygon(const Polygon_2<Kernel, Container>& p, Direction_2<Kernel> dir){
CGAL::Aff_transformation_2<Kernel> t(ROTATION, dir, ERROR_FACTOR);
return CGAL::transform(t, p);
}

I hate working in an environment where half of your mental energy is spent parsing the syntax of the code. After years of working in good environments such as python and C#. The above code is no fun to look at.

For fun I’ve attached a figure of the typically problem when fitting polygons