Show HN: Usability checklist – catch common problems before user testing | Hacker News Reader

Show HN: Usability checklist – catch common problems before user testing

userium.com

216 pointsuserium36 comments

If you want, you can also create a raw Markdown template to use in GitHub issues, after GitHub implemented Tasks: https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-....

    To Do
    =====

    Groceries
    ---------
    - [ ] Buy milk
    - [x] Buy eggs

EDIT: You could also play with the idea of a paid plan that allows users to create their own custom checklist using a select amount of your checks - possibly with the option of creating their own as well.

I'd consider throwing down $3 or $5 as a one-time fee, and even if the site stops working, I wouldn't have minded spending that money.

EDIT: Another feature could be the ability to display your own list on /user/123. It'd save me the bother of always going on about the same things, especially when it comes to accessbility.

EDIT: Another feature could be custom CSS and branding, but that could be implemented as a second tier, since other companies might want to use this for branding and PR. I personally don't care for it as a private individual.

Very good suggestions, thanks for the feedback! I will continue to improve the site.

Here's the Markdown template if anyone is interested: https://gist.github.com/vegasje/5454527

Hi,

I want to introduce a tool which allows creating custom checklists, sharing them, printing, etc. - for free: http://checkvist.com . There are some premium features, but they are not checklist-oriented. You can create list, share it with your team, clone the checklist, print it.

May be someone will find it useful :)

Thanks, KIR

Hi Everyone,

I created a free - research based - usability checklist, which can be used to catch common usability issues on websites before doing expensive user testing.

By fixing obvious usability problems you get more meaningful feedback from user testing.

Please help me make this service better by sending some feedback. Do you find this useful? Would you use this? Should I develop it further?

Many thanks in advance!

-Nina, nina@userium.com, http://userium.com

Looks good. It should help raise awareness of common issues and help make more user-friendly web sites and applications.

Minor gripe: shouldn't it be alt attributes, instead of tags?

I'm seeing the content flash when checking/unchecking an item. Can I suggest toggling a class instead of wrapping/unwrapping the <del> tag?

  <style>
    .done {
      text-decoration: line-through;
    }
  </style>

  <script>
    $(document).on('click', '[type="checkbox"]', function () {
      var $this = $(this);
      $this.parent().toggleClass('done', $this.is(':checked'));
    });
  </script>

The title should reflect that it's a checklist focused on websites. I opened it expecting to apply it to desktop applications and was surprised by it.

More suggestions for the accessibility list:

    1. If you have to use divs and spans instead of more
       semantic elements like lists and headings,
       use precise, descriptive IDs. Same for classes.

    2. Use WAI-ARIA in your HTML[1].

    3. Link skips.

[1]: https://developer.mozilla.org/en-US/docs/Accessibility/ARIA

This[1] is the official CSU Sacramento checklist for accessibility, it might help flush out some of OP's checklist items. It is a bit outdated (2009) so I wouldn't necessarily recommend taking it wholesale.

[1]: http://www.csus.edu/irt/web/accessibility/Resources/checklis...

..."pay" is be a button"...

should probably say

..."pay" should be a button....

Thanks, I will fix that!

[list-item-requests]

1. Basic functionality of the page can be used without mouse, just with keyboard (using TAB button to navigate between the links / buttons). Whenever I TAB, the active/focused item should be clearly indicated e.g. with a border or different background color.

2. You should be extremely careful not to override the native keyboard shortcuts of the browser. E.g. SHIFT+ARROW_LEFT/RIGHT/UP/DOWN are commonly used to expand text selection (TheNextWeb is an offender here, as they treat arrow left/right as a shortcut for "prev/next article" which extremely annoys me). Ctrl+L focuses the location bar of the browser. AltGr+[a-zA-Z] are used in many languages to enter diacritics like "ó".

Regarding (1.), some of you may find interesting my study regarding support on HTML elements to trigger JS event listeners in various browsers:

http://jakub-g.github.io/accessibility/onclick/

Do you know why it prompts "This page is asking you to confirm that you want to leave - data you have entered may not be saved."?

I've added 'window.onbeforeunload' to test a weird behavior of IE<=8 (actually I could tweak the JS on the page to add the listener only for old IE). When you have a link like '<a href="javascript:void(0);">' + onbeforeunload + click event listener bound to <a> doesn't return false, then clicking (from mouse/kbd) such a link triggers onbeforeunload().

It's documented under http://jakub-g.github.io/accessibility/onclick/#note6

> You should be extremely careful not to override the native keyboard shortcuts of the browser.

Yes. Please heed this Facebook, Twitter and all the other sites that hijack '/' to do a search. That already means "Find in page" in Firefox.

As it stands this is very web-centric. I'd suggest distributing all the points on different checklists for different types of applications. Relevant types that I could think of right now could be: Web site, web application, mobile app, desktop application, console application (maybe). Of course, many points would be the same for different applications, but some are only relevant to a subset (e.g. desktop applications don't necessaily need a memorable URL or use the browser's back button).

Very nice work, though.

> Color. Visited links color is different than unvisited.

I thought most browsers disabled that feature some years ago to prevent the exploit where you could see all the websites a user has visited by sampling colors of pixels at strategic locations.

Speaking of usability, what does the "reload" button in the bottom right do? For me it resets the form, not reloads it, whatever reloading a form means.

Otherwise very nice list. Can probably be made infinitely long though

Visited link coloring work on my Mac Safari 5.1.7. You can easily try it on your own browser by going to google.com and clicking a search result there. The link changes color.

Here's a good explanation what the exploit is and how it was prevented in Firefox: http://blog.mozilla.org/security/2010/03/31/plugging-the-css...

The css :visited pseudo-class now only allows certain changes, such as changing the color of text. The browser does show those changes. JavaScript can ask what color a link is, but the browser will always lie and say that the page is un-visited. If blue is un-visited and purple is visited, you may see in the browser a mix of blue and purple links, but your JavaScript will only see blue.

Very good idea. If I could suggest some improvements, it'll be good to have a separate print-only stylesheet [0] and test it cross-browser (probably one-column only, or two-columns with small adjustments). Currently, in print preview with default settings, it produces either hell lot of unused whitespace in the portrait mode (Opera), or not-so-much-but-still in Firefox due to floating issues. It looks much better though in Chrome.

[0] <link rel="stylesheet" type"text/css" href="print.css" media="print">

great idea and a nice list. any links to articles that support the reasoning behind a recommendation would be useful, though definitely not neeeded for every bullet.

Maybe some sort of ranking of importance, even user voting. Like when following MVP, is it critical to have X or Y at release.

Thanks for the list.

I see a lot of the easy-to-forget-but-we-all-know-we-should-do-them things, so bravo, thanks, and bookmarked.

Well done. For people whose Firefox's Acrobat won't print or for people who tried printing using IE8/9/10 and received the JS error, browse to the page using Chrome and print. You can easily save as PDF.

Would be great to see local storage or something similar implemented on the page, so I could maintain this checklist on a per-project basis without having to go over the list repeatedly.

Suggest adding Font section to checklist - e.g. CSS providing generic font fallback. Fontsize recommendation 16 px, line height 1.5 em, relative fontsize for Hx etc..

Good stuff! Here's few more..

Should there be one check to ensure that the site works at least somehow if javascript is disabled?

Also, there could be one check to ensure that the pages can be printed.

Here's even more:

- Site should work even if the page is zoomed in (e.g., visually impaired people may do this). There are two kind of zooms in browsers, one zooms the whole page pixel by pixel. The other one zooms only fonts. It is usually tricky to get the font zooming look good.

- Icons and images should look good in high resolution retina screens. Bitmap graphics have a tendency to look pixelated in retina screens if not done properly. See http://www.html5rocks.com/en/mobile/high-dpi/ and http://www.html5rocks.com/en/mobile/easy-high-dpi-images/

- Some people use Screen Readers to browse the web. The web site should have easy navigation and have text for all non-textual content. See http://webaim.org/techniques/screenreader/

Also, you already mention responsive design for various screen sizes. You could mention that it means the pages should look ok on tablets and phones.

EDIT: I just can't stop... one more thing: The page should load fast even for users who are using 3G networks

You should customize the bootstrap variable that controls the navbar collapsing width.

There's no need for a collapsing navbar if it has just one item that easily fits on all widths.

Nice, this is a really good list. You should put this up on Github (or something) so others can submit feedback/requests/corrections/etc.

I've been looking for such a list before, glad to have found it! Please don't stop developing it!

$('input[type="checkbox"]').each(function() { $(this).attr('checked', 'checked'); });

I suggest a new name. userium is giving me a headache trying to figure out how to pronounce it.

Use the european pronunciation: user-eee-um.

Reply on news.ycombinator.com