One of my friends shared this on Facebook yesterday. A genial middle-aged man in a dress shirt and slacks seems to be giving a standard product demonstration of a drum keyboard, but somehow it becomes this crazy drum solo, before ending as a standard presentation again. I probably find it particularly amusing because it starts with the stereotypical boring conservative Singaporean but gives you a glimpse of the underlying lightheartedness that I like to think runs through many of my countrymen.
This “Asian equipment demonstrator” is a Singaporean (probably) who is showcasing a product from Creative Technology, a Singaporean company that in the 90s made the Sound Blaster sound cards that pretty much had a monopoly on the PC market. They also had a line of MP3 players which were very feature-rich, and hold the patent for the invention of a user interface for portable media players. I owned one and was a big fan, happily filling it with anime soundtracks and Canadian pop-rock-punk. The media players, like everything else, died as the iPod ascended, something I watched with sadness while realizing that technical superiority was not enough: you had to make people feel good about your product.
I’m suddenly realizing this is probably the true origin of my interest in product design and usability. I actually got asked something similar the other day – which stumped me, I mean, I’m just…it’s interesting? I’ve always liked it? I’ve always been an artist something something something? Eventually I dashed off something lame about getting frustrated having to use US-centric resources as a non-US person. (“Enter your five-digit zipcode to view this information” – god! I still get riled up.)
When I was eight-ish I read Creative cofounder Sim Wong Hoo’s autobiography, which described No U-turn Syndrome and a lot of other stuff I didn’t fully understand. I am only now suddenly remembering that he had a chapter about taking computing exams in school and leaving answers dramatically unfinished to impress the grader with his integrity at stopping precisely when “pens down” was announced by the proctor. I know I definitely copied that behavior during later exams.
It’s funny I remember the book so vividly. It had spiral binding, “hyperlinks” by means of page number, and an awfully designed cover.
Web designers must consider accessibility and other user experience issues in their drag-and-drop implementations. This post offers some issues and solutions.
Merry Christmas from sunny Singapore! Started this post a while ago, wrote the bulk yesterday, might as well add a few more sentences and publish it on Christmas. Also, sorry, bad title puns again.
Drag-and-drop is a cute extension of the physical paradigm that works particularly well on touch devices for obvious reasons. It’s naturally suited to tasks where user-defined sorting of some kind is required. It’s also a great way to show off and engage users by creating something fun to play with: anyone who has ever interacted with a draggable element has pulled it randomly around the screen while savoring that rare sense of control over the interface, no matter how superficial. I’m fond of it, especially for the analogue sense it brings to digital interactions.
Problems arise when this control method is applied indiscriminately to content of all sizes and types, without regard for screen size, page length or consistency. Users get tired when drag-and-drop is unwieldy, has to traverse large distances, or if intermediate/drop behavior isn’t consistent with expectations set by other sites and applications. As an example, let’s look at LinkedIn, the website that reminded me to write this post today – although LinkedIn is by no means the sole offender.
Aside: I appreciate that LinkedIn is constantly experimenting with their interface – it’s very nice to see that they’re continually striving for improvement.
They’ve made a big change to their Edit Profile page recently – or maybe I was subject to a variation in an A/B test, we’ll never know. But to reorder entries on the profile I now drag and drop chunks of employment history etc. around. (But only positions I currently hold can be moved – another frustration that took a while to understand.)
I can be verbose in written communication, use bulleted lists, and have a lot of media on entries like those for illustration or design. These mean that the height of the draggable element becomes far too unwieldy for effective manipulation. Below is a screenshot of a reordering attempt. The element is too large to easily move, and it’s made worse by frustrating intermediate behavior that makes it hard to do what I want even if I manage to move the element.
This particular drag-and-drop implementation also doesn’t allow me to just move the element roughly to where the target destination is – a behavior I expect since the only possible action is a crude swap and no finer control is needed. Instead, I have to align the top of the element with the top or bottom of the target to bump the target into the spot where my original element was.
What if I want to move the element to a target spot far away on the page, beyond my screen boundaries? Now the user is forced to perform an awkward shuffle that involves
bumping the element against the edges of the screen to force scrolling (slow, and finding that exact spot is an exercise in precision pointer manoeuvring)
holding the element down while scrolling with a wheel, keys or another finger, and hoping that the element follows along or at least reappears when the cursor is moved (which doesn’t always happen, forcing the user to try method 1 again)
If my finger slips – possible for users with poor motor control – or if I get to my destination and the draggable element has been lost somehow, I have to perform the dance all over again.
Let’s have a quick video example of said dance, this time on the website I first ran into the issue on, WordPress. WordPress has used drag-and-drop in their widgets page for quite a long time – you drag options from a pool of available widgets to an “active” zone, which enables them on your blog. This worked very well at first, but as the list of available widgets grows ever-longer, adding widgets has now become a big chore: good luck to you if you select a widget at the bottom of the list.
The problem is complicated once we throw accessibility into the mix (as always!) – say for instance you’re me with my terrible eyesight and have your browser zoom set between 150-175% by default. Working sometimes with Magnifier open and docked, I have at worst 11.5″ of screen real estate on an already-small 13″ 1280×800 screen. The following is a screenshot of my entire browser window at my normal zoom levels: the draggable element is too large to even fit on the screen.
On drag-and-drop pages where I have to traverse large screen distances or work with tall elements, I basically zoom out to 50% or less, do all my edits there, then restore to my usual 150%. It is incredibly frustrating.
There are a few solutions to drag-and-drop usability problems. The most obvious is to add a different method of control. Try for instance up/down buttons that reorder elements in a list. WordPress has actually done something about the problem (slipped in so quietly that I just found out 30 seconds ago). Widgets can now be added by clicking on their titles, which brings up a menu allowing you to select where they should go, followed by an Add Widget button.
If you want to keep the fun and impressiveness of drag-and-drop, there are ways to do it in a manner considerate of the fact that not all users have the same computing setup as the developer does. Some possibilities:
shrink elements when they are picked up
have a little schematic where changes can be made and reflected on the main content
drop targets that scroll together with your position on the screen so that they are always visible
Drag-and-drop is a very nice user interface touch in my opinion. When used well it adds fun, simplicity and a deliciously analogue tactility (which I love), enabling users do what they want faster and more easily. But care needs to be taken to ensure it doesn’t become a drag on the overall experience.
Trying out the Post Formats in WordPress – this is an Aside, for short snippets that don’t really need a title. Or something. No one really knows what they are: try searching for “wordpress asides” to see what I mean.
My ideal way of building curated repositories of links would be through a place like delicious; however that never quite managed to take off (high barriers to entry, ease of use was always somewhat lacking. I used it the most between 2007 and 2009; since then I’ve tried a few times every year to go back, but the idea of having to properly retag my old bookmarks is daunting; the bookmarking process is still a bit too slow and clunky, and (to me) it is harder to access your bookmarks than to create them. I’ve since amassed a huge library of browser bookmarks, an uncategorized mess that I rarely wade into anyway.
I do think that if a big effort were made to reintroduce it today, it might really get somewhere, because we’re now so completely used to #tagging #everything and the idea of #socialmedia – something that the web in 2005-2010 wasn’t quite ready for yet.
I think the hypervisual bookmarking trend (see: Stars/Chrome Bookmark Manager) is a little silly. On Pinterest it works because I don’t think the site is a social bookmarking service, no matter what it and tech journos like to call it: it’s a social mood board site. Otherwise for users with thousands of bookmarks – who imo are most likely to desperately need bookmark managers – it’s a waste of space. Screen real estate is precious.
That the bookmark management problem is still exists is clear, at least.
In the past month or so of working on projects with the Student Devs I’ve had a chance to use some of the methods I’ve read about, and in almost every case, I’ve come away impressed by how these methods are actually really useful.
Because I’m still relatively new to UX (to compare, I’ve been serious about illustration for over five years now), I run into a lot of firsts these days while working on projects. First guerilla user test! First stakeholder interview! First user journey! What’s been really enlightening – and humbling – has been understanding the utility of tools and methods that I previously thought of as kind of pointless.
I’ve been reading about user-centered design since discovering it shortly before coming to college, but I’ll admit that a lot of it always seemed…silly? obvious? overhyped? to me. A lot of UX techniques are very straightforward. Write down all the different sections of your site and organize them into logical groups. Make simpler versions to test first before investing hours into a high-fidelity prototype. They always seemed too mountain-of-a-molehill, too formalized, too much like Process with a capital “P”.
Well, I guess now I’ve learnt to not knock it till I try it – in the past month or so of working on projects with the Student Devs I’ve had a chance to use some of the methods I’ve read about, and in almost every case, I’ve come away impressed by how these methods are actually really useful.
For example, as a fun side project, Thomas and I are making an app that helps students shop more efficiently at the school snack store. I decided to try making a user journey for how students currently interact with the store – it would help identify ways our app could be more broadly useful than the simple initial idea, but I also did it in large part because I felt like that was what “real” designers did: go through Real Designer Processes. So I went through the process.
I felt very silly going in, writing down every step the student went through, I was also unsure of whether I was doing things correctly. There are tons of templates for user journeys online, all slightly different, all slightly confusing. In the end I decided to grab a random set of useful-looking attributes from the templates and made my own. Our imaginary persona was Hungry Bob, a student who had missed lunch due to a meeting with a professor that ran long. Hungry Bob was then brutally subjected to every stressful experience possible within the snack store: public shame, long queues, confusion about prices, not enough time to browse, hard-to-find items – all the while contending with gnawing hunger. To be honest, I thought it was a little over-the-top…so it was both reassuring and worrying that when I showed the completed user journey to Thomas, his first comment was “wow, that’s exactly what happens at [store name] all the time”.
By really getting into Hungry Bob’s mindset, reflecting on our own frustrating experiences at the snack store, and examining each step of the process in detail, I was able to come up with a few suggestions and refinements to the original idea that I wouldn’t have thought of before. For instance, we originally had your in-app cash balance hardcoded to be $8, since that’s the amount students are left with on their cards if they don’t use it on lunch. But while thinking about how students actually hunt through the overpriced items at said store trying to find a way to maximize the lunch money, I realized that people often don’t mind paying slightly more than $8 if it allows them to get a few items that they really want, instead of an item they really want and disappointing filler items like carrot sticks or something. (Sorry, carrot-lovers.) I feel somewhat sheepish that it took creating a user journey to realize this, but hey, at least we saw it, and now our app has a flexible lunch money limit. It’s a very, very simple change in the code, but it makes the app much more useful to students – at least, I think it will. We haven’t gotten to the user testing stage yet.
I’ve also had a chance to see the emotional use of prototyping beyond its obvious “let your clients complain about something before you spend weeks building it” purpose. This week has seen me creating a mid-fidelity mobile prototype for an app the Yale College Council requested, using InVision (which I’m happy to plug here because they gave me a free student subscription, and because it’s really an amazing tool). The councillors handling the project on their end have been really happy with the ability to play with an intermediate prototype, instead of crossing their fingers and hoping that we deliver something that they like, and we’ve been talking about changes they’d like to see.
What’s cooler in my opinion is what happened with the snack store app. On Friday last week we took the idea to some managers within Yale Dining, to ask if they’d be okay with us making it, to see what their broader goals were, and to ask for access to their data. I think doing the user journey gave us some useful specific student experiences that we could refer to during the meeting to make our arguments more compelling. Would we have been able to bring them up without doing the user journey? Yes, but having mentally walked through the store earlier helped make certain oft-overlooked points much more salient.
Anyway, our meeting was going on, and we were encountering some resistance to our idea – one of them didn’t think it was particularly useful, and was much more enthusiastic about the prospect of us (implementing? customizing?) a third-party service that did something else entirely. More than half an hour in, one of the managers was starting to get the utility of our idea, and I felt like this was a good time to lock in his support. We hadn’t planned on showing the very basic prototype that Thomas had made over fall break, since it’s a plain text-based app with a couple of hardcoded values that doesn’t really do much – we didn’t think it would help our case. But by this point in the meeting I’d figured that we needed all the help we could get in communicating our idea, so I got Thomas to pull up the prototype on his phone.
That was probably the most interesting mood transition I’ve ever seen in a meeting. (Thomas says he couldn’t detect it, but I’ll believe it was there.) Both managers got more interested immediately, leaning in, expressions changing, becoming more curious. Once there was a working – even minimally – prototype on that conference table, they got much more engaged, playing with our four hardcoded snacks, adding and removing items from the cart, testing the autocomplete. It was easy to see that our previous descriptions of the app had been too nebulous, not compelling enough – probably due to our inexperience with meetings and pitches – and that now they really understood what we were going for. After that it was an easy sell. I was really impressed. I mean, you read about this kind of stuff, and about how Processes/tools are supposed to “disrupt client engagement” or whatever Markov-chain buzzword is in fashion today, but seeing it work in person is something else.
So. Yeah. That’s been really neat. I’m enjoying being a designer and giving myself permission to work on design and only design: I kind of wish I had more to do with the programming bits, but I know there aren’t enough hours in my life for me to do that many things well. Besides, I’m making a MUD game, and writing specs and code for that is using up most of my programming time.
User-centred design is a lens through which we can see the world, but it can sometimes feel like a new pair of glasses that you carry around and sometimes forget to wear.
Although I am now a user experience designer with the Yale Student Developers, and have always seen myself as a very user-centred person – whether I’m programming or drawing a magazine cover – I haven’t been doing this quite long enough that this way of thinking is completely internalized. If you’ll forgive the somewhat contrived analogy, user-centred design is a lens through which we can see the world, but to me it still feels like a new pair of glasses that I carry around but sometimes forget to wear.
Today I had to borrow a laptop from a friend to record a short video for German class. (I actually had to try three friends and three laptops, and none of them worked properly, so I’m going to give the speech in person after class tomorrow. Yay, “technology-enabled learning” done wrong!) While trying to get to the webpage that would let me submit my homework, I couldn’t help noticing that this friend’s laptop was horribly slow. Tabs in Chrome were all unresponsive. It took me 20 seconds just to application-switch.
Curious, I looked at what was running in the background and the first signs of the problem became evident: he somehow had four antivirus suites (two expired, one semi-functional, one apparently working) and five file-syncing/cloud backup services all running at the same time. Despite the presence of the file-syncing clients, he also wasn’t keeping backups of any of his data. The applications running might not have been the source of the slowness, but that the machine (and his data) was in this state gave a good hint as to what the problem might be.
When I returned his laptop to him I asked if he was aware of this situation. “Uh, yeah,” he told me, sounding unsure. “I think I installed all those programs by accident? I can’t find the uninstallers. And I don’t back up my data, yeah, I know I should, but…”
This is a facepalm moment, isn’t it? This is the kind of story that you tell back at the tech support office, to collective head-shakes and horrified looks. “Oh my god,” we go. “Why are users so inept?” And then we exchange smug looks. Users, man.
This is the moment you have to catch yourself. Is it really the user who is at fault? Or is it because the uninstallation process** isn’t intuitive? Why isn’t he backing up his data despite having multiple user-friendly cloud backup services at his disposal? Does he think it’s too difficult? Does he not realize that these programs offer him a way to back up his data? Could it be that these aren’t as easy-to-understand as we think they are? (You’d be surprised at how hard it is to explain the concept of file syncing to people, even college undergraduates who have spent at least half their lives online.)
I certainly didn’t realize what I was doing at first – after all, poking fun at the less tech-savvy is a comfortable and familiar hobby for most of us. I was telling a programmer friend about what had happened, and we were expressing amazement at how widespread bad computing habits were when he remarked, “people need to take better care of their computers” – and I suddenly became very aware of how we were pinning all the blame on this guy who had lent me his laptop so I could do my homework.***
As UX and product management people in the tech world, it’s only natural that the user-centric glasses we try our best to wear still fall off our nosebridges sometimes. After all, we’re mostly in this industry because we care about the people using our products, yes, but also because we love technology. We think the stuff engineers can come up with is awesome, and we want to make it even better. We’re all geeks. (Some more than others.) There will always be times when we forget that not everyone is the same way, when we’re baffled by another person’s unfamiliarity with something we work with every day, when we’re tempted to roll our eyes and declare the the problem exists between the chair and the keyboard.
What’s important is realizing when that happens, taking stock of the situation, putting the glasses back on, and looking again.
* I considered adding the sentence “my goal is to have the mental equivalent of laser surgery”, but after thinking about it for a little while, I decided that this isn’t really something I want. Although great in theory, I suspect that would tip me too far into the other direction, and cause me to lose touch with engineers instead. I need to be able to see how others see – not fully become others and lose the ability to view things from multiple perspectives.
** Mobile is one place that really gets this right. Uninstalling apps on smartphones is almost universally painless – perform the action that brings up a context menu, then select “remove” or tap a cross or drag it to a trash bin. Macs come a close second, except that the drag-to-Trash gesture doesn’t work for every type of application. The desktop environment is so wide open and subject to developer whims that the same kind of standardization is hard to achieve.
*** The way we instinctively shift responsibility off our products onto users reminds me a little of the language used in contemporary misogyny, actually: “women need to be less aggressive”, “women need to wear less revealing clothes”, “women need to sacrifice their careers to focus on their families”. If we can put so many resources into hiring UX people and good PMs to change the dialogue surrounding our products from “users need to X if they don’t want broken computers” to “computers should make it easy or needless for users to X”, we can definitely put the same amount of effort into changing the power dynamics and dialogue surrounding non-males in the tech