Women in tech, inclusive design, and the lesson Apple learned today

Women are clearly a minority in tech fields, both in education and in the workforce.  There are a number of reasons why this might be the case, including cultural attitudes, lack of mentorship and outright hostility to women in tech. This post isn’t about the cause of having so few women in tech, though–it’s about the results. People tend to design for themselves, particularly in tech–and this is perfectly expected, but it does mean that with the paucity of women in tech fields, the design work in tech is not often done with women in mind. Testing on people not-like-designers who use or might use the thing you design is pretty much the core of usability.  Given that women do purchase and use technology, if possible it’s worth including some of us in any design team and it’s always worth including them in the testing phase of any product they might use, because they might just see it differently (this principle also applies to products that might be used by children or the elderly or anyone who is a target market for any product, particularly where they are not represented on the design team).  Back to women, though: today Apple has learned about including woment he hard way.

Today Apple announced their much awaited new toy.  As many people predicted, it is a tablet, and they have called it the iPad.  The name has problems, including the phonemic similarity to iPod which one of my workmates pointed out, but more embarrassingly for Apple the connotations that immediately led to not Apple, nor iPad, but iTampon being a trending topic on Twitter and some pretty vicious skwereing on sites like adfreak

This isn’t the first time Apple has forgotten women in it’s design process, I’ve already blogged about the direction of the clip on the iPod shuffle. Despite the free publicity, though, this is the one they might learn from–being ridiculed all over the internet probably wasn’t what they hoped for with this announcement. Apple may well have had women in their design process (there is a strange kind of groupthink that goes on on team-based design where people miss things that would bee seen by anyone outside the team), but they clearly didn’t test on a diversity of women.

The name of this product shows it wasn’t designed with me in mind, and makes me a little less likely to buy it as a result–this design, like the clip on the shuffle isn’t inclusive.  Obviously not enough people complained about the shuffle, and Apple didn’t understand the need to include women in design and testing.  I bet they will next time, though, and I hope other companies have seen Apple’s mistake and learned something too.

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.

Password masking, and the difference between usability and user experience

Recently Jakob Nielsen recommended removing the little black dots that come up when you type in a password, and having your password come up in clear text instead.  He had some pretty good reasons for recommending this including:

• Increased password security
• Mobile usability
• Error prevention

However, Nielsen also recognises that there are some situations and some passwords (for example banking passwords) where the security outweighs usability. You can read more in his article about the matter here.

Responses to his idea ran the gamut from wholehearted agreement (by a security expert no less)  through tentative disagreement to pretty strong disagreement.

There has been some comment on the sociotechnical aspects of password masking, including using masking as a reminder to users that they ought to keep their passwords secure, and a discussion about the reasons why many people are uncomfortable with masking.

Other responses suggested solutions to the problem, including displaying only the most recently typed character (like on the iPhone), and giving the user the option to unmask (rather than mask) a password.

I completely understand the usability reasons for unmasking passwords, and I agree with what Jakob Nielsen is saying, up to a point.  My preferred option, out of all the ones suggested though, is the last option, where a user can choose to unmask a password, and my reasons for this are a common context of password use, which I will illustrate with an example:

I’ve just finished a large group project to launch a new library catalogue; we did a lot of collaborative work, and spent a lot of time using computers that projected onto a large screen.  We frequently read email to remember discussions we’d had about the system, manage links, manage to-do lists and generally remind us what was going on (this is a really common way–PDF of storing “stuff” in one’s headspace), and the system had components we had to log into.  We were logging into and out of systems left and right, and always on a big screen. I work at an institution with a single sign-on–this means your password for the HR system where you manage your payroll and salary, your library password, your email password–they’re all the same thing (bear in mind, single sign-on is good for security, users are less likely to use bad passwords if they only have to remember a few of them). Even more frequently than we had these meetings, two or more of us would be clustered around a desk testing some aspect of the new library system that required a log in or out.

I can’t imagne that either of these scenarios is uncommon in the workplace, meaning that in Nielsen’s world users would all share their passwords.  Similarly, I imgaine it is fairly common in social contexts, particularly with shared hosues and computers. Sharing passwords is undesirable at best, and I don’t need to describe how much damage one bad apple in a workplace could do under such circumstances–and it would be extremely difficult to track down who that person was, and what they had done when a large group of individuals all knew each others’ passwords.  Not only that, with single sign on passwords provide access to confeidential and sensitive information, including (at my institition) email, leave details, salary details and library details.

Just like with Nielsen’s solution, having characters disappear one character at a time essentially clear-texts your password to anyone who happens to be present, leaving the only options to balance security and usability as the check-box options.  Nielsen suggests that the checkbox be “hide”, but I disagree.  The social implications of a “hide” box are that you have to make the decision to hide your password from your colleagues or loved ones or friends in front of them, which sets up the potential for interesting dynamics around trust in professional and personal social interactions.  My preference would be an “unhide” box that implies it is simply natural to keep one’s password hidden–thereby avoiding any issues of trust in situations where otherwhise passwords might be shared.

The problem with Nielsen’s approach is that it is a purist usability approach.  If all we cared about was making systems more usable, absolutely it would be right to expose everyone’s pasword, and have the option to hide it occassionally as necessary.  This could lead to extremely uncomfortable social situations in both the work and personal spheres, though and as such is poor design of user experience, which takes the context of use into account–and I can’t recommend something that would so frequently lead to bad user experience.

So, what do you think?  Should we all show each other our passwords?

Help text: What it isn’t for

My life has been interesting lately: We’re implementing a new library catalogue which also means re-implementing most of the library web-site.  This has meant the need, in some cases, for new help text, and while I am not a technical writer, I have done some technical writing in the past, so I got the job (that, and I put my hand up for it since everyone is busy).

In preparation for writing the help text I needed to write, I reviewed a lot of other help text, and I found a pretty common mistake: Using help text to fix up  problems with an interface.

One of the help texts I reviewed was for the search history component of a search service.  This service automatically kept all the recent searches, and allowed users to save searches more permanently, and file these saved searches away in different folders for later recall.

The help text for this service explained to users what ‘this session’s queries’ and ’saved queries’ were, and identified the non-standard icons used for moving searches between folders. Help text in this case is a band-aid for the mistakes made in system design: the word ’searches’ should have been used in place of the word queries, and if the folder system could not be made drag-and-drop, the icons should probably have been replaced by words (or at least standard icons).  This would have dramatically cut down the need for help text, and more importantly (given that only a tiny minority of users read help text), improve the general usability of this feature.

Whiel the feature described above was a pretty clear example of using help text the wrong way, it was far from the only example I could draw on, and this is fairly disappointing. Help text is for systems that are genuinely complex, not for putting a band-aid over poor user interface design.  When was the last time you had to read the manual to do something simple?

Usability means sustainability: a note on world usability day

Today is world usability day, and the theme this year is sustainability.  I can undertsand if that might seem like a bizarre combination, or if it might appear that world usability day has jumped on some kind of bandwagon.  I don’t think the two are wildly unrelated, and I think it is timely that world usability day recognises the relationship.  The relationship comes into play in a number of ways, from better designed living spaces and cities down to feedback to technology users about their real impact, but today I want to focus on two issues: efficiency, and computer supported co-operative work.

Efficiency is, in my opinion, a really big way better usability can contribute to improved sustainability.  Consider that Ben Shneiderman found out 8 years ago that the average person spends 5.1 hours per week grappling with computer problems.  If even 25% of those people would otherwise spend those 5.1 hours doing something that didn’t require electricity, that is a huge environmental saving.  Consider also the case of Lufthansa flight 2904 where cockpit usability problems constributed the death of two people, and the scrapping of an aircraft or the Therac 25 usability problems which caused the death of two people and necessitated considerable medical treatment for two others; both of these cases highlight social, financial and environmental sustainability problems that might have been avoided with better usability.  More mundanely, consider workplace injuries caused by poor ergonomic design, or the tim you spend looking up help files: each of these is a loss in efficiency due to poor system design and lack of usability testing. Every loss in efficiency we suffer due to poor system design or technological troubles is a way that usability (measuring how real people interact wit that system)  might have produced a more sustainable product or system.

Computer Supported Co-operative Work is another area for significant growth in sustainability.  This research field has a rich hsitory of contributing to the ways in which we work, and promotes some real sustainability gains.  CSCW has been the genesis of ideas that allow us to travel less (because we can collaborate online–there are some things for which you have to be there in person, but meetins are no longer one of them), print less (because we can share and review documents online) and share ideas more readily (because electronic dissemination is so lightweight). In their own ways, each of these advantages of sharing an electronic workspace contributes to sustainability (particularly given that travel and paper are not incosiderable contributors to environmental problems) , and I have no doubt that CSCW will continue to provide stepping stones to sustanability gains in the future.

I could talk about any number of other ways that usability helps create a more sustainable world, but I need to get off this computer and go and do something requiring no electricity.  In the meantime, I thoroughly recommend this post on ways you can check the usability of behaving sustanably in your area.  What are the barriers you face in living sustainably that could be improved with better system design?

New user experience person working in (digital) libraries

A couple of days ago I found another person who is doing work pretty similar to me, only she blogs about her practical work a lot more than I do.  Lorraine is posting a series of usability analyses on digital library sites and software, and her insights are very interesting.  You can read her blog at lorrainepaterson.wordpress.com, and you can follow her on Twitter (lorraine_p).  I’ve also added her to my blogroll.

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.

Connex: a great example of systemic failure to care

Tell me, if you wanted your automated train ticket machines cleared, would you choose 823 AM on Monday as a good time to do it?  Even if ticket clearing takes 13 minutes? Even if, during those 13 minutes, four trains stop that station according to your schedule, and in fact 6 actually stop because two are running late?  Even if it was a station where not many trains stop, because it is not a primary station? Even if there is no other way for your passengers to buy tickets, unless they have enough coins (tickets start at $3.70)? Even if you regularly ended up with 10+ people waiting behind you?

No, neither would I, and yet between them, this is what Connex and Armorguard think is a good idea.  There is actually plenty of scope to clear the ticket machines at that station where not one single train stops there, even during weekdays.  I’ve written about Connex before because of their poor approach to user experience, and while they have often given me cause to do it again, I didn’t want this to be the “I hate Connex” blog, so I’ve left it alone. This particular example, though, was a  perfect demonstration of how little Connex cares about its’ customers’ user experience, particularly when you factor in the Connex guards who were present to prevent the “fare evasion” not being physically able to buy a ticket during peak hour might normally cause.

It comes as no surprise that Connex have lost their contract for the Melbourne metro train system, and while it is likely true that the State government needs to come to the party if services are genuinely to be improved, I won’t miss the callous disregard Connex shows for its customers, nor their pre-recorded message apologising “for any inconvenience caused”. There are things the new operator can do, even without government support, that will show that they are interested in their users’ experience of their system, and this more than anything will make a difference to that experience.

Apologising: Google is doing it right

As some of you will know, gmail went down for 100 minutes early thismorning.  I did notice it, but assumed it was my internet connection acting weird again–and I didn’t really need to read email at 7AM anyway.  For people elsewhere, however (for example in the US where this was anything from midday to close of business) and even people in New Zealand where the workday was just beginning this could have been a real problem, especially for those using gmail for business porposes.

Given how reliable Google usually is, this sudden and lengthy failure will understandably shake confidence in the service, and may even make people more righteously angry than service failures by unreliable companies (consider my eyerolling acceptance above, when I thought the problem was my ISP).

Generally speaking, users can think one of three ways when things go wrong (and lets face it, things do go wrong sometimes with any product or service):

• That the product or service is unreliable and therefore they have lost faith in the product or service and the parent company
• That something went wrong, but that the company did what they could about it and the solution was acceptable so they will continue to use the product or service
• That the resolution to the problem was not satisfactory, but that they have no option but to use the company next time anyway (for example when the company has a monopoly–if this is the case though, as soon as the company no longer has a monoply they can expect customers to jump ship).

Google probably has a lot of people in the second category after today, because they did two things right: They updated people, and they wrote a fabulous and public apology.  The apology was probably even more effective than one normally would be because a large company apologised for an outage in a free service, but there are a few other things Google did right:

• They apologised unreservedly, and with an understanding of their users.  There was no “we’re really sorry but it wasn’t our fault” or “we’re really sorry but you shouldn’t be so mad”–they understood why people might be annoyed, and they said sorry.
• They explained the cause of the problem.  Not everyone is going to care about this, but it is good practice to explain for those who do, when writing for a public audience
• They described what they are doing to make sure it doesn’t happen again.
• They subtly reminded users why they chose gmail in the first place, not by saying “we are the most reliable”, but “we’re trying to keep failures rare”.
• The apology was public (right up there on Google’s gmail blog), but not forced on those who didn’t notice the failure.

This is probably the work of Google’s PR people, but dealing with the failures that inevitably happen in life is a really important part of good user experience, and (I swear I don’t work for Google) this is one that Google have done really well.

How to deal with ‘too much information’: where should we put search refinement facets?

Swinburne Library is in the process of making some changes; we’re replacing our library system with a fancy new one, and as the user-experience-person-in-situ it is up to me to make suggestions for the search and discovery interface our users will see.  Some of those decisions I will blog about here, and search facet placement is one of them.

Search facets are one of the search tools that I think will be most instrumental in making stuff easier to find (and the OCLC report (PDF) on user expectations vs. librarian expectations suggests library users feel the same way). Facets are the little categories you see on search interfaces that let you narrow down your search results to things that are more relevant to you; they started out in tools with well-defined metadata (like eBay and Amazon, and even some of the newer library systems) and they are slowly working their way into searches with less-well-defined metadata, like Google.

With anything new like this, though, you have to figure out where in the search interface to put it.  So far I have seen facets placed to the left of search results:

to the right of search results:

and below search results:

At Swinburne, we talked a bit about facet placement, and in all likelihood ours will be on the left.

So, what are the arguments for and against each position?

• Facets below search results: When facets are below search results, they don’t distract the user when they are viewing search results, which is a good thing.  However, given that the vast majority of users don’t scroll all the way down, and only look at the first couple of pages of search results (and they look more at the first results on these pages), placing facets below search result is pretty likely to mean that users don’t see them or use them.  This likelihood is reinforced by the fact that this is a significantly uncommon location for facets, so users won’t think to look for them here.
• Facets to the right of search results: From a user-centred-design purist standpoint, in my opinion the right-hand position for facets is probably the best in an interface where the language is read from left to right.  This position means that user see search result first, and then facets if the search results don’t contain anything immediately useful.  Given the number of commonly used interfaces that put facets on the left, however, this could be a risky proposal.
• Facets to the left of search results: This is what Google have gone with (possibly because their advertising is on the right).  It is also common in other commonly-used information seeking interfaces, such as eBay, Dymocks (in Australia) and Amazon (for the US and the UK). Use of these interfaces will train users to look to the left for facets; and it would seem that at least a small sample of users have already developed this preference for left-hand search facets.

Swinburne has a real opportunity with this project to provide a search interface for our users that is not “slow motion search, typical library“; however, to do this we must pay as much attention as we can to our users.  Putting the search facets to the left is just one of the decisions we will make with the users in mind, and I hope to blog about more in the future.