My “Why Is My Underwear in the Microwave?” blog post references apps’ illogical design. If you haven’t read the “underwear” blog, click HERE.
This post is about the other half of the problem we users have
This half refers to poorly presented user documentation. Along with poor application design, they add up as two strikes before we even get into the batter’s box to know how to use an app.
What helps to confuse us, when attempting to perform an app function, is that many times their clickable-labeled named items don’t make sense. The clickable items are presented as hyperlinks, buttons, and tabs. Hyperlinks usually are correctly labeled. Buttons, most of the time—but not always—are correctly named. Tab labels, more times than not, don’t match up with their respective subject matter to act upon.
Newspapers get this right when they label a continuous read to another page. If a news article is about how a man confronted an alligator, its linking label from page most likely would be identified as to go to: “Page 3, Alligator.” Computer clickable labeled items only take us to a next page where the page, only, is the link. And if that next page has its many clickable items, then where on that page do we start?
Our Third Strike to Swing At
As for user documentation, there’s no one standard for all.
- Some apps use videos to describe how to do their user procedures.
- Others show page-pictorial images with embedded text in their procedures.
- And lastly, there are those that use only text for their procedures.
I hate “how-to” videos. They’re not fun to watch and listen to amateur actors’ boring ten-minute (of fame) presentations. And then what, am I supposed to memorize what was said in order to do its procedure function again six months later? And if I need to refresh myself on an item that’s in the ninth-minute of the ten-minute movie-clip, I then have to hear eight minutes of blah, blah, blah, that will surely put me to sleep. Visuals are for movies and TV shows that includes professional actors, which serve their purposes well. I’d be upset, if I went to a movie theater and instead of seeing the movie, I’d have to read its script pages instead.
Apps that present their procedures to include displayed pictorial images added to their procedures to perform, are not good choices either. This method inflates the length of their procedures.
If each web page had its own unique name shown at the screen’s top middle, then in the text-only method, their procedures would easily describe the named page and what the user needs to do next. Text-only procedures are short and sweet. They are performed step-by-step in bang, bang, bang, downward fashion. This should be the ONE and only standard method.
I would think it’s the application owners’ responsibility to provide good user procedures; after all they are the apps’ providers. They assume their app is the only one we users use. I got news for them, speaking for myself. I use more than 100 apps and there is no way, I can memorize how to do every app’s, every function.
Crazy Owner’s Manuals
My new 2015 Hyundai car came with eight books—that’s a little much!
One of the manuals describes how to delete a route, which doesn’t make sense. My argument is that a route is subordinate to a destination. If I don’t have a destination to go to, then I don’t have its route. When having a destination to go to, the only thing I can do, route-wise, is to change it, to either get to its related destination by the quickest method or by the slower scenic method. In either situation I end up at my destination.
One of the most basic data processing fundamentals we users need to know when performing various app functions is that we are to:
- Add the whole of something that was never there before which now needs to be included, or
- Change parts of that something that’s there now, which needs to be updated to stay current, or
- Delete the whole of something that’s there now, which is no longer needed.
Something could be any data entity such as a user profile, a text document, a pictorial image, etc. This is important to know, the: add, change, and delete functions are of equal status, and each is not subordinate to the other two. Logically we can’t change or delete something if we first didn’t add their something. And we can’t change something if it’s already been deleted.
We users can’t do these three functions if the technical end doesn’t allow for this to take place. Yet, I find it amazing how many apps make it so complicated to accomplish these three basic functions, especially the delete function. This is where we can tell the difference between a professional and an amateur app designer.
With my car’s weird routing app, I have to go through its change portal to make the delete happen. This doesn’t make sense to me. The delete button should be displayed next to the change button in the same screen portal. As to destination, we can only add or cancel (delete) it. Think about it, we can’t change a destination.
What follows is just one example regarding user documentation we users are frustrated with
I have five app payment accounts that automatically send their respective charges to my bank account each month. With each account referring to my respective profile pages, I need to include my credit card data. We know what’s required for it: the sixteen card numbers, the expiration date, as well as the three-digit security number on the card’s backside. Each of these three data items can be individually changed.
What I find amazing is that each of my five payment accounts have five different procedure methods to affect these three items for change, and none is designed by the best one standard method I would have designed, which is to treat each of the three entities separately to either change: any one, or any two, or all three.
Stay tuned as there’s more blog posts coming on this important user documentation subject.