The UX of HTML5 | Hacker News Reader

The UX of HTML5

cxpartners.co.uk

33 pointsrobinwarren8 comments

Perhaps this was covered in the talk and not the slides, but here it goes.

I think one of the paramount things about UX that people forget is designing for your audience. If you are fortunate enough to have a grasp on the types of users your product has, use that knowledge!

For example, the whole sunday vs monday as the first day of the week is not universal. This pattern should be applied regionally whenever possible.

Another example, one of my projects in particular used spinners pretty excessively. It was a small on-site user base, so I just watched them interact with the various inputs. I found that inputs that were simply integer based, and less than 4 digits, spinners were great. For consistent sequences, dropdown lists were the key. Anything else was a simple input field. All of these, of course, required input sanitation.

But, if I would not apply those assumptions to a new project. If you can try to get an understanding of your users before you design.

Yes. And, keep in mind, there is an incredible bias in usability tests toward novice users. The UX for an app used one time is completely different from the UX of an app that is meant to be used on a regular basis by the same user. For example, text entry for a date would be a lot more efficient for an experienced user than dropdowns (as presented in this presentation) would be. In fact, the dropdown solution would probably annoy an experienced user. With user experience, context is key.

Drag and drop just doesn't seem to be in the lexicon. It's only to be expected after 20 years of not having it on the web. Sure, there may be some exceptions - GMail's sorting into tags comes to mind - but it's just not happening any time soon.

There's also a good reasons all the controls like spinners and sliders and calendars haven't been around before HTML5. It can very easily be argued that they weren't needed before then. A language like JavaScript that doesn't even handle decimal points or localisation of date formats, currencies or calendars just isn't ready to keep that infrastructure up without any browser libraries behind it. And even HTML5 doesn't do anything to approach this. There is no sane mechanism to provide l10n or i18n on a website that integrates nicely with JavaScript or HTML5, and that's a major reason calendars won't happen. Ditto with the sliders and spinners. Why ditto? Because it's a symptom of the same problem.

What HTML5 is providing in the UX side in the examples given in that presentation is a very, very bare skeleton of a functionality that doesn't extend to provide good user experience. You imagine your Photoshop web designer bound to his iPad for the past two years, and there's no hint of appreciation for the default HTML5 slider there. And with good reason. It sucks.

Give some logarithmic stepped input. Or some way of CSS-enabling each component. Or some sane way of doing drag and drop in an easy way that doesn't require about ten JavaScript event listeners each, and it may work.

But right now, it's just plumbing and some elements that even jQuery UI does better. Maybe that was the goal of HTML5, maybe not. But it's not helping out there when people feel the need to rewrite and redevelop the wheel of every widget because they feel that the HTML5 standard just doesn't do enough.

It is doing some truly, truly beautiful things. The parser infrastructure developed for it alone deserves to be put in a museum and have temples built to worship it. But I agree with the presentation that ignoring so many things that Metro and Android and Apple have addressed over the past few years when it comes to Fitts' Law and loving usability is what HTML5 is doing. And it's kind of sad, because there's a few parts in HTML5 that should be driving everything. They are in Metro, but it's not the same.

I can't wait for the day when HTML5 provides a native way of doing semantic zoom or drag and drop or lovable calendar widgets, but it's not any time soon.

Thank you for the link.

Here’s what to do. Technically it’s a little harder. Don’t enter labels in the text field because as soon as you type they are gone. How do you check you responses when reviewing a completed form?

Can someone explain that sentence to me?

I believe he's saying to not use "placeholder" attributes to indicate whether a field is required because it disappears when a value is typed into it. Instead, you should use some helper text underneath the field.

Imagine you have a placeholder in a date field that tells you the format in which you should enter the date ("mm/dd/yyyy"). You enter the date and that information is no longer visible. You finish the form and think "Wait a second, was that supposed to be mm/dd/yyyy or mm/dd/yy?". That's the general idea.

Yeah, because of all those people that "review forms" after filling them in!

Major train company giving a refund? HAHAHA don't lie

Reply on news.ycombinator.com