Nice Guy Wi-Fi

Category: UI/UX

  • Matt’s Rules of UI / UX

    First of all, I am not a UI/UX (User Interface / User Experience) designer, programmer, etc. I am simply a user who observes and sometimes tries to think of what decisions I would make if I was in charge of building something. Some of these I have read about and some of them I just think are good ideas. I doubt any of these are new ideas.

    Some of these apply only to web interfaces and some of them apply to anything with a graphical user interface.

    Overall look

    • Should have user-configurable dark and light mode
    • Should have text size increase and decrease controls
    • Should be printable nicely (where applicable)

    Forms

    Save everything

    • Submit asynchronously so that work is never lost (dynamically save everything to local storage and only clear once successfully submitted and processed by server side)
    • Clicking Submit actually makes a spinner inside the button until it is verified saved on the server side. Give positive feedback (e.g., green check) upon successful save.

    Navigation

    • Pressing TAB should always move between fields in a specifically-defined, orderly fashion
    • Pressing ENTER to submit a form should try to submit it (unless you’re in a <textarea>, obviously).

    Numbers

    • Don’t use <input type='number'> unless the number will definitely be 999 or less. See next point for rationale.
    • If a field is for numbers larger than 999, allow commas and periods. If bytes, Mbps, etc., allow things like M for Mega, G for Giga, etc. Convert the letter indicator to a number in the backend upon submission (for example: 500M becomes the number 500_000_000).
    • Beware of comma and period use outside your own locality. Rely on Intl.NumberFormat or another region-aware library in JavaScript or equivalent backend code or tell the user via hint what format is allowed.

    Error handling

    No text fields should be cleared upon error

    Give the user a clear explanation as to what is expected in the input field. Do this either in placeholder text or a tip above or below the input field. The illustration below demonstrates a violation of this.
    Errors should not be indicated until a box that was active is “inactivated” (i.e., onblur), with the exception of numbers having commas, M, G, etc. (see Numbers above). Also, onblur will allow an empty box without complaining–even if it’s a required field. The animation below illustrates a violation of this.

    It shows errors before the user has even had a chance to fill in any data. As soon as the user starts to enter data, the error changes to a complaint that it’s in the wrong format. But the user hasn’t finished typing yet! It should only complain if the user goes outside the active text input.

    If a change has been made, clicking any button besides one explicitly marked Cancel should inform the user they have made changes and those will be lost rather than silently discarding the changes. The animation below illustrates a violation of this.

    Clicking “Back” should first confirm we want to abandon changes. Otherwise name the button “Cancel”

    Errors should be checked at the frontend and backend level and the error message should be carefully constructed for brevity, while maintaining completeness and proper spelling and grammar. The complexity and verbosity of the message should reflect the supposed audience. Error elements should be indicated by something (e.g., red box).

    Addresses

    • State/country selection performs a search when clicking in the box (put cursor in top of box)
    • In a country selection, the country “auto-selected” should be derived from browser’s “Accept-Language” header (e.g., “en-US” picks “US”); if there is none, just list the countries in alphabetical order (see below):

    Cursors

    • Cursors should always indicate what is expected of the user. If it’s link-like (include expand/contract), it should be a pointer. If it’s a button, “default” is fine.
    • Don’t use the “not-allowed” cursor in a text box, as it makes people feel like they can’t select and copy. Instead show a “read only” message if they try to actually type in the box. “Not-allowed” is okay for checkboxes and radio buttons.
    • Great reference: W3 Schools Cursors

    Links

    • All sections of a page should be clickable and have an ID that can be linked-to directly (hovering over them indicates a chain icon and clicking them updates the browser URL).
    • Within reason, all things you can left-click should be right-clickable and “open in new tab/window” should be an option.
    • All things you navigate to in a single-page-app should update the URL bar with #location so it can be bookmarked or referenced later. Likewise, pages must be constructed so that if a user navigates there later it loads into the proper page and section.
    • Similar to above, everything that could be referenced elsewhere or a link sent to someone else should be laid out in the URL bar.
    • URLs should be as short as possible while maintaining uniqueness. Even allow for self-shortening. For example:

    Wording

    • Be precise. Ambiguous words can cause confusion. For example:
      • Reset – Does this mean “reboot” or “factory reset?” Never use the word “reset” by itself. Instead use “reboot” or “factory reset.”
      • Cancel – Does this mean “cancel the changes I just made?” or cancel something else? For example, don’t have a calendar entry with a simple “Cancel” button; instead say “Cancel meeting” or “Cancel changes.”
    • Translate everything! Even if it’s just American English, it might eventually be other things as well, so use translation strings on the backend from the beginning. If at all possible, have a native speaker do the translation–even if it means open sourcing your translation files.
    • Grammar and spelling! (note that was an incomplete sentence; appropriately-applied, self-aware humor is exempt from all rules). Develop a custom style guide, based on something generally accepted (e.g., Chicago Manual of Style). Be consistent throughout. An example of customization in a technical article on networking would be in the use of the past tense of NAT:
      • NATted
      • NAT’ed

    Video Controls

    Allow shortcut characters while a video is playing (case insensitive). Most of these are based on YouTube, which I think does a great job, and being the most watched video service on the planet, sets the bar.

    • K or SPACE – Play/pause
    • J or left-arrow – Jump back 10 sec
    • L or right-arrow – Jump ahead 10 sec
    • I – Info (Time remaining, speed (1x, 1.2x, etc.)) – stay 4 seconds but disappear if i is pushed again. Same behavior and timing on mouse over/still/out
    • C – Captions toggle
    • < or  , – Decrease speed
    • > or . – Increase speed
    • F – Full screen toggle
    • T – Theater mode toggle
    • M – Mute toggle

    Most of these shortcuts can be made with the right hand on the keyboard without moving. When doing video on a tablet (e.g., iPad with attached keyboard), be sure to include keyboard shortcut support.

    Clicking anywhere on the video with the mouse also pauses it, unless there is an information/settings overlay, then clicking on the video hides the overlay, but does not pause the video. If it is a touch screen, clicking on the video does not pause it, but brings up the controls.

    Final Thoughts

    Ironically, I violate some of these with this blog. This is a list of my ideals and personal guidelines. As Captain Barbosa said in Pirates of the Caribbean: “The code is more what you’d call ‘guidelines’ than actual rules.”

    I have more to say on the subject, for example, a collection of some of the terms I’ve learned by reading books, blogs, and watching videos on the subject. But that can wait for a different day.