Now, I think you can split gestures into two categories. One is of the pull-down-to-refresh kind. These are gestures that are discoverable and explanatory. The other kind of gestures are like tapping-the-status-bar-to-scroll-to-the-top, or swipe-to-delete (or swipe-to-reply in Tweetie). These gestures you won’t discover on your own except by accident. These are not discoverable, and they are not explanatory.

This second class of gestures can exist (in my opinion) because they are not the only way to accomplish a goal. In the case of tapping the status bar, users already know how to scroll to the top manually. It’s slower, but it’s possible. In the case of swipe to delete, users already know they can tap on a message and then tap the trash button. So knowing the gesture isn’t necessary.

So when you’re inventing new gestures, it’s important to think about whether the gesture is required to use the app. If it’s the only way to accomplish a goal, you better be sure it’s discoverable and explanatory without needing to read a manual. If it’s the other kind of gesture, go nuts!

From Twitter Reloaded: an interview with Loren Brichter

The behaviour is common practice now, not only for single-field forms like search inputs, but entire ten-plus field information gathering forms. This is where the problem arrises. If you’re like me and tab between inputs (‘fill in field, hit tab, fill in next field, hit tab, etc), it’s very easy to forget that you need to read the value (acting as a label) in the next field before tabbing into it – as soon as it has focus, you can no longer tell what you’re supposed to be inputting.

The placeholder attribute should not be used as an alternative to a label. –HTML5 Draft Spec

Even more recently, the HTML5 spec introduced the placeholder element for inputs. Though the HTML5 spec advises against using a placeholder in place of a label element, it seems common practice to do so, and it tempting even for myself. This would be fine and dandy if it weren’t for the specific implementation of placeholder‘s behaviour in all major browsers: Exactly the same as we saw above, clear on focus. It leads to precisely the same problem as before, but this time natively instead of using a bit of JavaScript.

I’ve created what I believe is the ideal alternate behaviour multiple times in the past with a tiny bit of JavaScript and CSS:

• Position the label for an input directly below it with the same borders/padding so that the text lines up perfectly with what is typed in the input
• Using JavaScript, bind a function on change for the input that checks to see what the value of the input is (after each keystroke), and if it’s anything other than blank, hide the label. If the label is hidden and the input is blank on change (you’ve deleted the contents of the input), show the label.

I’m not completely sure whether the necessary change here is in the behaviour/intended use case of the placeholder attribute or in the code developers are writing in conjunction with their forms. Since it’s highly unlikely the HTML5 spec will dictate such a change at this point, I think the onus is on developers to be more careful with the aesthetics/usability line. If you implement the above properly and with care, you’ll have an accessible form that saves clutter and uses no additional markup.

My predictable solution:

Perhaps I’m ramping this up too much. Recognize this bad boy? Find yourself constantly checking the symbols and their meanings when you’re trying to decrypt a keyboard shortcut for use? Guys, it depicts a choice. A fork, a switch. The name of the key is ‘option’ (or ‘alt’, which is also accurately represented, alternative).

See it? Assuming this is your first realization, I’ll allow you to draw your own conclusions about the other symbols used for control and command.

Have a great weekend!

Well, not really, but every time I need to plug something into that 3.5mm jack on the back of my iMac at the office, I can’t help but think about why it’s so difficult. I’ve pondered putting that port on the side, on the bottom, anything that helps access – but really, repositioning offers no ideal or substantially improved alternative.

While the same issue is present with the USB ports in the same area, they’re much more defined and can be felt out with relative ease. the issue with the 3.5mm port is that it’s so small, so challenging to accurately locate with your index finger, blindly. So I propose a simple solution (the best kind!). Recess it in a small (approx 1cm in diameter) dimple . Around the size of the tip of an average finger. This does two things: Makes the port easier to find blindly, and provides a very small targeting assist – the plug would slide in with relative ease even if aimed a little bit off.

How’s that, Steve?

ALL images in this post are credited to macstories.net

Finder has gone the way of iTunes, totally grayscale. I get the decision to some extent, unifying everything, but this oversteps design boundaries – it’s excessively sterile. I intentionally keep all installs of OS X I control on the original OS theme (with the ‘traffic light’ window controls), because I find Graphite (which effectively grayscales those icons) borderline depressing. I think a grayscaled Finder should come with the selection of the grayscale OS theme, and otherwise they should remain colored.

Also worth noting is the new button style for the finder views. This change appears in multiple screenshots of Lion. Clearly it’s very resemblant of a touch (iOS) interface, but the connect isn’t there for me – mice, even trackpads, are not on the same level as touchscreen devices. There’s no tactile simulation, which a slideable element implies. Why are they trying to meddle with this before they’re ready to go touchscreen in any sense with OS X? Additionally, I think the UI feature makes zero sense on menus with more than two items. This is a toggle-specific interaction as far as I’m concerned – true/false, on/off, enabled/disabled. Not list/icons/details/coverflow.

Also, why the bloody crap is Coverflow still in Finder?

I’ve been using Letterbox for well over a year, perhaps two. All it effectively does is change the orientation in Apple Mail from displaying message previews above the mail list to beside it, to its right. This allows for greater vertical message list length and message preview length (and if you’re like me, you only view messages in ‘preview’ mode. In short, it makes better use of widescreen monitors. This is now unnecessary, as Apple has rethought this in Mail 5, changing the orientation and making other iPad-like interface adjustments. This, I’m excited for.

Yes, I know about Post Box and the like – to be honest, I can’t properly explain why I’ve never made the switch, though I have tried. There you have it.

I have only one thing to say about the revised TextEdit: Holy shit, TextMate supports list writing (properly)! Welcome to nearly two decades ago. I hope the OS’s global font/formatting chrome has been significantly improved as well.

Finally, one of the oddities I encountered. Quick look has always been very much a keyboard access UI for me – tap space, see if it’s what I’m looking for or scan for a piece of information in the document I was looking for, tap space again to dismiss. I don’t like that they’ve introduced a clickable button to the quick look interface here, as this is one of the last places I’d want to use a mouse. Odd.

Why on earth can’t iTunes keep in line with a user’s intended commands while both playing and browsing through a library? Why is it that, when I am in an artist view and play a song and then switch to another artist’s view just to look around, iTunes plays out the current track and then picks a new one from whatever the hell I happen to be looking at at that moment in time? This behaviour is totally unjustifiably ridiculous.

I re-tested this today to find that now, instead of continuing with tracks in the view you started the current track from, it will move on to dead silence. I’m not sure if this was changed recently or if I’m doing something differently, but if it’s the former, what a pathetic attempt at a solution to a problem when the real solution of obvious and not very complex.

Apple, iTunes is one of your biggest cash cows, but also some of your shoddiest UX work.

The importance of this process is often overlooked or not sufficiently analyzed for shortcomings or elements which can be improved. If conversion is everything with your app, this is the first and (hopefully) only barrier separating them from the experience and utility you have to offer. Time to get it right.

I’ve always been particularly drawn to the UX involved with forms on the web. They are by far generally the most tedious and taxing commonalities for the typical user (and the rest of us too), and request the most of the poor user who probably doesn’t want to type anything more than URLs.

Fields. What’s required?

The registration process – it’s like the bow on an icebreaker, if it fails the rest is completely screwed.

Take a moment to think about what data your application actually requires from each user. More often than not, that’s email, username, and password. That gives you enough information to authenticate and identify a user within your application, as well as of course communicate with them via email. Every field beyond that is one additional hurdle for the user, or perhaps more accurately, your application’s ability to get a user on board.

Let’s take for example a ‘name’ field. Not username, name. That’s right, this is the internet, you have to ask if you want a real name. First of all, is a real name necessary; could you request it post-registration (more on that in a bit)? Is that field one or two (first and last names)? Will you need to use only the first name at any point in time, or only the last name? It’s not safe to split at the first space to display first/last names if they entered it in one field, so the need for two fields is created. This initial consideration for what information you need to collect decides the format and structure of your entire registration flow, arguably the most important part to any web application’s initial success.

The minimalist approach

Occasionally, I come across websites that only ask for your email address and handle the rest for you. That is, they send you your password via the provided email address. What does this constitute as effective for? It’s the sites like Instapaper (which actually doesn’t require a password at all if you don’t feel the need to protect your account or specifically want to make it public) that don’t have a basis in community. Personal applications that are meant for pure utility and often don’t have high security requirements.

Is this approach effective? Yes, as long as it’s suited to the application. More importantly, is it possible to bring some of the ideas behind this approach to other, more in-depth registration processes? It’s the non-personal information in a registration form’s requirements that can sometimes be considered troublesome to fill out, like the password field (more on that later). Another example would be selecting a vanity URL. While this could potentially be presented post-registration, could it not be included in your registration form and filled in automatically based on your username or first/last name fields? When you ‘tab out’ of the last name field, could an element appear with the proposed, already confirmed as available via AJAX, vanity URL that consists of the first name field and last name field, no spaces? Rdio does this successfully on their registration form.

Bending standards

Beyond the fields included in a form for (or in the subsequent stages of) registration are more set-in standards. I’ve been noticing more and more questioning of ‘password masking’, the default behaviour of password fields in-browser. That is, the way password inputs replace each character you type with a bullet point or asterisk. This has been the accepted and standard behaviour for as long as I can remember, and the only variance I can recall is the slightly changed behaviour on many touchscreen devices, namely the iPhone/iPad.

With a slightly less accurate/predictable keyboard, typing blind is a bit too much to throw at users – so on these devices, the last character you type remains visible for about a second, or until you type the next character. This behaviour is fantastic. It could be argued that it degrades the security that the masking is designed to provide in the first place, but if you have someone looking that closely at what you’re doing to follow the ‘visible’ tail-character, they might as well be watching the keys you press. The obvious ‘next step’, passible or not, is un-masking completely. This is where I would draw the line on mobile devices, as there are far too many situations where an onlooker with nothing better to look at could very easily read your password. On desktop platforms, however, I think it’s a different story.

What I’m getting at here is that silly confirm password field that accompanies quite literally every single password input I’ve ever seen. I understand why this exists. It is impossible to know 100% what you’ve typed in as your password. One typo and you’ve got to go through a reset password process before you’re even fully registered. However, the problem is created in the first place by the masked password standard. In this respect, an unmasked password fields solves the problem – double-check once you’ve typed it, even if you were watching your fingers on the keyboard or your cat playing with the printer (aww), and you’re set.

What about those curious onlookers, though, near your desktop computer? Let’s be honest, how often do you sign up for a new service with somebody looking at your monitor? Admittedly, however, it is a potential problem, so here comes one more question. Where do we give the user a choice? Is it a browser setting? and OS setting? Functionality you build into your applications’ registration form? Well, I was unsure about this myself, but then I remembered what I’m writing about here - registration forms. None of this subject is applicable to login forms, as there is no ‘bloat’ input to fix with log in forms – get it wrong, simply try one more time and get in. That answers the question – this is very much a per-web app feature. It can be safely assumed, optional or not, by neither the OS nor the browser that password inputs should not be masked.

I’m thinking about building up some alternative password field behaviours in the near future, watch this space.

Post-registration information

oh hai, reminder

In the case of an application that requires a fair amount of information upfront, in order to enable all of the application’s most important functionality, some choose to first get you registered – that is, username/email/password – and then prompt you to complete your profile before you can begon using it. Sometimes it’s optional but continues to bug you about it (“Your profile is 15% complete, only 4 steps remaining!“), and other times it’s a forced second registration step. In the case of Rdio, the first step is essentially just an email confirmation step on its own – and serves to get your email address in the system just in case you flake when the next registration step arrives (in which case you’ll get email reminders to finish up).

This approach has pros and cons. Again, the necessity of the second-stage information collection must be questioned. While it may seem more likely that a user will just go ahead and finish up the registration when they’ve already created an account and just need to provide a bit more information, it’s also borderline sneaky and some users won’t appreciate that. If it’s not *totally* mandatory, that usually means you’ll have a ‘progress’ meter until the end of time letting you know what you haven’t yet done to let the service know who you are or let the world know about your presence on it. Typically, there’s no out-out for any given step that you decidedly do not want to complete (see left, on Klout), although in my opinion that would solve the problem. You’re encouraging the completion/actions, but not forever criticizing your users for failing to comply. If the missing information makes missing functionality evident, the requirement will appear necessary, instead of demanded.

Security

The security of a user’s account is governed almost entirely by the password they choose. Sure, there are best practices to evade hacks and account cracking centered around the UI (such as displaying only ‘login incorrect’ instead of ‘wrong password’, which gives away an existing username), but really on an individual account level, it’s about the password. Developers know this, and password requirements have become commonplace. In theory, password requirements/restrictions make perfect sense – if the user wants to use abc123 as their password, simply don’t let it happen. However, it’s also a deterrent unless it’s done very gracefully.

I’ve come across password fields that take password security into account, but absolutely ignore UX. Being informed after submitting the form that my password doesn’t contain the necessary characters? Having a maximum character limit (baffles me each and every time, seems somewhat totally counterproductive)? If requirements are going to be imposed on one of the most basic fields in registration, one of two things need to happen.

1. Make the password for them. This could be done by leaning-up the registration form and sending the password to the user via email along with a confirmation link (two birds with one stone). Alternatively, you could get crafty with the single password field in registration (read upwards for a discussion on password masking) and essentially provide a password generator rather than input. Something I’d particularly like to see in something of a hybrid is a password generator with an optional checkbox that reads ‘create my own password’ and otherwise implies that a less complex password will put their account at higher risk.
2. Make it as painless as possible. Be upfront with password requirements. Make the lower character limit six, not eight – unless perhaps you store credit card information within user accounts. Provide examples. Take from the above point and provide a randomly generated one and give them a ‘fill’ or ‘use’ button to use it.  Finally, let them know as soon as they focus out of the field either way whether it’s good. These parameters should negate the need for a ‘password strength meter,’ I have doubts about how useful they are to anyone in the first place.

The registration process, the most forward-facing and fragile part of your application’s user experience, deserves more attention. It’s like the bow on an icebreaker, if it fails the rest is completely screwed.

Another oddity is the change in symbol color – on the iPhone, they’re both white, and here we are on the Mac with a white App Store symbol and a black iTunes symbol.

Long story short, it’s not very well unified. I’m satisfied for now with one quick change, purple-izing the iTunes icon to at least resolve one of those issues.

Feel free to download  here (.icns, ~255kB).

Updated to get the tone closer to that of iOS’s icon, cheers @adambetts! Could get closer, but the icon as a whole is shaded completely differently – somewhat difficult to balance it properly, additionally with the black symbol vs. white.

Really, in most circumstances, small- to medium-sized sites should be plug-any-play for the client.

The challenge I come across often is with complex page designs that contain various blocks of content. It’s cases where a page template contains several different areas of content that handling how the user manages that content becomes a bit complicated, and  the process strays from intuitive to abstract for the client. The three most common solutions I find used are as follows:

• Posts as content blocks. Even when the content areas are static and specific to just one page, often a site will ship with posts categorized by the page they are to appear on. Worse, sometimes the template actually calls specific post IDs. Template files, should never, ever, ever use specific content (or user, or taxonomy, etc.) IDs, and an options page with drop-downs is a half-assed workaround. This process makes the concept of a ‘post’ totally abstract to the user. Why can’t I edit the content in the ‘page’ editor?
• WYSIWYG Editor Formatting. TinyMCE is a decent editor but let’s face it, you simply do not rely on it to keep track of more than lists, paragraphs, and some inline formatting. Asking a client to enter code view, ever, is a sin in my book.
• Custom fields. Probably one of the better approaches, but not without its problems. Using custom fields on individual pages creates global entries in the wp_options table, which show up in all instances of that Custom Fields meta box. Why should the client have the option of entering phone_number and address_1 on the Gallery page? the global level is problematic in this case, and the custom fields interface as a whole is not as intuitive as one would like.

None of these solutions is ideal. They each have potential to confuse the client, screw up the display of the page, or result in emails to you when you haven’t included ongoing maintenance in your invoicing, but you can’t ignore because they’re a result of the clarity of what you delivered.

So, how do we fix it?

I’ve had a solution in mind for months now that I can’t find any problems with. Before I begin, let me say, I work in the template level in WordPress. I build functionality that works as plugins, but in themes – I get fairly involved with the core and its hooks, but I am not a core developer. The feasibility of this seems real to me, but it’s completely possible I’m not seeing a conflict in core implementation or hole in my logic. I welcome any and all feedback.

The same way you can use <code>add_meta_box</code> to add meta boxes in custom post types content types (really, they’re not ‘post types’, I don’t know how they got this name), we should be able to use a similar function (or perhaps the same function with a new argument using the template name) in the context of a template, and its callback to add new fields . The rest is the same as with custom content types as well – the <code>save_post</code> hook to collect your custom fields and any necessary JS or CSS included in the admin dashboard using <code>wp_enqueue_style</code> on <code>admin_init</code>.

The concept is simple, once you select a template for a page and update the page, the new fields become available. If you or the client changes the template, you can change it back without losing any data as it’s saved as meta data and is not removed when the template is changed. Within the template file now, you can use <code>get_post_meta</code> to collect your custom fields, again, the same as with custom content types. These custom fields are completely contextual to the template file you’re working in, and this file is not used unless the template is selected for a page. There are no conflicts, no confusing or unusual interfaces, and the code (if implemented as I’m seeing it) is nothing unheard of in the WP documentation.

These are quick thoughts, but the idea’s as developed as it can be for myself – I would love some insight, positive or negative, as long as it’s constructive into the development of this or reasoning why it’s unnecessary.

A slightly belated happy holidays to everyone, hope you had an excellent Christmas if that’s your thing!