iPad: Sit and listen, don’t speak

I recently had the opportunity to use an iPad for a while at work (I know, I’m already well behind the cool kids).  I found the device not wildly exciting, for two main reasons.

The first reason is that it is a single-user device, so in a situation where one has been bought for everyone to have a play with and try, the device is very nearly hamstrung. Admittedly with a little more effort I probably could have convinced the thing to talk to my itunes account and downloaded some free apps and cool stuff, but the fact that this was not obvious means this is not a device to be shared between people who don’t share passwords and credit card details.

The second thing that was more immediately obvious, and more confounding was that within even a few moments of interaction it was clear the iPad is very much a device for consumption, and not for production. Although the touch screen would make the ipad an obvious choice for some kind of gestural or pen-based input, this isn’t available (perhaps Apple are still smarting from the spectacular failure of the Newton?), and the native “keyboard” is noticeably clunky to use. This means that for all production purposes–even those which involve consuming media (such as annotating books or pictures, gestural photo or video editing)–that would seem ideally suited to a touch-based interface, the iPad in it’s native state is essentially useless. Even doing a Google search on this thing is hard. And while there are pens you can buy, and keyboards, and apps and all kinds of workarounds, it doesn’t change the fact that all of these things are not what this large and expensive piece of equipment was designed for.

I’m not alone in my assessment of these limitations of course. Larry Marcus says that the iPad is no replacement for a laptop unless you are primarily a consumer. Nathan Jurgenson at Sociology Lens reinfirces that prosumption is not where it’s at for the iPad. Jeff Jarvis, in his must-read review calls the iPad vapid and shallow, and points out how it is a move backwards from the open content the web made possible. Cory Doctorow takes it one step further and points out the iPad itself is a closed device. Jonathan Zittrain points out that even Apps don’t make the iPad open because they are vetted (and makes some very interesting points about a large antitrust suit against another technology company).

None of this is to say that the iPad doesn’t have a market; Jake Simms thinks “grown ups” will like it, Steve Myers reports on a panel at SXSW that suggested the iPad is designed for “laid back” computing, and Kathy E. Gill says we will have to wait and see how people use it in their consumption activities.

Personally, I won’t be getting an iPad; I have a netbook that does all the consumption things an iPad does except nice ebook reading, and there are cheaper ebook readers (if and when I decide to get one) and plenty of prduction things besides. While iPads are very du jour, I think they have missed a number of interesting interaction possibilities afforded by a touch screen, and I will be interested to see where they go from here.  Any iPad users care to comment on their use?

Kartoo was clearly not for many users at all

Phil Bradley posted on Saturday that Kartoo, the visual search engine I blogged about as part of the 23 Things programme, is gone.

Back when I posted about Kartoo the first time, I mentioned a number of reasons why it might actively alienate some users, including its treatment of culture and gender–this isn’t a good start for a search service trying to break into a market that already has such clear dominance (Google accounted for about 70% of all searches in December, and is working to expand its range of services and thus its market share).  Had Kartoo really offered something interesting, then it could have attracted continuing use from those it didn’t offend at first sight, but like I and many of my fellow travellers on the 23 things program discovered back in 2008, Kartoo also didn’t offer anything interesting or useful in its interface or its results (and in fact it was downright hard to use).  Given how much you have to offer to break habits that work for users, Kartoo fell far short of the mark, and while I’m not so convinced that it had nothing to offer that I’m glad its gone, I’m not surprised either.

Why users like federated search (even though they shouldn’t)

‘Federated Search’ is a library term, it refers to search engines that search a variety of library databases (things that contain journal articles, conference papers and the like) and combine the results in some way to be presented to the user.

Federated searching is a somewhat fraught topic in libraries; many librarians don’t like federated searching and are hestitant to recommend it to library users.  This reluctance is not without good reason–federated search is inferior in many ways to using native database search interfaces, including problems with relevance ranking, the false appearance of comprehensiveness, and the inadequate de-duplication that many offer.  On the other side of this, federated search offers the holy grail of library searching: a single search box (well, almost–federated search usually doesn’t include the local catalogue, though sometimes it does, as in this example at UNSW).  The single search box is seen as being “like Google” in offering users a lot of different content from one search–and even has a slight edge over Google scholar in that search results will usually reflect more closely than Google Scholar which results a searcher can actually access.

Federated search has some issues that would normally be pretty big rpoblems from a user perspective too:

• The relevance ranking doesn’t really work. Because federated search is pulling in material from a range of sources, each of which use different approaches to relevance ranking and different metrics to express a rank.  Any combination of these results is likely to produces flawed relevance ranking.  This means that often, the most relevant results will not be in the magical first couple of pages.
• Federated search is very, very slow.  Again, because federated search is searching a number of remote databases and then applying some metric to combine results before these are presented to the user, federated search is very slow. Typically users are unhappy with slow response times, so this should be a real problem for users.

So, we know librarians are often hesitant about recommending federated search, and that users have every reason not to like it…and yet study after study shows that users do like and use federated search.  So why is federated search so popular?

• One stop shopping: Federated search offers users a one-stop shop, and even though they know it isn’t as good, they will often use it anyway.
• Time saving: Despite the long load time for search results, users know they will save themselves time (and likely frustration) by visiting only a single site.
• Search syntax: Search syntax varies slightly from site to site, and federated search allows users to forgo learning the variationson syntax required by individual databases.  Given that we know boolean searching is hard (sorry, paywall), it is easy to surmise that learning less about it is considered a good thing by users.
• Low user expectations: Users expect library systems to be slow and clunky, so their expectations of federated search are lower than they would be for other web-based services.

Users’ willingness to use a system we don’t expect them to like is an object lesson in how usability principles are not entirely universal: Occasionally users will tolerate unusable systems over more-usable ones because the end result is still a faster and easier user experience.

So, does users’ willingness to put up with the limitations of federated search mean we should stop striving for anything better? I don’t think so.  I think that as web technology improves, users will have less tolerance for slow and clunky systems.  We’ve already seen this at Swinburne with the library catalogue–while it hasn’t changed our users surveys show increasing levels of dissatisfaction as a result of user expectations that have been raised by their interactions with other systems.  I don’t believe that users are going to be willing to individually visit library databases in the future any more than they are now; even Google is meshing different kinds of data in its search results.  I believe there is real benefit to be had for librarians and library users alike in making headway in one-stop searching, I’m very much looking forward to seeing Primo Central and Summon (the next generation of federated search, where metadata is locally indexed making search faster and relevance ranking better) in action.  In the meantime though?  Users still like federated search, even though it is slow and awkward.

One of these things is not like the others: Livingsocial’s recommender services

Last year I did an experiment: I logged every book I read, complete with tags about timing, subject matter, fiction or non-, andf themes, in Google books.  This was inherently satisfying to my curiosity (63 books last year, 24 of whiuch were non fiction), but was lacking something I’m interested in: a recommendation feature.

During the year, I discovered I could also log my books in Facebook, in a service that does have a recommender feature based on ratings (but no tags, sadly–I know, I should have just used librarything in the first damn place).  Thus I entered the exciting world of LivingSocial, which accepts ratings for books, albums, movies…and restaurants.

While I haven’t bothered too much with the music recommender service (though I should try, since my taste is all over the place), but I have found the book service and the movie service to be quite exciting–I’ve seen lots of books and movies I want to read/see.  So when I noticed last night that they also had a restaurant section, I was cautiously excited: I love food and I am always looking for places to try, but I suspected that it might be a US-only service.  It’s not, but I still wouldn’t recommend it to anyone, mostly because it doesn’t take into account the differences between books/movies/albums and restaurants:

• Availability of large, relatively comprehensive catalogues: There are a wide range of relatively-comprehensive online catalogues for books and movies–think Amazon or LibraryThing. The same is not true for restaurants: there may be listings in the local yellow pages for some towns, some of which may be available online, but these listings would be difficult to harvest and far from comprehensive.  As a response to this, Livcingsocial will actually allow you to add your own restaurant listings, but only after you have rated 20 restaurants.  If you don’t do a lot of travelling, and your city doesn’t have any restaurants listed, this could be a bit difficult.
• Location dependence: Subject to availability, playing equipment and local censorship laws, books/movies/albums may be enjoyed anywhere.  Restaurants, however, are only really available to those living or travelling (let’s be generous) within say 100 km (60 mi) of the restaurant’s physical location.
• Amount of information required to make a decision: Everyone has certain requirements of their entertainment, for example:  some people find swearing offensive, some people dislike science fiction intensely, some people cannot abide restaurants that won’t take bookings, some people are vegetarian.  Recommendations for books/movies/music are more likely to meet people’s requirements (going back to our example those who dislike science fiction will universally rate it lower, thus feeding each other’s recommendations) and even if they don’t, it is much easier to find out ahead of time that they are bad (in the example of swearing parental advisory stickers are a good clue). In the case of restaurants, however, there are more paramters in play (food, service, noise level, ambiance, wheelchair accessibility, child-frioendliness, diaetary requirements) and this type of thing is harder to tease out in a five point rating, and often harder to discover before making the time investment to actually go to the restaurant.

The restaurant recommender is based on the same principles as the other recommenders, the amazon style “people who liked x also liked y, and you like x so you will probably like y”.  My experience with it, however, was quite frustrating: I rated a significant number of restaurants (not without some difficulty, as there aren’t that may listed in Melbourne, so I had to go to other cities I had lived in), and then clicked on “recommendations”.  Most of the recommendations were for restaurants in the US, and there was no way to generate recommendations for a a specified geographic region.  If I were travelling to the US any time soon, this might be helpful if I were going to the specific cities where restaurants were recommended for me, but generally speaking, these recommendations are useless.

The problem here is that a model that works well for small physical items has been applied to experiences, and it simply doesn’t work–making the user experience clunky and ultimately frustrating, possibly more often than it is helpful.  LivignSocial would have been better to stick with wine!

Have you ever tried a product or service from a company that did other things well only to be disappointed?

‘Giving back something broken’ undoes all your good work and then some.

In Stephen Donaldson’s Second Chronicle of Thomas Covenant, the protagonist Covenant points out that ‘there’s only one way to hurt a man who’s lost everything: Give him back something broken’.  While that is certainly melodramatic for the tone of this post, it is something than rings true in user experience.  If your system does something good for users and then takes that something good away without good reason it will make the user angry.

Let me give you an example:  Long time readers of this blog will remember how pleased I was with the pre-pay option available at my local supermarket.  Recently the chain involved in that post has brought out a loyalty card which allows you to collect those four cent petrol vouchers on the card, rather than stuffed into your wallet.  This works particularly well for my partner and I, since we don’t own a car and therefore only rarely purchase petrol; it means when we do purchase petrol we can just hand over the card rather than having to remember to save the dockets and present them at the right time.

So far it all sounds pretty good, right?  The problem is, this card breaks the pre-pay option on the supermarket tills.  You can put all the information in, but when you hand the cashier your loaylty card, it cancels the transaction you have begun and forces the cahsier to start all over.

This problem takes a system that works in favour of the customer, and turns it on its head: the customer does the work of entering their information, only to have that work completely wasted.  It would be less annoying not to have the option to pre-pay in the first place. The supermarket needs to fix this problem, or remove the pre-pay option before they get into more loyalty schemes (as is happening in the next couple of months).

What experiences do you have of systems that were working really well only to turn on you at the last minute?

On signs, and the need to carry my camera everywhere

Recently, as part of my work, I have commented on a signage policy for my workplace. Signs fascinate me.  It’s a basic usability premise that simple objects should not need signs, but so often I see a sign that either isn’t working, or which (with a little thought) doesn’t need to exist in the first place. I really do need to carry my camera with me more often so that when I see signs like this I can take a picture, but in the meantime I will describe a couple of examples to you:

There are two ways ofr a sign to fail: not provide the information that is needed, or provide information which may be actively misleading to some or all of the population.  A library I frequent has only a male cleaner; as such when he cleans the women’s toilets he must hang a sign to alert them to his presence in the toilets.  The sign he uses reads “not in use”, and I suspect that this is supposed to mean that it is not in “circulation” (to borrow a liubrary metaphor, but hung on a library toilet door, it reads more like “vacant”.

Signs that don’t work are interesting, but signs that shouldn’t need to exist raise my usability analyst ire something awful.  Recently in a public building I noticed a photocopier with not one, but two signs on it letting users of the space know that the copier wasn’t working.  Now, it’s excellent that the people responsible for the building let users know the copier isn’t working, but two signs seems like overkill, and given that the copier is on wheels, why didn’t they just move it out of the public space?

Are there signs in your work or recreation spaces that make no sense?  I’ll leave you with one I found on flickr, taken by brionv:

The bottom sign reads "door is alarmed"

Human meaning in machine encoding? Thoughts on the semantic web

Tim Berners-Lee, the inventor of the world wide web, outlines his goals for the semantic web in the book he wrote about the development of the web.  I love his dream, that one day we would be able to ask “find out where a baseball game was played today and it was also 22C”.  I just don’t believe it is very likely to happen, for two reasons:

• Effort
• Natural language

The effort question is a really interesting one.  Somewhere along the line, someone has to expend the effort to make human semantic concepts in some way machine encoded, or, alternatively to answer their own questions.  For some, a certain level of machine encoding of the semantics they personally attach to an object (usually in the form of tags) is useful, either for some purpose of their own (information retrieval, for example), or for some social-capital reason (see a more detailed explanation of this here).  However, when a person has only a small amount of information to organise they are considerably less likely to add semantic information to it.

If there is no human being willing to expend the effort to add semantic information, there may be a human being willing to write computer programs to extract such information.  This will be more or less successful dependent on the kind of information to be extracted, and what it is to be extracted from, for example:

• Artist and title information encoded in mp3s are relatively easy to extract, where song lyrics are much harder (unless you combine the artist and title information with a lyric search on the internet).
• It is possible to (with a relatively high degree of success) automatically extract historical date information from free text (full disclosure: that is my work from a previous lifetime).
• Extracting information from a digital picture abut what it is of is quite difficult  (and an open research question), but if the pictures are born-digital photos information about the camera, the date and all sorts of other things is often encoded in them and easy to extract.

This is lesser effort than tagging, because it can be done once and used multiple times, but it is still effort that someone has to expend.

One further approach is, as in this paper (sorry, paywall), leveraging human-created tags to allow machines to do things that look like they understand the semantic web–so in the paper, for example, the author wrote a program that used the way people had combined tags on flickr to unsdersdtand what concrete things (for example tulips) were associated with abstract concepts (for example spring).

In any of the three cases human effort is required to generate the information needed for machines to do the kind of processing Berners-Lee suggests the semantic web ought to be able to do for us.  To actually get people to expend this effort requires them to have a special interest in it, either at a personal level (as with tagging) or a research interest (as with automatic extraction programs.  I think this effort is a major impediment to more widespread “semantic web” applications and uses.

The natural language question is also a barrier, and a much more usability centred barrier.  Even if we could get evertyhing tagged up, either by human hands or automatically, how people would then ask this semantic web to answer their questions is an open question.  glenn, an acquaintance of mine who works in the field (and like his name spelt wiht a lower case ‘g’) thinks that we need query languages, and I am inclined to agree.  If natural language searching on the free-text internet fails (paywall again, sorry), it will surely fail in any kind of structured environment.  Unfortunately, users are known to do poorly with Boolean search, and it is reasonable to expect that other query languages would porduce similarly bad results, so even if the web was tagged up, it may still be fairly difficult for the average user to ask the question Berners-Lee posed in his book.

I think tagging is great, because it imbues objects with personal meaning, and allows people to find things more easily.  I have yet to see evidence of a truly workable (and by implication usable) semantic web, though, and as such I don’t believe people will be able to answer questions about baseball games at 22C for some time to come. I also believe that even when it is possible to answer these soorts of questions, it will be not because of advanced tagging of web-pages, but more form advanced text processing by search engines–and that isn’t the semantic web, it’s search engine companies prioritising user experience.

Voyage: A road to nowhere

Voyage is a novel feed reader that displays content in a 3D-appearing space, and despite my well-documented reservations about 3D interfaces, I tried to give Voyage a go.  I have to assume that Voyage is not actually a production-level RSS service, but rather a demonstration system, because it is lacking some fundamental features of RSS readers including:

• Personalisation: You can’t create your own account on Voyage, which would mean you had to re-add your feeds every time you visited the site.
• RSS search: Voyage forces you to know the RSS URL of the feed you want to access–not the name of the site or the site URL, but the RSS URL.  This is a big ask of the average user
• Reading: To actually read any interesting RSS feeds you leave Voyage and go to the original site, even in cases where the feed is full-text (rather than an “atom”).
• Pictures: The site does not display pictures. This is a bit of a problem for picture-oriented blogs like I Can Has Cheezburger

Given these limitations, this display feels more like a discovery service for new blogs (along the lines of the liveplasma music and movie discovery service), but it does not have the back-end database of recommendations.  Either way, there are considerable usability problems with this interface:

• The text is not clear and readable
• The 3D-ness of the interface doesn’t add anything (the only dimension that appears to have any meaning at all is the forward and back one), and does make things harder to find (indeed, included in the 23 things task is the “add a feed and try to find it” puzzle).  Given that 3D interfaces perform deomnstrably (PDF) worse in information organisation tasks, and this interface does not have to be 3D, this is a serious usability concern
• The feeds area looks as though you ought to be able to click n the feeds to go to them.  Instead clicking on them deletes them, which given that you need to know the feed URL of a site to add it, is a high cost error for a simple action
• It simply isn’t clear what many of the interface elements (space, colour, the horizontal line) mean, making the interface difficult to learn
• it is difficult to navigate back “out”once you have selected something, meaning that the navigation is difficult and actions cannot be easily undone

Each of these concerns is in contravention of at least one of this excellent list of usability first principles, meaning that basically Voyage is hard to use.  Not only is it difficult to use, but it doesn’t offer either a decent feed reader or an interesting discovery service, so there is nothing in the user experience that is compelling enough to entice users back.  Maybe in a couple of years this concept will be more fully fleshed out, but in the mean time I am going to stick with Google Reader, which does reading and recommendations very well indeed.

Social engineering and usability: a post about toilets.

I’ve been away from this blog for far too long again, I know–sadly I have had things happening at work that have demanded my attention more urgently than this blog.  Now I’m back, and I am going to write a post about something I never thought I would see on this blog: toilets, specifically the dual flush ones.

The first dual flush system was designed in Australia in 1980, and modern ones are estimated to save households up to 67% of their annual water usage–a lot in a country that suffers chronic drought, but favoured by environmentalists everywhere.

Early dual flush system by necessity had to clearly mark which button gave a whole flush, and which a half flush, meaning buttons usually looked something like this:

The images on the buttons clearly dwmonstrate the concept of “full” versus “half”.  It might not be obvious to unfamiliar users exactly what this does, but once explained is likely to be relatively obvious (apparently, too, it is relatively easy to train new users–even children–to use “one button for pee-pee and one for poo-poo“).  The particular model displayed might have a minor design flaw, though.  The half flush button, the one an average user is likely to use most often is on the left as you face the toilet–further from the dominant hand of approixmately 90% of the population.  While this is a tiny inconvenience, it may affect behaviour in some cases, meaning the full flush may be used slightly more. Conversely in much design left is less and right is more–consider the volume knob on your car stereo, or the speedometer on your car, for example, so maybe this left-to-right design has consistency advantages that outweigh the convenience issue–experimentation would be the only way to know which side induced the “best” behaviour.

More recently, though, manufacturers have been moving toward circular designs, presumably in response to the fashion of the day.  Unfortunately, not all these circular designs are clear, as evidenced by the signage in this picture.  This design really does have a design failing; while the designers have kept to the left-half right-full convention, the half flush button (again, the one likely to be used most often) is a smaller target, on the left, and therefore harder to hit.  On the positive side, for at least some of these toilets, hitting both buttons (which is possible in this style of design) triggers the half flush, rather than the full flush (as scientifically tested by an army surgeon).  So again, this toilet may be discouraging “good” behaviour by its design, in the first instance because it is marginally confusing, and in the second because the correct usage of the toilet is discouraged by its design.

Recently, though, I was in a pub and I saw a dual flush toilet that is entirely based on the principle of encouraging “good” behaviour (in this case only using the double flush when you need to).  Because I have not been able to find a picture of this design (and strangely enough, I don’t routinely have a camera with me in the toilet), you can see an approximation of the design at left.  This design is quite clever, in that most of the time it does not require users to understand the concept of the half flush–provided they hit anywhere on the button but the small square, a half flush is what they are getting.  This may be particularly beneficial in a pub, where judgement may be impaired, and the amount of water per flush is probably the last thing on patrons’ minds.  Basically, this design is a clever little piece of social engineering, because unless you really want a full flush (enough to hit the relatively small, off-centre target that is the full flush button), all you get is a half flush.  There is a downside to this, though–it could make life harder for users with fine motor control impairments, for example tremors, Parkinsonism (or even drunkenness, ironically).  The fact that this design relies on the small square being pushed as well as the big circle (as opposed to instead of it) makes this somewhat less problematic, but users having to flush multiple times when they need a full flush (because they have poor aim) may cancel out the general benefit.

This flush design highlights the tension that can sometimes arise between what’s best for the group, and what’s best for the individual in interface design.  As to whether people do have trouble with the full flush, or whether this design really does save water, I don’t know, but it made for interesting thinking on a Friday night at the pub.  What do you think?  Would you put this flush in your house?  Is there anywhere it shouldn’t go?

Boolean search made easy to understand?

Recently a colleague sent me a link to a little tool called ‘Boolify‘. Boolify is a visual representation of Boolean search and is meant to be an educational tool to help people learn how boolean search terms work together.

Boolean logic (and one of its common applications, Boolean search) is a common ground field between computer scientists and librarians, particularly those who try to teach it. Boolean search is hard to understand for most people, but if users could understand it it would be one of the most powerful tools in their search toolbox (particularly when they are using a search term that has more than one meaning). Good search engine interfaces try and get around it by offering a more ‘natural language’ advanced search interface that lets users do some Boolean searching (see for example the Google advanced search interface below), but the true power and flexibility of real Boolean searching is somewhat lost even in these interfaces.

Google’s advanced search interface

Now it’s debatable whether the power users lose in an interface like this is even that much of a problem, given that the vast majority of users enter short queries and don’t use advanced search. Arguably there is a chicken-and-egg problem here; users may not use advanced search because (in many cases) it is too hard, meaning they never learn to use it, meaning it is too hard…Whatever came first, I think the answer is that users can usually (at least with Google) find the information they want (or something close enough) without having to get into Boolean logic, and therefore they don’t learn it.

There are some people, though, for who a good grasp of boolean logic is essential. Computer programmers are in this group, as are the librarians to whom people turn when their own searches fail. Potentially students and researchers should have some understanding of Boolean search as well, though I would generally argue for better search interfaces for these groups. So, given the difficulty of teaching Boolean logic (and having taught first year computer science I have first hand experience of this difficulty), anything that would help make it easier would be great.

At first glance, Boolify looks like just such a tool. It would be more awesome if it had a predefined results pool to play with (as well as providing an internet search), so students could see how query reformulation affects what is included in the results pool, but that is pie in the sky, and this thing looks like a good first step. It has puzzle pieces that show how you can interlock different bits of a boolean search, and the horizontal and the vertical can act like brackets in a real search term–the thing at the top is in the innermost brackets, and so on down.

Sadly, though, the promises Boolify makes are not delivered upon. Despite the puzzle pieces providing every promise of being interlockable, queries can only be developed in a linear fashion, and so the pciture below is what happens when you try to develop the query ((libraries OR museums) NOT gallerys) AND ( user experience OR usability). It simply isn’t possible to do, despite the puzzle pieces having every visual and logical affordance needed–you can on develop queries in a line, which means this tool does not represent the full power of Boolean logic.

Trying to develop a complex Boolean query using Boolify

Usually I would not be so hard on a tool designed to teach something difficult in a novel way, but this tool is a poor teaching aid. It doesn’t allow users to do what it looks like they can do by clicking bits of puzzle in anywhere–thus not showing the true power of Boolean queries, and having a significant usability problem. It also (and I think this is more important) doesn’t let users reformulate queries by moving puzzle pieces around, thus denying a real opportunity to learn how Boolean operators work together by reformulating queries and seeing what happens to the results. I can honestly say that until this tool fulfilled more of its promise, I wouldn’t use it teaching–it is bright and colourful, but it doesn’t bring much more than that to the table.

So, what does everyone else think? Should we leave Boolean logic to the geeks and logicians? Who needs to know Boolean logc, and how should we teach it?