Monday, April 28, 2008

I knew searching would fail

There is a great report about a usability test on the web about a guy
giving some common computer tasks to his girlfriend on a fresh Hardy
Heron installation. I found it via Slashdot but since fewer and fewer
people are slashdotting these days, so here is a link [1].

The tasks are well chosen and the user is _not_ a first time
grandma-type-user and approaches each task in the obvious possible
way. "Obvious possible" - for people not used to a Linux distribution,
where "doing stuff my way" rules over "getting stuff done".

As I started reading it, I knew at some point the user was going to
"search for something". And I knew she was going to fail. Which she
did.

The problem with most (all?) of the linux desktop search applications
is that they are cut out for a particular task and are (hopefully)
pretty good at it. Indexing is the keyword there - how to index all
kinds of data in the best possible way and then allow users to search
the indexed data. And there are lots of sophistication there.
Unfortunately the common search tasks by an user is not quite that.

- Search for a file by name - most common
- Search for files of certain types
- Search for files in home directory containing some text - slightly
advanced usage
- Search among browsed websites etc.
- As a computer "user", it is not clear why I would search for
websites in the desktop search tool and not in the browser. Of course,
once I am told this can be done in the desktop search tool _too_, I
would be extremely glad and nod in appreciation.

It takes time to write a desktop indexing and searching system. I
didnt believe it when I first heard of it and my friends asked me what
is so difficult about it other than implementing inotify. For some
reason it is. So a lot of effort in invested behind that. But there
has been less effort in presenting a failsafe, minimum capability
search experience in that direction. What do I mean by failsafe and
minimum capability ?

- One obvious way to launch the search tool (there could be more, but
there should be one which may not be the best but works in the worst
case)
- The obvious tool should never fail on the basic searching - never,
never, never. By basic searching I mean searching for non-file content
information - name, size, type (what on earth is _mimetype_ to a
non-CS/IT person ? searching by extension is what I mean. broad
classification like music, picture helps).
- Repeat the above. Let me say it this way - if the user knows a file
exists, she should be able to find it by name. And matches by name
should come _first_. Same for search by types.
- Anything else is a bonus. When we have complete semantic desktops,
where a file is same as an email and same as an addressbook entry,
maybe then users would want to search for everything or specify what
exactly she wants. Not now.

So where does beagle fall behind (or some of the others tools, by
reading about them and looking at their screenshots).
- User want to use them to search for files. The tools return pretty
much everything.
- Give them an option on where to search. There is no need to
include an option for "application/rdf+xul" but list the common
options. A search service has to work for the minimum, a GUI has to
cater to the average. I would be sad if it didnt have ways to cater to
the advanced crowd too but I dont mind if that requires one extra
step.
- User wants to search everywhere (in the filesystem).
- Thats definitely not what beagle was designed for. A beagle search
tool is not expected to do that. But when it is presented as the
_main_ search tool to the users, it will be used to search everywhere.
And it will fail.
- I dont quite know how to design a failsafe GUI search tool but a
good start would be use the indexing service to home directory files
and brute-force 'find /usr/bin' for non-home directory partitions.
- Some users would never need to search by content.
- If searching content was cheap then it would not be a big deal if
searching by content is enabled. But content searching is expensive
from my experience. It would be better if users are allowed to opt-in
for content searching.
- Content searching is not supposed to be expensive. As far as
beagle is concerned, it is halfway on meeting this goal. It still
needs some fault-tolerance feature to detect problems before too much
damage has been done.

There are lots of other ways to make searching "just work". The user
does not even need to know there is any indexing in the background.
The sad part is a lot of what I suggested (or could have suggested) is
already possible with the current beagle infrastructure. What is
lacking is someone with a good GUI knowledge to work on improving the
search experience. I am defending the base by fixing the occassional
simple bugs but a real developer is needed. And needed urgently
otherwise yet another distributions will be released with a lacklustre
search experience.

http://contentconsumer.wordpress.com/2008/04/27/is-ubuntu-useable-enough-for-my-girlfriend/

1 comment:

Anonymous said...

Gender bilingualism is not about designing a pink phone or increasing female share by reducing male appeal. It is about increasing the appeal to both men and women. Research has shown that “if you meet the expectations of women you will exceed the expectations of men.”

So what do women want?

A BCG study of 12000 women in 40 geographic areas studied key drivers and detractors in order to determine what women really want.
Complexity destroys value: The study showed that there is one problem that is common to all women globally - not having enough time. Women value any product or service that helps them make the best use of time. Conversely, they hate a product or service that wastes their time. Any form of complexity destroys value. We need to reduce the time to the desired outcome which means that every click destroys value. You might be thinking “but men want this too” and they do, but women are less tolerant than men. So if you meet women’s needs you will exceed the expectations of men. Aral Balkan (a top app designer) said “an app used to be finished when you could add no more in, now it is finished only when you can take no more out”… and that principal applies equally to software on our phones.

Experiences enabled by technology. Women want experiences that will help them solve their work/life challenges, or those that help create an emotional bond – or just some “me time” that creates a moment of pleasure for themselves. Perhaps a classic example of this is Apple’s iPhone FaceTime – where they have created an experience enabled by video conferencing. Although we have had the technology for years on some of our our phones, we have not shown the experience but instead focus on the solution – even now!

Design for me – women love brands that “get them”. This is both the exterior physical design and the ability to customize internally. Exterior design requirements are things like: timeless colours, one handed use, size and reach so that you can reach all keys – as women have smaller hands and often one handed use is essential as they are likely to be carrying a shopping bag, handbag, child, briefcase etc. So some of our product portfolio should have female first design requirements. Internal ability to customize means - does this phone understand “me and my needs” – just like Amazon shows that it “gets me” – because it recommends products I might like because other people with similar buying patterns bought them.

Value at best price – women will decide if the value of a product or service is greater than the price they will buy it. The danger is that if you over specify a feature – say a very high spec camera - you don’t add real value to a women but you increase the price. It may just tip that equation so that women won’t buy.