Raymond E. Floyd
©SHUTTERSTOCK.COM/OLEKSANDRSHNURYK
In the electronic environment of today, the sophistication of a user cannot be anticipated to be at any particular advanced level. As a matter of fact, users range from first graders, to individuals with advanced knowledge, to elders with little or no technical background. As a result, a much greater burden is placed on software developers to ensure the product they release operates correctly under any conceivable key entry from a user. Anything less can be a disaster for a product, or set of products, due to customer dissatisfaction and complaints.
Whether one is wandering a street in a city, sitting and enjoying a meal in a restaurant, or walking the halls of a high school or college, there will be people intent on some subject matter on their smartphones, iPads, or other modern devices. In many cases, they are oblivious to the world around them. While the majority of these individuals understand the technology they are using, at the user level, it is doubtful that their knowledge goes much deeper. They use what they need and ignore all of the other things their device is capable of. In that respect, they don’t know if their device performs correctly or not, as long as what they wish to do is done properly.
Beyond that vast number of advanced users is an equally large group of those who may have little or no technical knowledge. They are not sophisticated to the point that they can use current products as their predecessors did, e.g., the dial telephone versus the smartphone. This lack of understanding presents an interesting challenge to the developers of the many software applications offered to the user community today.
For example, the owner of a Brand X smartphone wishes to change someone’s home telephone number but not the mobile number in the contact list. Selecting the CONTACT icon brings the user to the contact list. He or she then pages to the particular person’s number to be changed. Selecting that picture, or icon, presents the user with a page of contact information, including the home and mobile telephone numbers as well as email and mailing addresses.
At the top of the display, the user can see two options: EDIT and MORE. From the user’s perspective, neither fits—he or she wants to CHANGE the home phone number. If the user selects EDIT, the screen looks the same, except now there is the option to EXIT or SAVE, but the user hasn’t done anything. He or she then selects the GO BACK button, returning to the first screen.
Now, the user taps MORE and arrives at a set of options ranging from DELETE to ???. He or she may reason that the number must be deleted before it can be changed. Unfortunately, if the user selects DELETE, he or she is on the verge of deleting the contact. Even the warning message “Do you want to delete this contact?” may not register with the user. If the user does choose the DELETE option, he or she now finds that the process of entering that contact needs to be restarted, hopefully with the new telephone number as well as all of the other information that had been included.
Of course, the developer may say that the user should have read the manual before attempting this action. The Brand X manual is about 300 pages in length and written to a high school graduate level of understanding and language—not a particularly good combination for the casual user.
Perhaps the most fundamental problem rests with the developer, who understands what he or she is trying to do and the method programmed to achieve a particular goal. Unfortunately, users most often will not have that level of understanding—they bring only an anticipation of success in using the particular technology. There is also some level of confidence that all possible entries have been tested during the development phase of the product, and, therefore, the product cannot perform incorrectly. That is an assumption for most products, which is more often not true. It is a difficult task to ensure that “every possible” selection has been tested. Even when the normal developer testing has been completed and some user testing done, there will be various combinations of inputs that have not been included but will often happen in the world of the using community.
A second challenge, less often encountered, is a lack of understanding on the part of the developer regarding the problem being solved. A simple example is in the conversion of temperatures from one scale to another, say degrees Celsius (°C) to degrees Fahrenheit (°F) or °F to kelvin (K). [Typically, temperatures will be in °F, °C, K, or degrees Rankin (°R)]. A typical application could output a message similar to this:
Enter temperature to be converted:
Does the developer expect a scale identifier (“F,” “C,” “K,” or “R”), or is the user to input the value to be converted? It would be better to output a message such as this:
Enter temperature scale being converted from:
Of course, then the user may input “F,” “C,” “K,” or “R,” or he or she might enter “f,” “c,” “k,” or “r,” not knowing the developer is expecting uppercase letters, not lowercase—and the program does not function as expected. Either the message to the user must be explicit, or the program should be flexible enough to accept either (and ignore any other entry from the user).
If the developer does not understand the relationships between the various scales, this could also produce invalid results. For example, when converting from °F to K, the formula is given as \[{\text{K}} = {^{\circ}}{\text{F}} + {459.67}{.}\]
If a user were to enter –460 °F, the result might be displayed as \[ ^{\circ}{\text{K}} = {-}{0.33}{.}\]
Such a result provides two incorrect identities. First, since the late 1960s, the Kelvin temperature has been designated as an absolute number, not degrees. The answer should appear as \[{\text{K}} = {-}{0.33}{.}\]
The second problem is that the Kelvin scale is also known as absolute zero; therefore, K may never be a negative number (at least in current physics definitions). This is something the developer must know and guard against, outputting a message to the user that the temperature entered in °F is not valid and cannot be lower than –459.67 (K = 0). As an aside, the Rankin scale also has this same lower limit but is expressed in degrees.
The success or acceptance of a particular application depends heavily on the knowledge and skills of the developer. While many developers get wrapped up in the nuances and elegance of an application, the developer who will most often be successful is the one who can take a step back and view the product from the user’s perspective. That does not limit the developer to elegant solutions, as long as he or she remembers that the user does not see the elegance, only the results. Testing new products for the complete and proper operation can be time-consuming and boring, but, when it is done completely and correctly, the user benefits from a truly operational application and the developer from a successful product.
Raymond E. Floyd (r.floyd@ieee.org) earned his B.S.E.E. degree from the Florida Institute of Technology, Melbourne, Florida, USA, in 1970; his M.S.E.E. degree from Florida Atlantic University, Boca Raton, Florida, USA, in 1977; and his Ph.D. degree in engineering management from California Coast University, Santa Ana, California, USA, in 2009. He spent 26 years with IBM, Armonk, New York, USA, retiring in 1992 as a senior engineer. He was programmer for more than 40 years, programming in a wide variety of languages. He was an adjunct professor for three years at Florida Atlantic University and was a visiting lecturer at Northwest College in Powell, Wyoming, 82435, USA. He was a Life Senior Member of IEEE, life senior member of the Society of Manufacturing Engineers, and member of the Society of Petroleum Engineers and the American Society for Engineering Education. He most recently coauthored a text, Perspectives on Engineering (2011); an IEEE e-book, Shaping an Engineering Career: Book 2: Dual Career Ladders (2013); and another text, So You Want To Be an Engineer? (2015). He passed away in May, 2023, after a lifetime of contributions to the field.
Digital Object Identifier 10.1109/MPOT.2019.2910303