I recently read Hamlet Au’s Is Second Life’s User Interface Cursed by Knowledge? post on new World Notes, where he tries to put the finger on the failure of Second Life You-Know-Where’s user interface to make the world and its usage accessible to newcomers. I even commented, a quick shot and rant that failed to relieve me, instead simmering inside my mind since, eventually to take the shape of the following post.
Hamlet Au’s argument hinges on the theory of « the curse of knowledge » as propounded in a New York Times article he quotes. The gist of it seems to be that woeful interface design is the result of people deciding which features should be exposed in the interface, and how, on the basis of too much technical knowledge. He concludes :
So how do you fix the Second Life You-Know-Where user interface? In all honesty, I probably can’t say. Then again, the Lindens can’t say. Metaverse developers can’t say. Longtime Residents can’t say. And if you read this blog on a regular basis, you likely can’t say, either. Thanks to the curse of knowledge, the very people who know Second Life You-Know-Where most are also the least qualified to introduce it to a mass audience. (This is probably why the open source initiative and heads-up displays have failed to improve user retention– most of the improvements and features to come out of them are made not for new users, but for established Residents.)
Now I think there is little doubt the interface of Second Life You-Know-Where could be tremendously improved to flatten the notoriously steep learning curve of new residents. Honestly, those of us who did not have an excellent background in 3D / FPS gaming had great difficulties mastering even the most elementary parts of Second Life (moving, interacting with objects, camera controls — more about these later) on the first go — I know I had. As to more advanced functions, I’m ready to bet that even long term residents are unaware of many tweaks, tricks and minor but useful functions.
As a moderately long term SL Y-K-W resident (my first rezzday approaches fast), I am eminently not qualified to comment on the improvement of SL Y-K-W’s interface according to the « curse of knowledge » theory. I cannot help feeling, though, that hands on experience as the (mostly unwilling) user and victim of a plethora of interface concepts and implementations both in hardware and in software form does count — in your case as in mine, for that matter : just look at the small ecosystem of remotes that probably has evolved in your living room as it has in mine, never mind the applications and underlying operating system of your computer —, and that some understanding of what you actually can do with an item (be it hardware of software) is necessary to ponder the best way to use it, though, obviously, this might often not be the one chosen by the manufacturer or propounded by current thinking (anybody remember the Office Assistant ?). Which is why I will count the fact that I never designed a complex technical system (software or other) in my life, and that I am happily and utterly oblivious of all theories of interface design as a big plus.
One thing that struck me in the comments that followed Hamlet’s post is that what most people discussed was the graphical interface to SL Y-K-W. The talk was of better and more appealing graphic widgets and of adding more « intuitive » interface elements as well as introducing the web metaphor into the client (a teleport back button, for instance), besides the odd call for splitting the monolithic viewer into smaller tools (*nix geek syndrome, I think this one is called). Basically, the commenters seem to agree that what sucks about the GUI of Second Life You-Know-Where is the « G(raphical) » part.
I disagree. To me, the user interface is far more than the window system, widget set, or « skin » as it is fashionably called these days, used by an application. I don’t think the main problem of SL Y-K-W‘s interface is graphical in its nature.
Just have a short look at it (it’s that big, battleship grey and barf purple coloured window that is gobbling up resources on your desktop) : an ugly text button bar, true, but one that works quite well ; an even uglier general design in the aforementioned colours , but one that works according to accepted GUI conventions (i.e. it uses a main and context menus triggered the usual way, has the usual set of widgets, supports copy and paste as well as drag and drop — etc.). It’s even scalable (though it looks bad at every scale but 1.0), which I wish other interfaces were. True, it’s not pretty, but there are no major graphical interface sins in sight.
So, what is the problem then ? I think it is one of concept, not of graphics. What needs to be addressed is the UI (sans G), which I would tentatively define as the way the functionality of a complex system is exposed to the user for interaction. The challenge for SL Y-K-W interface design is as follows :
- The underlying system is incredibly powerful and versatile, which makes it a very complex machine to interface with indeed ;
- Cutting back on options and features (as some have proposed, both in the comments to Hamlet’s post, and this Metaversed post) only undermines the cornerstone of SL Y-K-W’s success, viz. that there is virtually nothing you can’t do with it. Take the popular argument for hiding building tools from the user : not everybody wants to create content, that much is certainly true, and getting into edit mode the first time, often unintentionally, is indeed a jarring experience. Still, the availability of user created content and the fact that it can be modified to suit your needs is one of the many things that make SL Y-K-W so attractive. Just ask your favourite fashionista : every single one of us consumist chicks is half a builder, as the same tools which have created the things we wear allow us to adjust them to our body shape, remove and or modifiy parts we don’t like, retexture and recolour them and generally tailor an important part of our SL Y-K-W experience to our wishes. Would I want to start a « building viewer » each time my jewellery does look wrong ? I guess not, though I might if I get desperate, being a bit of a power user — but what about new users ? In the long run, the move would do nothing but split the population in a builder elite and a passive consumer mass unaware of its opportunities, sacrificing one of the major differences between the world of SL Y-K-W and the atomic one on the altar of the « uncluttered » GUI.
- Which leaves no way but to make the mastering of the system’s complexities as easy an experience as possible. The key to this, in an interface, any interface, is to create an internal logic that is as intuitive as possible, stick to it consistently, provide good feedback when you interact with it and, last but not least, document the whole thing lavishly. It hasn’t got to be simple. Just to be usable as if it was.
SL Y-K-W’s current interface is an excellent example of how not to do it. The only consistent part is, in fact, the often vilified graphical one. There is no logic recognizable beyond that but the half digested ones of 3D / FPS games and 3D design tools, with a bit of IM client thrown in. The windows-esque GUI on top but reflects that sorry state of affairs.
Take mouse tricks for instance. There is mouse camera control : tricky to use, poorly documented, and with no interface feedback whatsoever beyond the intrinsic one, the not always useful POV (where is my damn camera in relation to me, for instance, and why am I staring real close up at a wall, and how the h*** do I get back to normal ? What did alt+ctrl+pan do again ?). And as to the derivative mouse tricks, nearly all are poorly documented (advanced walk being one example), if at all, their logic is counterintuitive, and the little feedback the interface gives is often misleading (think of mouselook, where alt+clicking does what ordinary clicking doe outside mouselook, never mind the cursor, your only feedback, indicating otherwise). Do you know how long it took me to notice that alt+clicking does not only lock the camera on something, as documented, but also locks the AV’s gaze on it, thus being the key to eye to eye contact in conversation ? What is the logic behind that ? Normally, camera control is independent of AV movements, in fact, that’s one of its strong points once you’ve started to master it, but not when alt+clicking. Yes, there is a logic to this too in some designer’s mind, but is it pervasive ? Consistent ? Obvious ? I think not. Which makes it very bad interface design, despite being an incredibly useful feature I would never want to miss.
And what about the keyboard ? Its main keys work different depending on context. Don’t believe me ? Alright : the enter key ends chat input, sending typed chat on its way. Unless the chat box is hidden, in which case it shows it (ever forgot to hit it before typing ? Yippie, instant flight). Oh, and if the box is already visible, and according to your settings, it might also close the chat box again. Very logical. Arrow keys are used to move, and they will also move you if you try to use them in the chat edit box, unless you tell SL not to ; but they will not move your AV when used in other editing boxes, no matter what. So much for consistency, huh ?And then there is the space key. Which makes you take little steps in combination with movement keys, and breaks a fall… unless you happen to have the chat box open, that is, when it inserts a space. Oh, that works in any text box that happens to have the focus, by the way. Yay.
Then there are the HUDs (I’m just talking of the ones included with the viewer) . They are a late addition, I’m told, and it shows. All of them are hidden by default, except for the potentially most confusing of them all, the mini-map. It takes time to make sense of the map if you’re not a seasoned gamer. But my, it blinks and rotates so prettily (look, real time !), now that is what I call an interface. On the other hand, there is that boring camera control HUD well hidden in the menu, which despite a sore lack of feedback in its current state (you can’t see what level you have zoomed in or out, or how far and in what direction you have rotated or moved the camera) simplifies the use of the camera so tremendously I’m ready to bet the early learning curve would be half as steep it it was on by default, and mouse camera control deprecated to a power user option. One third as steep if it provided some feedback, and offered a « reset camera position » button.
At least, the HUDs are logical, reproducing other ways to do things in a point and click manner (kinda like button bars) — zooming with the HUD is like zooming with the mouse wheel, no ? Oh, aye. But shall we talk of the zoom shortcuts ? You know, ctrl+0, ctrl+8, ctrl+9 (only ctrl+0 is working on the numerical keypad, incidentally). They take on zooming is quite a different one : unlike the wheel and the HUD, which zoom the camera in a way reminiscent of optical lenses (up to the point of showing a measure of optical distortion at close range), the shortcuts magnify or de-magnify the whole frame of reference. Zoom in with ctrl+0, zoom further in with the mouse wheel, reset your view with ESC, and find out … that you are your still zoomed in. You need to hit ctrl+9 too. Yes, there are valid uses for it (building with small prims coming to mind first), but again : is it logical ? Is the logic pervasive ? Intuitive ? Obvious ?
And if we ignore all these logic glitches, the lacking feedback, the poor state of the documentation, and look only at the conventional UI elements, such as the menu, what do we find ? A ramshackle assembly of functions often hidden in lengthy and convoluted, partially hidden menus (think of the debug menus, which contain some crucial settings and options, like rebake). The state of the menus shows the lack of cohesive, pervasive, intuitive logic in the client.
One final example : calling cards. You know, the things in your inventory which seem to be redundant of your friends list ? Well, they’re not. They are a bright idea which got buried in the interface, never seeing their logic point anywhere in it outside of the inventory. Originally, they seem to have been intended as a lower level kind of contact management than the RL IM inspired buddy list the friends list is. Calling cards, simply put, are a shortcut to an AV profile stored in your inventory. You can manage and organize them as any inventory item (unlike your friends list, which knows no folders). Close friendship privileges, like being able to see each other’s online status, or being mappable and such, need promotion to friend status, but you can have calling cards of people that are not on the friends list. In fact, every friend you delete from your list remains in your calling card folder (that has saved many of us when SL Y-K-W’s servers have decided to munch up our friends list, not an unheard of event). Sounds great, no ? So why aren’t calling cards handed out routinely ? Because, a.) you cannot request a calling card from someone else, unless you do so in chat, and b.) even if you do so, they can only give their card to you face to face, by finding the option in a nested submenu of the context menu of your AV. Very logical, seeing you can propose friendship from any AV’s profile, wouldn’t you say ? And no, of course, you cannot create a calling card from a profile, while you can landmark a location. Why is that ? Logical. Consistent, too. And well documented. Not.
I could go on and on. The problem of SL Y-K-W is not that its GUI design is ugly (it is). The problem of SL Y-K-W’s interface is that SL Y-K-W itself is, to make a simile, an incredibly powerful, lavishly stocked toolshed for virtual world activities, but that it is the kind of toolshed where there are three kind of Philips screwdrivers of every size with only very slight, but significant (and of course undocumented) differences, except for the size sixes which have been retired from service and are meant to be put back real soon now, any day really. Half of the wrenches are in the lowest drawer, below the jackhammers and saws, the other half is pinned on the wall. There are three boxes full of power tools, all of which are unlabeled, the inscriptions scuffed off or useless, plus each one needs a different power cord, at least two of which you might find in the cardboard box labeled « old screws ». Never mind the two cords which seem to belong to no tool whatsoever. And, oh, one of the drawers has been stuck for ages now, we’re not sure what’s in there anymore but it might bite you on the bum if it’s still alive.
Repainting the shed will not help. Burning the shed down and starting from scratch seems tempting, but would probably be a case of throwing out the baby with the bathwater. Emptying every damn box and drawer, finding out what is needed for what, throwing away what is unneeded, eliminating redundancy by merging things (throw two away, buy one new) and sorting everything before putting the most frequently used things in plain sight, and the others in boxes and drawers neatly and clearly labeled might help a surprising lot. Because, Linden Lab, unless you do, too few U will keep using your I.
[applause]
What *do* you think the main problem of
SLY-K-W’s interface is?@Casius : err, didn’t I say ? To quote myself : « the logic glitches, the lacking feedback, the poor state of the documentation ». Or, as I tried to say with my tool shed simile : far too little organizational logic for the power of the application.
As a footnote, read the following aperçu from a real-life conference on virtual worlds at the IDC Hertzelia :
Now, if that isn’t the curse of knowledge, I wonder what is 🙂