Ignoring the Android Honeycomb Action Bar Convention

I’m working on the UX for an application for the new Android Honeycomb User Interface (UI). This is the first time I’ve designed for this operating system and we were fortunate enough to have Nick Butcher of Google UK take us for a walk through the new environment and introduce us to some of the UI conventions.

If you’ve not yet had the pleasure, you can take a look for yourself here:

There’s a lot to like about the Honeycomb OS in my opinion, especially once you get to know it a little and learn what the many icons that litter the interface actually refer to, however there is one UI convention that really bothers me, and that in this application we are going to largely ignore and that is the action bar.

This is the action bar (screenshot borrowed from TechCrunch who discuss the UI in some detail here)

Honeycomb Action Bar

So, the action bar is application specific and context specific within an application. The idea is that you put any actions you may need in that part of the application into the action bar where you can then ‘take action’, the more contextually relevant the action, the further to the left, the less relevant and more global, the further to the right.

Now, it is A Good Thing that there is a convention for this, especially in an open source environment where designers/developers play fast and loose with the interface and the overall experience of using the device running this platform suffers as a result (as, having played with a Xoom for several days now, I can report is definitely the case).

The implementation, however, I’m less thrilled with, particularly as I’m confident it will actually encourage designers to ignore or duplicate the action bar’s functionality within the interface… and here’s why.

Tablet Activity Zones - Landscape Here’s a ‘heatmap’ of the activity zones for a tablet in landscape mode from a very useful post by Dan Saffer of Kicker Studios.

Note that the red band labeled ‘reach’ (indicating that you have to reach to access this zone and it is not an easy or comfortable activity) corresponds almost exactly with the Action Bar.

Although the TechCrunch article suggests that you instinctively look to the action bar (which, given that it is visually quite pushed back, seems to me to be an easily learned behaviour rather than a natural one), it qualifies this immediately by saying that you do this only if you can’t locate the action in the applications main UI.

This means that, if you follow Honeycomb’s UI conventions (in the hope of making the ecosystem of applications a good user experience with some potential hope of ever rivalling Apple’s iPad), you have three options: make the actions people need to perform ergonomically awkward (the xoom, for example, is no lightweight and unless you’re resting it on a table or your lap, requires some juggling in order to hit an item on the action bar, this juggling also makes the selection significantly less accurate), duplicate the actions in the bar and in the application UI, or ignore the convention and put the actions that are most contextually relevant in a place that falls with in the ‘easy’ activity zones.

I doubt that the designers of Honeycomb intended the action bar to replace in context calls to action, and neither it should, but it seems to me that it means that the actual use of the action bar is now very ambiguous. The more I design for this environment, the more I’m finding that the action bar actually feels much more suitable to application-wide actions rather than contextual – not the least because it is often visually quite removed from the content it is acting on.

This is a significant iteration on the previous Android software and, as our friends at TechCrunch say: ‘…at least people will actually be able to find these options, which is more than can be said about the options hidden behind the ‘Menu’ button on current versions of Android (which many people never hit).’

At the same time it feels like a rather awkward solution to this problem and certainly one that wasn’t really thinking about the mechanics of using a tablet in the wild.

As someone with an existing interest in design and UX for open source, I’d be really interested to hear what other designers who are encountering this convention are making of it. I’d also like to hear about whether the option of placing the action bar nearer to the ‘easy’ activity zones was considered and how that played out.

I’d really like to see Honeycomb evolve, and for good and clear UX conventions to emerge in this space so that we have a really solid alternative to the closed and ever more controlled world of Apple

(disclaimer: I own Apple gear. I know it’s great).

Five User Experience Initiatives for Drupal 8 (A Drupalcon Debrief)

I had the pleasure of spending last week in Chicago at Drupalcon. I was there to run a workshop and do a talk but, to be honest, I was also mostly there to decide whether it was time to break up with Drupal for good.

My relationship with Drupal is now heading towards the 3 year mark. The number of hours that I’ve contributed (unpaid, in addition to those I’ve been fortunate to be paid to contribute) are really starting to rack up. I was starting to question whether those hours were well invested and whether it was wise to invest any more. Whether in fact it was possible that my contributions might actually constructively lead toward significant improvement or whether, after all, trying to do good UX in open source is really just thrashing.

Well. We didn’t break up. It’s not all roses, but there’s hope.

The first sign of hope came in Dries‘ keynote where he identified not just usability but delightful experience as a goal for Drupal8. Frankly, I’ll be beyond surprised if Drupal8 gets anywhere close to ‘delightful’ by the release of version 8 but as long as we’re tracking in that direction, I’m pleased.

The second sign also came from Dries’ keynote where he started talking of initiatives and distributing leadership throughout the community. I think this a great idea and gives not only UX but other disciplines the opportunity to really stand up and take a key role in the community. I noticed, however, that Dries didn’t mention any specific UX initiatives, so I thought I’d share five that I think Drupal should embrace in the coming months and years.

1. increase the overall UX/Design competency within the Drupal community – help developers (who always make loads of design decisions, in Drupal-land and beyond) make good design decisions.

What does this involve?

– Making and publicising a good pattern library so that developers contributing user facing code can help us maintain consistency and enhance usability.

– Continuing to make the case for good usability through sharing ongoing usability testing and showing how, where and why users struggle to complete tasks

– Increasing the size of the usability team in the Drupal community – here we need to focus on lowering our pretty atrocious attrition rate – keeping the good people we attract rather than just attracting more people only to see them give up and leave, exasperated, in short order.

– Creating an environment that supports and encourages good design practice. More on this below.

2. Incrementally improve known usability problems from Drupal 7 in Drupal 8. Refocus on the Site Builder persona.

There are lots of known usability problems remaining in Drupal7 that it would be great to see nailed in Drupal8. In particular, a lot of the site building tools were not given as much attention as they deserve because of Drupal7’s focus on Content Creator.

At the Usability BoF in Chicago the team discussed refocussing Drupal8’s UX goals on the tasks of the Site Builder and therefore on improving the interfaces that are encountered during the core site building tasks. Regular usability testing on these tasks will also be undertaken during this cycle.

3. Improve Drupal’s ‘Out of the Box’ experience

The learning curve of death cannot continue. We can’t expect newcomers to sign over their first born child before we let them set up a simple website. We need to give them something quickly. Enter the Snowman (nee Tsunami) (see also @eaton’s initial proposal for this project).

4. Improve the experience for Content Creators

Refocussing the UX efforts for Drupal8 on the site builder leaves our Content Creators in an awkward, somewhat unloved position. The challenge remains to find a way to enable the people who run our Drupal websites day to day (and the people who can be incredibly influential in deciding whether or not Drupal is the chosen infrastructure or not) to have a good user experience.

There are several efforts in progress addressing this challenge including Project Verity (the not-drowning-tho’-equally-not-quite-waving project that I’ve been working on with the team at Mark Boulton Design), Workbench (recently released by the guys at Palantir) and no doubt many others that I’m not aware of (yet!)

It seems at this point that the fate of the content creator is in the hands of contrib not core. If you’re looking for an opportunity to really contribute to the future growth of Drupal consider this a worthy cause.

5. Make Drupal.org a better environment for creating good user experience

Nobody I’ve ever met who works on the Drupal project actively wants to create a crappy UX, but our tools don’t necessarily make it particularly easy for us to do so. Drupal.org needs better collaboration tools that encourage us to follow good process (eg. to explore the problem space and possible ideas before we start coding the first one we think of), to get the right people in the room for discussions at the right time (smart but not annoying notifications), to help drive productive, efficient, consensus focussed discussions, and to help ensure we’re all pulling together, not frittering our energy away on related projects that don’t know about each other.

This is the goal of the initiative that Randy Fay & I kicked off in our Core Conversation at Drupalcon, it’s called the Prairie Initiative (also see Randy’s and my slides on this topic aka ‘Redesigning The Issue Queue’ ).

This is where I want to spend the bulk of my ‘Drupally’ time over the coming months (albeit only a few hours a week – I’ve got work, kids, side projects, a mortgage to pay – don’t we all).  I’ve got some unfinished business on the Drupal.org redesign project anyways, the issue queue is my itch to scratch (I’ve moaned about it enough) and getting this right (or at least, a little righter) seems like a fascinating and challenging project to me. Also, I get to work with some of the Drupal community’s finest. Expect to hear more on this in the coming months.

There they are – the five UX initiatives I’d like to see for Drupal 8. I’m not sure how things become official initiatives in our new Drupal 8 landscape but I imagine that if a whole bunch of us keep saying it over and over, form into working groups and start getting exciting stuff done, that’s got to be a good start. If a delightful experience is really what we want to achieve then, IMHO, this is how we get started.


A model for design leadership in the Drupal community


The discussions around the design and user experience objectives for Drupal 8 begin to kick off and will no doubt crank up a gear at the upcoming Drupalcon.  (are you coming? come to my workshop! no ux/design experience necessary)

As much as I want to see us continue the great trajectory for improving the user experience for Drupal that I think the community achieved with Drupal 7, I have some reservations about our capacity to maintain this momentum without addressing some of the structural issues within the community – effectively the environment in which design can happen.

There are bunch of topics that we can explore around this – I’ve pitched a Core Conversation for Drupalcon about redesigning the issue queue, for example. I hope I get to talk a whole lot more that during the coming months. Today I want to talk about a structure of leadership for design in the community and to propose a model.

One of the main reasons that we were able to achieve so much with Drupal 7 was because the D7UX team (which I was privileged to be a part of) were given a mandate, a bit of authority, and a clear brief. If we want to continue to take big steps with Drupal’s user experience (and we still need to take several big steps on this front if we want to be competitive and remain a viable option for a wide audience), we need to find a way to replicate this focus in the longer term.

Currently we have two UX Maintainers – Roy and Bojhan – who are both incredibly dedicated and do great work within the community to promote a better user experience. I have nothing but the greatest admiration for their resilience. There are also, increasingly and largely thanks to Acquia,  more UX and usability resources available within the community.

We have the dual challenge of encouraging existing community members to become more ‘UX-y’ and attracting UX Outsiders into the community in order to grow this team. We also have the dual challenge of making many, many incremental changes that could rapidly improve Drupal’s usability (we call these the ‘low hanging fruit’), as well as considering the bigger, more hairy challenges around defining and understanding target audiences, and finding ways to create good experiences for an incredibly wide set of journeys and requirements.

Eaton recently took a good stab at describing some of the big UX challenges ahead for Drupal 8 and offering a good proposed approach – I recommend reading through this, including the comments, if you haven’t already.

In order to make it possible for such changes to happen, I propose that the Drupal UX Community requires three types of leadership: A UX Maintainer (or two), a Design Pattern Library Maintainer and a Designer in Residence. Let me describe these in reverse order.

The Designer in Residence: This person is tasked with addressing some of the Big Design Problems – the more strategic/structural problems that will impact Drupal’s long term ability to be a compelling choice for organisations in the coming years, that will look at the challenges of multiple platforms from a UX perspective, that will look at target audiences and optimising out of the box experiences/on boarding. This role will benefit from having an ‘outsider’ perspective. This person works with the UX Maintainer(s) to take great strategy and turn them into achievable tasks. This person shares their work with the Drupal community and the UX Community at large, along the lines of what we did with D7UX. They are Drupal’s UX ambassadors to the outside world, they help draw fresh UX talent into the community. They conduct generative research. This is a role that could be rotated every six months or so, getting fresh eyes on the big problems would be fantastic. We could invite people we’d love to work with to take this role from time to time.

Design Pattern Library Maintainer (or librarian, if you prefer): this person leads and coordinates a project to develop an excellent library of design/UX patterns that can be applied consistently throughout core and into contrib. They work with the UX Maintainer(s) to ensure that new patterns are applied/communicated and they take requests from the UX Maintainers to develop patterns that are missing or confused. They might conduct A/B testing to establish optimal patterns. They take work from the Designer in Residence and turn them into patterns as a part of the process of making big design ideas achievable.

UX Maintainer(s): work with the overall community to get the day to day UX work done. Help push things through the queue, coordinate and communicate usability testing, incrementally improve the UX of Drupal by knocking over the ‘low hanging fruit’ improvements, help educate and train up members of the community to be more UX-interested and UX-aware. Works with the Pattern Librarian to see that patterns are implemented well across core and contrib, works with the Designer in Residence to make Big Ideas achievable.

I believe that each of these roles should have clearly identified goals for a defined term (say, six months?) so that they can see and show what success looks like and be able to get useful feedback on the work they’re doing.

I also believe that these roles should be funded positions. I believe that one of the best ways an organisation can support good User Experience in Drupal is to put their hand up to offer sponsorship for a part time role for six months.

If we do this – get the structure in place for good design to happen, and create funded positions to make working on Drupal a viable alternative for good UX people who have so many other competing demands on their time at the moment – I am very excited about the prospects of Drupal’s User Experience in the years ahead.

Something significant needs to happen in the way we do Design and UX in Drupal – along the lines of D7UX but more embedded and integrated and more sustainable. We won’t achieve what we need to by making lists and prioritising them. We’ve still got a lot of big problems to solve and a lot of hard graft to do.

What do you think – might this help make it happen?

10 tips for UX Freelancing

Every now and then I’m asked for advice on getting started as a UX Freelancer. I tend to say the same thing most times, so I thought I’d put them together here for future reference and for the benefit of anyone else who’s thinking about making the jump (or who has made the jump and wonders whether we see the world the same way….)

I offer no guarantees about any of these tips, all I can say is that they have worked for me and that they form the basis of my ongoing approach to UX Freelancing. Some of these I’ve known since the beginning, some I’ve learned, most often the hard way.

In presenting these tips I am speaking particularly to those people who think of freelancing as I do – working for multiple clients on multiple projects (not always at the same time) in the course of a year, not taking a series of long term full time contracts.

If you are also a freelancer and would like to offer additional or alternative advice please do feel free to add your comment below.

1. Why are you doing this?

Why are you choosing to freelance? Is it for a better balance between work and the rest of your life? For riches and fame? To have more control over the work you do? There are lots of reasons why people choose to freelance (some of the more or less based in reality!). Think about why you’re doing this and then think about what decisions you’re going to need to make in order to achieve this outcome.

It is crazy how many people start out freelancing imagining spending Tuesday afternoons in the local cafe reading – because they can. Then end up working more hours than they’ve ever worked in their life and never going anywhere near a cafe or a book.

What are your ‘project goals’ for becoming a freelancer? Make some ‘golden rules’ that will ensure you can achieve these goals. You’re in control now, so be proactive about it and make life/work what you want it to be.

2. Finding work: Build a good network, do good work

The best way to get good work is to make friends with other UX Freelancers who are good, get busy, and want to find a good home for work they can’t do.

Actually, I don’t get much work this way personally, but I pass on quite a bit and see several other good UX Freelancers doing similar.

The *really* best way to get good work is to do good work, and to have other people talk about your good work to others who may wish to hire you. I think this is how I’ve gotten most of my work over the years and I hope it continues this way.

(You may have noticed that I do not recommend contacting recruiters, not even for ‘safety’ for your first job. All evidence I have seen indicates that you are unlikely to get good/interesting UX work as a freelancer from recruiters and you are more likely to be paid less than you’re worth.

Although, I have also heard evidence that recruiters over charge for UXers, this has only ever come from someone looking to hire, not be hired. If the only way you can get work to start your freelancing career is through recruiters I’d be tempted to re-think freelancing altogether).

3.  Be visible.

Being a secret freelancer is not a good strategy. There are several different ways you can be visible, choose the one or more you find most comfortable. Options include but are not limited to: write a blog, be active on Twitter, speak at conferences & other UX events (large and small), attend events and talk to people, contribute answers on UX related email lists, forums, Quora etc.

When being visible, the best way to do so is to contribute to the body of knowledge of your UX community. We don’t really want to hear how fabulous you are (I’d rather hear that from your previous clients or colleagues). We would like to know what you’ve seen that’s interesting lately, why it’s interesting, what you learned from a project etc.

You don’t need to be a massive self-promoter. I’d advise against blatant, unhelpful, self promoting, but being visible (particularly being digitally visible, Google-able with positive and relevant search results ensuing) is important.

I find that by sharing my work, my process and my learnings (as much as I’m commercially able to) I negate the need for preparing and maintaining a CV or shiny portfolio. Your mileage may vary.

4. Position yourself.

If I know what kind of projects you really like (and are really good at doing) and I hear of a project like it, I will think of you immediately. Apply the same approach to positioning yourself as you would to your projects.

Don’t try to be everything to everyone, think about the kind of work you’d rather do and let people know that’s what you want. You might end up doing all kinds of different things, but you’ll become a go-to person for your particular niche, and that way, stay top of mind.

5. Don’t take work you don’t really want to do.

It is really hard to say no to work when you’re freelancing. Really hard. It takes a while to believe that work will actually come to you when this project is over and that you will be able to pay your rent/mortgage etc. Don’t panic and take a project you really don’t want to do. There are two reasons for this:

Firstly: It’s really hard to do good work on a project you don’t care about. The quality of your work is critical to your future success as a freelancer. You can’t afford to do a bad job (not if you can possibly avoid it).

Secondly: It is a little known fact that the universe conspires against freelancers who ignore this tip. Just as you’ve become contractually obligated to work on the most boring, tedious project ever for weeks into the future, you will be offered the Project Of Your Dreams. And you’ll have to turn it down (or, at least, you should – skiving out on projects at the last moment or worse, when you’ve just started, because you’ve got a better offer is pretty bad form). I can’t begin to tell you how awful this feels.

6. Don’t overcommit.

See above re: it’s hard to say no to work. Also, projects always take longer than you think they’re going to. This can lead to working every hour god gives you. This is not good.

It is not sustainable to work ridiculous hours indefinitely. You will probably have to do it sometimes, don’t make it a way of life. Your mental health, family/social life and the quality  of your work will all suffer. Even if you say ‘screw my mental health and family’, the quality of your work is the indicator of both the volume and interestingness of your future work. Don’t do anything to jeopardise that. (Like, say, working at 3am on a Saturday morning when you’ve already clocked 80hrs or more that week).

Try to over estimate the time you’re going to need to do a project (then you may just get it done in time) and do allow yourself some downtime to remain sane and relatively fresh.

7. Don’t over complicate the legal/financial aspects.

When you’re starting out (in the UK at least) all you need to do is register as self employed. You don’t need to register for VAT immediately (although it does feel weird charging no VAT and clients do ask questions), you don’t need an accountant or a limited company immediately. Take it easy and scale things up as you need to.

Do make sure that you are tracking your time and your invoices properly. There are millions of options for this. I have used FreeAgent since I started out because it allows me to do estimates, invoices, time tracking, maintain a client list, and automates a lot of my tax and it comes with a pretty delicious user experience. It’s not the cheapest option but it has worked well for me (and now that I have an accountant, they can log in via an ‘accountant login’ and get everything they need automatically). Paired with an iPhone app called Out Of Pocket which integrates to FreeAgent and lets me capture my expenses on the fly, I’m  much better at my accounts than I ever thought possible. Accounts are almost fun.

Except for the tax-paying bit. (On that note, don’t spend your taxes, or you’ll find tax time rather painful. (Speaking from experience here)).

Get Professional Indemnity insurance. Hopefully you’ll never need it. Some clients will require it.

Don’t stress out about contracts, stress out more about choosing the right clients and managing their expectations by communicating well throughout the project. You *really* don’t want to get down to enforcing a contract and in most cases, the cost involved in pursuing things legally outweighs any financial benefit.

I probably shouldn’t admit this but the only time I tend to sign a contract with a client is if they have one they want signed. Most projects I do without a contract. I work hard to make sure my client understands how we’re going to work together and what they’re going to get – almost invariably this changes as we get to know each other and our project better.

If things start feeling dodgy, in any way – stop working and start talking. Invoice regularly, make sure you are going to be paid. If you don’t think a client is going to come good with the cash, ask for a payment upfront (again, this is something I do rarely tho’ I know it is standard for others), and put them on short payment terms. Or better still, don’t work with them. Writing off invoices is very depressing.

Be aware when invoices are overdue and don’t be shy about chasing them up with a friendly but timely email.

In my experience, if you choose good clients, you don’t need to worry too much about getting paid.

8. Value yourself appropriately.

When analysing the recent UX Freelancers Rate Report data, the thing that most struck me was how apparently random our dayrates are.

A lot of really good people are charging a lot less than they should and a few are apparently charging more than they’re probably worth. Now we have some idea of what we’re all charging – be informed and charge yourself out appropriately.

Once you’ve set your rate, keep track of how many people simply accept it and how many wince and complain at the rate. (Exclude recruiters from these calculations). If more than 1 in 4 wince, you may need to lower your rate a little. If fewer than 1 in 4 wince, you may need to put your rate up.

9. Don’t do freelance work and look after small children simultaneously.

See above re: overcommitting. I’ve tried it. It’s horrible for everyone involved (you, your client, your kids). Get childcare (and curse that it’s not a deductable expense).

10. Take the lead.

When I think about the (thankfully only occasional) projects I’ve worked on that didn’t go as well as I’d like them to, it was almost invariably because I was looking to my client to take the lead, to tell me what they wanted to do, and then for me to act on instructions. In every case, whether the client *thinks* they know what they want or if they haven’t a clue, you should be proactive in setting out the process or project approach that you think will give the best outcomes and make the best use of resources.

Your client is almost always paying a premium for your services as a freelancer – this may be because they’re desperate and this is the only way they can get the UX work done, but hopefully it is because they are looking to you to bring some specialist skills to their team. Give them their money’s worth and make the most of your time with them by being proactive and helping them use you well.

So, that’s it. Almost everything I’ve learned about UX freelancing that I can remember today. Let me know how much of this resonates with you or not, what I’ve missed (I know there’s lots!)