Chronicles of Noivad

The commercially available GUI is now over 30 years old. We all know that what was once a paradigm altering way that communications engineers, researchers & computer scientists could interact with their machine has firmly cemented itself in the landscape of interfaces, as the mice and trackpads that came with it. Initially the GUI was called a novelty that would quickly wear out its welcome by companies that have since staked everything on their misunderstanding of how a GUI should act. Now that a more common use paradigm is direct touch. The conventions useful & familiar with the desktop metaphor have been replaced by a graphic icon collection to open an app suited to the task. Again people who’s thinking is still bound by conventions of prior use paradigms that either work poorly or not at all without alteration to fit into new paradigms is hobbling the efficiency of their user base. The base-line of porting UI to a tocuh UI has been accomplished: where it was a double click to open, it is just one tap; where it was a menu bar window, it is now a navbar & bottom “tab/panel/view.”

However, Before this current paradigm shift happened, the GUI had already been mutating between versions & various OS platforms until new conventions were tried & failed or took root. Often multiple ways to interact are allowed in most desktop OSes, & between platforms some interactions are preferred, while other are simply cumbersome. Somewhere along the way the fundamentals of UI design were forgotten & exchanged for the slickest looking UI and usability took a backseat to aesthetics because the people who placed aesthtics fist didn’t realize that aesthetics and usability are tied together.  Thus the interactions needed to perform an advanced task became unnecessarily cumbersome, and furthered the knowledge gap between the novice and the competent.

Navigating a modern OS is a labyrinth for novices, and many never even see the structure they are navigating in (orientation). Worse companies hire many people without testing to see if they really know how to use a computer. They just assume “knowing X” = “competently and efficiently using X.” So, while I might not bat an eye in changing a preference in response to an error or unwanted/slowing behavior, many remain forever ignorant of how to fix a minor configuration problem or that changing a behavior is even possible. Sure, there are many books, blog posts & other articles out there, but most people’s interaction is limited to “just getting the job done” which is perfectly fine if one is thinking about using a screwdriver or a hammer, or even a multitool. But for a tool that might give no visual clues in how to use it effectively like most modern software, most people’s education is reduced to learning behaviors from others through imitation, and luck of discovering things. In my experience, most people that rely on computers to do limited or specific tasks (such as manage a bank account, write a document, play a game or use the internet to interact with via a SoNet), few of them actually take the time to learn how their machines work regardless of the form factor of that computer — be it a desktop, laptop, tablet or smartphone.

I encourage people to spend an hour per day just playing with their device or watching a video or read a book or a few hours a week learning to use their device. The reason is this hour will pay itself off as the person learns how to fix errors that cause confusion & result in either downtime or simply to use their device more efficiently to get work done faster, and have more time to relax away from the computer.

[Reviewer Note: No one will take an hour. How about a smaller bite, 10 minutes, or the length of an entertaining youtube video — concentrate on learning one small thing? Make it a habit. This habit of learning in little bites will eventually translate into larger bites of time.]

Also, engineers that dismiss a professional UI designers touch need to respect that there is just as many layers of foundational knowledge to make a good UI as there are to make a good infrastructure or API. Judging by some of the UIs out there, the people who designed UI features that make it difficult to navigate their interface obviously haven’t studied the problems of making a good UI. If designers used a process of problem solving that includes at least one of these methodologies:  “paradigm/design principles/considerations/bounds/extension” or iterative “build/observe/refine” (the last being the simplest process), then it could vastly help a person designing a UI understand that few of their user base think like them and even fewer will instantly “get” their UI. However, this is only effective if the UI designer is open to change to accommodate everyone both above and below their GUI savviness level, not just themselves.

Given the low percentage of users that do “get” the UI with the user base expanding faster than can be accommodated, I think it is time UI designers help users learn to use their devices. A few minor & very easy features to implement in app — some that could be implemented at the OS level — would help users learn to use their machines for a few minutes at a time or when it’s convenient for them.

Every Control & Icon has a Description (Hidden Close By)

Now this first sounds messy until you consider that these pop-overs/popup windows could be hidden in a layer until needed (layering, progressive disclosure). A double-tap tap or hovering over an icon (already in some apps) or heads up display toggle would show a tooltip style pop-over that could be overlaid on screen highlighting meaning and function of an icon or a description of a setting (progressive disclosure).  Much like other ballon help systems this could include more in-depth info and also be allowed by both linking to online resources and local resources (either a visual and/or textual explanation that could give an example and show contrasting choices when needed). Each and every option or icon in a preference pane or dialog should have a little tooltip next to it explaining in non-technical jargon what this setting or selection does (assuming the choices are not crystal clear — “delete <document name>” is pretty clear). A link to expand the block (progressive disclosure) to define terminology (orientation) also could load an external demo showing its use and how it changes a view or behavior.

(see In-App Instructions Animated for how local resources could work to instruct). 

[Reviewer Note: Even us oldies would love something like this since some apps that we use are rarely used and we simply don’t remember what it does. Also an ability to quickly and easily turn off the these tips or select the amount of information displayed — name only, small help bubble, small help bubble with links, and when selecting those options a pictorial example would be show exactly what that means. That’s another pet peeve. I like the little circle icons in some UIs where the user can click on them to see an explanation of what that option does. What I would like to see is a “more” link inside that that would popup a pin-able window that the user can move around to help with task at hand and roll up when it gets in the way to just a title bar (like a window shade).]

QuickTips 

The second idea, quick tips, is already in some apps. I just wish they’d be system wide, and supported with an “Upon launch” OS feature. Helpful info could show up on the splash screen. This could tell a user how to use a shortcut they’ve been accessing via the pulldown menu. For example, in most web browsers and other apps with form fields, a quick tip such as “To quickly change form fields, hit the tab key to go to the next field” would speed up many novice/naïve users ease of using your browser greatly. If an icon is unique to your app, showing the icon and what it stands for could help users avoid the trip to the “Help::Search” menu option. Even something as simple as showing what the symbol is for the option/alt and control keys are, what a apps specific, or stock OS icon sets  (like the various arrow icons) mean.

Just knowing this keyboard symbol set would help a lot of novice end users

In-App Instructions Animated

This tip could even go further and show where they can alter the way info in displayed. Something as simple as: “Want to changed what loads when you launch this app? Check out APP_NAME::Preferences::General::Upon Launch, with the bolded text a clickable link that not only opens that panel & highlights the sub-pane but also animates pulling down the menu items & navigating to that pref. This feature is present within JetBrains IDEs under the help menu currently and in other programs. It really helps find things assuming the user know the “magic word” (meaning “proper term”). Another quick tip could impose a heads up display overlay like some mobile apps have that highlights the General Tab that show a description of what settings reside in the tab.

[Reviewer Note: Yes another real bad pet peeve of mine. No links, and I am supposed to remember how to navigate 7 layers deep. What’s worse is when there are links but send you to the top of the navigation, and the window that directed you there has already disappeared. I have great working memory, but remembering that is challenging for me.]

Is this a lot of work? Not if one compares that to the manuals that used to come printed with how to use each app & their troubleshooting steps. And it is worse considering the low usage number of some knowledge base [KB] articles that fail to actually answer the question. Knowledge bases could be linked, but requiring no extra effort from the user is the best way for them to do just-in-time learning by simultaneously doing. This method of learning by seeing and doing is proven much faster, especially when combined with orientation material & overviews that allow a person to understand what they are doing and why.

[Reviewer Note: Another pet peeve, the KBs only tell you when it works, and don’t mention the numerous ways it can fail and what you need to do to get back on track.]

Breaking the Page Paradigm

The fourth way to improve UIs would be to break away from the page metaphor. People like pages because they are familiar with them. People keep records and get information on static, forever unchanging pages. While that WYSIWYG metaphor once helped people unfamiliar with how to operate a computer once allowed them to quickly adapt to using the web, The display itself is redrawn 60 or more times a second at resolutions getting close to rivaling baseline laser printed output. So, while on a printed page,the only way to “update” it was to make a pop-up book with manual tabs to pull to change content, on the computer the dynamic nature of the interface has been mainly used to animate games and watch movies. The only visual difference between this text you are reading is the medium. If you want to see what is embedded in a URL you have to click on the link and you are taken to a completely different page. Compounding this is now 2 issues: (1) usually the page loaded in completely contextually unaware of what info you wanted from it, unless you are logged into the same site. For instance, if linked to too general a page or a page with a lot of different info, you might have to find the content on the page. This is basically like losing your place in a book and this forces you to de-focus on absorbing information and switch mental processes to locating information.

Usability & Learning Resistance

(2) Worse, if the link is changed, the content breaks. This is out of control of inter-site links, but I see this even within the same commercial site. Again this usability resistance forces the user has to defocus, and switch modes to try to locate the info they needed with either a search or looking at the URL and seeing in modifying it will at least land them in the index for the subsection (if there is one). Had this info been dynamically pulled from a data store updated with each release and expanded in place (using a view update instead of a new window), focus is maintained, time learning is saved  (learning/orientation resistance is lowered) because you’ve cut out re-orientation delay, and the person gets his or her work done faster.

All of the “in-place” information “feeds” alleviate the need for switching mental modes and losing time. If the situation is particularly bad: such as there is no overview, index or “compatibility-worded” navigation bar that is actually arranged logically for your site or no other way to find content but doing a search — hoping to type the magic word that gets enough, but not too many hits, then users often get lost even trying to locate sometimes the simplest of information. The end result is they give up trying to learn and just grit their teeth and trudge through if they must or find an easier to use alternative. (BTW: pop-overs on web articles from offsite links also discourage users from using your site. So, while you might make $.0001/page load you might be missing out on repeat business non-intrusive ads at @.00005/page load could get you.)

Also, documentation online is often out of date, so screen shots and settings that might be valid for one version of an app might not be accurate for another version. All of this makes end users throw up their hands and really dread using their machine or your site/app. So, they use it like a tool they don’t like using: meaning the use it simply to do their work and that’s it. No learning, no BS, even if ultimately learning the conventions of an App or OS would allow them to get their work done much more quickly.

Part 2 coming “soon” ;)