We’re familiar with the Uncanney Valley that is the gap between desktop interfaces and accurately recreated, desktop-like interfaces on the web. But there’s an Uncanney Valley between real web interfaces and mock web interfaces, which the Gmail team have found in their recent labels update. By imperfectly recreating a text field they’ve added needless friction to a simple workflow. If it looks like a text field and feels like a text field, I’ll expect it to act like a text field! An “edit” button or icon would suffice here, and be easier to implement. (The problem: the first text field is an impostor and clicking in it to place the cursor actually opens a new field for which the cursor needs to be placed again!)
7 Comments
What’s wrong with it? It’s just in-place editing, isn’t it? In case you want to rename a label.
Posted by aimee.mychores.co.uk at 10:09 pm on 5 July, 2009.
I’m not sure I understand the problem here - on Safari, when I click the label name, it turns into a regular (native) text field. I could understand if it was an text field implemented in HTML/JS, they are usually as a disaster (as are simulated scroll bars).
If your point was to the edit action being implicit – well, I think it’s a question of trading off discoverability vs. UI clutter. I think the hover makes it reasonably clear that an action is possible – and it’s a pattern familiar from other popular sites (e.g., Flickr)
A similar point could be made for the re-orderable message list on the Gmail Inbox. The “grabbable” pads on the left of the message rows are a better option than explicit up/down buttons.
Posted by Niall Smart at 6:10 am on 6 July, 2009.
Hi Aimee, Niall: I’ve added my description of the problem to the post.
Niall, re discoverability vs. verbose, obvious, cluttered interfaces: I agree completely in the case of frequent use software like Gmail.
Posted by Eoghan McCabe at 8:40 am on 6 July, 2009.
Works for me in Firefox, although I hate this sort of thing because it just creates inconsistency between web apps. The likes of Google who can afford the time and effort on client side development are driving a wedge between them and smaller app developers when the truth of the matter is, this stuff should be baked right in to the browser(s) to provide a consistent interface that my mum can understand between apps.
Interestingly, I just had a problem submitting this comment! The text fields below look very similar to the post button and as such I completely ignored them as text fields!
Posted by Tom at 11:39 am on 6 July, 2009.
@eoghan Ahh, gotcha, the cursor position doesn’t click through when transitioning to edit. That’s probably the reason they select the contents of the text field when beginning edit. (Flickr has the same approach/problem). It’s possibly misleading to describe it as an “imperfect recreation” of a text field, as from what I can see, the editable version is a native UI component, it’s just that they can’t/don’t capture the click position and translate it into the cursor position.
Though, to the main point, having looked at it again I’d have to agree that putting a “rename” action beside the others would seem like a good decision – after all they are repeating show/hide/delete in each row…
@Tom I had exactly the same problem submitting comments here!
Posted by Niall Smart at 4:27 pm on 6 July, 2009.
I am jealous of your fuzzy dates! Wicked touch.
Posted by Lauren Fisher at 9:47 pm on 6 July, 2009.
While I agree there is potential for confusion, I have a feeling this works pretty well.
(Please do not interpret this as fanboyism)
Google is known for using extreme amounts of user testing on any and all ui changes (even down to the shades of blue, as mentioned by a former google designer recently).
Unless they’re breaking from this trend, I have a feeling this has been shown to a large number of labs users, before it was publicly announced.
Posted by Brian Artiaco at 6:42 pm on 16 July, 2009.