The idea behind it is that our Social Networks online are not representative of our actual social network. As it turns out, this is in fact the truth: the average person only communicates with 5 – 7 people in their intimate circle, using technology. Facebook is also quite interesting: the average user has about 120 friends but two way communication only takes place between 4 -6 people, depending on your gender.

It does make me realize that Social Networks don’t adequately deal with the fact that our actual relationships are vastly different from those depicted on our online profile.

(Sources are at 1:30)

Whilst browsing the web might be an extreme example of how this is done (wrong), even smaller changes in input or output can change the interaction methods. Example would be having an extra monitor. The fact that I have two impacts my usage pattern in the sense that I switch less between windows, do much more dragging of content between visible windows, or might have a harder time finding where my windows are hidden.

A more subtle example would be having a scroll wheel on a device that enables you to navigate very quickly through lists (A), vs having to press a button every time you want to go up or down in the list of items (B).

At first glance the implications of this are simply that you’d have to restrict yourself on Device B with the amount of menu’s you can bury in a menu. This however, affects the entire application. Not only do you need to restrict yourself to the amount of items in the list, you need to design the application in such a way that all the features are still accessible. When you can jump up and down in lists without problems, such as in A, you can afford to have a very flat menu structure, perhaps only 2 levels deep. On B, because you can’t fit so much in one screen, you’d need to design in such a way that you can still fit in all the functionality, whilst dealing with the restrictions. It requires a much deeper structure.

This illustrates that even the smallest change on seemingly similar devices require you to think twice about simply porting over your interface from one platform to the next. I don’t read my physical copy of The Economist in the same way as I do with the online version. Why should mobile application be any different?

PS: thanks to Barry for the tip about the lectures.

The bad: As is often the case when booking airline tickets, you want to book months ahead. This means that you’d have to click through until you reach the month you want to fly in. If this 6 months from now, this leads to a lot of clicking. Accidentally clicking outside of the calender box removes the entire thing, probably causing frustration. The use case for booking tickets is also a different: you might be shopping around on various sites simultaneously, with 5 or 6 tabs open, in each one looking for flights on the exact same date. This means that you have most likely already chosen two dates and don’t need to be reminded on what day 12 December is. In this case you lose the advantage of having an oversight and the browsing becomes a tedious task.

Drop Down: Baltic Air

The good: Here we have exactly the opposite as at Lufhansa. Through a drop-down you select the dates, maximum amount of clicks: 2. Referring back to the use case of booking tickets, this quick input can be advantageous.

The bad Drop downs cover other navigation elements. You loose oversight of what day you are booking your ticket and a drop down certainly does not remind me of a calendar.

It needs to be mentioned: Baltic Air gives you the option to try both options, although they use a popup to achieve this.

Combination: Dutch Railways

The good:Initially I was skeptical about this pattern since I can name very few times (if any) that I have looked at tickets months in advance. Taking the train in The Netherlands is also more akin to taking a tram, which makes me question why such an elaborate calender is needed. However, I am sold on this because it combines the best of both worlds: a monthly oversight, and a quick way to jump to dates relatively far ahead.

The bad: I am curious how often people actually do check dates far ahead in the future. As with the Baltic air example, the drop down covers other content, which is never really good, but it’s a trade off.

To conclude: I don’t really think any of these are better or worse to such a degree that it is crippling usability. However, the use cases of these sites play an important factor in deciding what pattern is appropriate. For journeys happening withing short notice (buses, trains, etc.) the calendar might be good. For bookings 6 months from now, this might not always be the case.

But, is that really true? I am doubtful. I think the term “search engine” is actually very applicable. Of course, we know the browser is the piece of software that gets used to view the content (or access the web applications) housed online. But what we know it to be is irrelevant. It is what people actually perceive it to be that is much more important.

See, to apparently a majority of people, that thing they use to browse the net is simply a tool to help them find content. A search engine, packaged as software, that displays the results of searches, either entered into the address bar as URL’s, or in separate search engines such as Google or Yahoo!.

The fact that Google’s browser, Chrome has an address bar that doubles as a search input field is also very interesting: it is a radical departure and it makes sense not only from a usability point of view, but also from the mental model point of view that people have of a browser.

I guess what is most important to remember from that clip is that people actually perceive things in a (sometimes radical) different way than it was actually intended. Perhaps we should also design products that fit better into what people actually perceive it to be, rather that what we want people to perceive it to be.

EDIT: Turns out, the people in Rotterdam have the same idea’s when it comes to what they think a browser is. A bunch of students from my own University back in The Netherlands performed the same survey. Results were the just about the same. Video in Dutch:

For those unfamiliar with personas, they are a design tool that was created by Alan Cooper and elaborately explained in his book The Inmates are Running the Asylum. (My review here). As mentioned by Jeroen, they are not always implemented, the culprit being (perceived) high cost.

However, I am very convinced that the implementation of a persona (and not only as a outcome after a research process) is of extreme value when you see them as a boundary that you should stay in when deciding what goes in or out of a product. This is in-line with Jeroen’s first argument for the use: making design decisions. If the only function they perform is to set the boundaries and guidelines within which development will take place, they have served their purpose.

This has the very effect that money is not being spent on conjuring up feature that does not fit into what the end user is actually looking for. Might it be to too simplistic to say that this will actually save you money in the short run (development costs) and in the long run (better experience)?