Why is this blog called SofDoc?
The short answer is that it is an acronym from the title of my dissertation, which involved the assessment of application software documentation. My principal research interest has been human factors in management information systems: managers use all sorts of information (about enterprise operations, industry competitors, and the economy) in planning and controlling enterprises, and I was interested in the usability and learnability of the technological interface (especially the software and its documentation) between managers and target information.
Jane M. Carey, an Arizona State-Phoenix professor, was the leader in a related emerging interest group among MIS academics; she organized a series of annual symposia, which I attended as a contributing participant during my last 3 years in academia. Ablex Publishing had an arrangement with Dr. Carey to publish volumes from the symposia; there was a lag between my original presentation and the publication date. When it came to the point of proofreading my latter book chapters, I formally coined the term SofDoc for a related business startup idea after leaving academia in 1991. (I had a one-year appointment as a visiting professor at Illinois State and was unable to secure a followup position in the middle of a recession.) Unfortunately, the business never got off the ground. [I did a recent Internet search to see if the term had been coincidentally, independently, or subsequently used by other parties. I believe it has been (not that surprising); please note this blog is unaffiliated with any other enterprise or product.]
What do I mean by "human factors"?
I am not referring to interpersonal relations but rather the fit of technology to the physical and cognitive characteristics of individuals performing tasks in a given enterprise context. The technology itself should be unobtrusive to the user: it's like a good waiter (the kind whom notices a coffee cup is nearly empty and knows to freshen it up without disturbing the customer) whom does not unduly distract the user in his or her performance of the task; it should be adaptable to and leverage the user's knowledge, skills, and abilities.
The basic criterion is usability: the technology interface should be efficient, effective, and satisfying in performing a task from a user perspective. I have written scholarly articles on the concept of usability, but let me explain in practical terms. By "efficient" I'm referring to the economy of relevant perceived user effort: do I have to scour through hundreds of pages of documentation or decipher cryptic syntax to figure out how to do to do something practical? Do I have to jump through a lot of obtrusive technology-oriented hoops that have little bearing on the task at hand? By "effective", I'm referring to the success of the user in dealing with the interface: was I able to accomplish the intended task? Did the information in the user manual raise more questions than answers? By "satisfying", I'm referring to the user's subjective appraisal of the interface experience: was it appropriate, professional, attractive, and easy for someone like me to use? Or did I find using the software mostly frustrating, more trouble than its worth, even if I finally managed to get it to work? Did I find the experience well worth the investment of my time and effort? Maybe even fun, cool or enjoyable to use, with unexpected benefits? Perhaps I can see using this software in other contexts, leveraging my investment in learning to use or using this tool...
The criterion learnability refers to the efficiency, effectiveness and satisfaction in learning to use the interface. An interface is learnable to the extent its use is intuitive or user past experience or knowledge (say, of interface, software or application standards) is readily applicable. Note that the concepts of learnability and usability are not necessarily the same. For example, the early word processing software Wordstar used a number of cryptic codes/keystroke combinations difficult to master but subsequently efficient to use. Generally speaking, we are aiming for an interface which the user is able to use productively in a short period of time without undue effort or extrinsic reference (e.g., to expert users or documentation).
Examples of Poor Human Factor Design
I believe that users often tolerate unusable technology design because they feel responsible for related errors (e.g., "I was trained in using the software; it's my fault"). Donald Norman, who wrote the wonderful book I often cite, The Psychology of Everyday Things, once reviewed a word processor keyboard design where the "delete document" key was position near the enter/return key. Norman questioned the vendor, whom quickly dismissed Norman's concern, noting that none of their customers had ever reported a problem; he then basically told the vendor representative to humor him and introduce him to an administrative assistant user. Norman asked her if she had ever deleted a document by accident. The assistant said, "All the time!" The astonished vendor asked why she had never reported the issue; she explained that she had been trained in using the system and figured it was her fault.
One of the key points Norman stresses is to design systems for error; even expert typists will occasionally make mistakes. One tries to design the system in such a way to minimize or eliminate error. For example, the software designer can make it difficult for users to perform risky operations like deleting key objects by requiring special procedures, hiding them, and/or designing the interface to make relevant actions more difficult to perform (e.g., by requiring special keystroke combinations or the use of obscure remotely-located keys, or adding speed bumps to the process (e.g., "are you sure (Y/N)?" with 'no' as a default)).
An example of designing error out of the interface was my recent experience with a kiosk; it required me to insert a credit/debt card; the machine would reject a card being inserted in any way except the target method.
Computer programmers can be users, too. I remember when I took my first computer programming class (FORTRAN) at OLL, we didn't even have a campus computer to process our program assignment card decks on campus (one line of code per card). There was a 3-day cycle of submitting a card deck processed at cross-town St. Mary's University and returned; this meant I had two tries to get the week's programming assignment done. Computer programming requires the development of a different skill set, and the beginning programmer goes through an error-prone learning process, not only involving rigorous language syntax but any related computer job submission procedures.
Many, if not most IT professionals know an industry saying: "is it a bug or is it a feature?" I found an interesting story behind the saying in a book from M. Lynne Markus, Systems in Organizations: Bugs and Features. The important thing for understanding this anecdote is to realize is that there should be cards at the end of deck signifying the end of the program; it's easy to see how a novice could make a mistake, even just in physically handling the card deck.
A well-known university was testing a new beta (pre-release) vendor compiler (software which takes computer program code and translates it into a binary format that machines can process); the end cards were unintentionally missing from a submitted test card deck; this resulted in catastrophic results (e.g., system memory and/or attached magnetic tape data being wiped out). The testers replicated results and reported the problem or "bug" to the vendor. ("The first computer error was caused by an insect, which was attracted to the vacuum tubes by the heat and became lodged in them, creating a short circuit. Thus, the name "bug" came to mean a computer error.") When the vendor finally released the compiler, the university testers, out of due diligence, checked to see if the vendor had corrected the reported problem and, in utter astonishment, found that it had not been fixed.
The testers then scoured through hundreds of pages of documentation, only to stumble across an item announcing that the software had come bundled with a free purge utility. Normally one would expect to pay extra for such a worthy utility if sold separately... Not only was it effective in purge operations, but it was easy to use and very EFFICIENT: i.e., it didn't even require a large program deck to work--the utility would work just as well with less than a handful of cards! Hence, the saying: "is it a bug or a feature?"
How did I become personally interested in this topic?
When I left the Navy, I was looking for work and more as an after-thought, sent a job query with my auto insurance payment. It turned out that the well-known insurance company was looking to staff an end-user APL programming team in the property-casualty actuary department.
APL ("A Programming Language") is a power interpretive (vs. compiled) computer language developed for the IBM mainframe environment, particularly useful in rapid application development. APL required a special keyboard for powerful operators. It focuses on core mathematical constructs like matrices, vectors and scalars (you can invert a matrix with a single operator), which made the language ideal for actuarial and other statistical applications. One could write code in one line that would take dozens of lines in an alternative compiled language.
The actuaries felt that their requests weren't getting high enough priority from the bureaucratic IT department and decided to establish their own division technical support team. The insurance company had largely failed in its efforts to train COBOL programmers to be APL programmers. The APL language differs in other respects from others, including the fact that the code is interpreted from right to left (something very natural to southpaws like myself). The insurance company thought with my two math degrees I would make an ideal trainee as an APL programmer/analyst. Because of the months of delay in hiring a supervisor for the end user support team, I trained myself, well enough to attract a significantly better offer from the leading APL timesharer in Houston a year later.
The APL timesharers offered an enhanced version of APL and APL programming services on their mainframe systems; they made money by selling premium-priced metered computer time (running rapidly deployed APL applications) to organizations. [The rise of microcomputers and cheap computing in the 1980's undermined the timesharing industry's business model, and the branch offices I once worked at quickly folded as I started pursuing my doctorate full-time.]
As many programmer/analysts, I didn't get to start out by writing new applications; I was often tasked fixing buggy production code. We earned revenue by the client running applications on our system; if the application had to be patched, that meant lost revenue to the company. I don't want to go into undue detail here; suffice it to say that APL programmers had their coding style preferences and criteria. (For example, a number of programmers wanted to minimize unnecessary code, and if you could reuse the same variable names or eliminate program comments to make the code leaner, so much the better! I'll never forget this one cryptic program I was debugging: the programmer had used unintuitive variable names like X, XX, XXX, etc., and I was literally having to count X's in the middle of a long line of reassigned variable names to figure out which array I was working with.) There are idiosyncratic aspects to programming in APL; for example, a certain APL operation might yield a scalar instead of the one- (or more) element vector subsequent code expected. Thus, a missing comma in the middle of a line of code several dozen characters long could result in a program blowing up.
One of my favorite APL anecdotes involves a former colleague, Jeff. He was doing his share of firefighting, fixing problems, as usual not documenting what he did. Managers of course paid lip service for the need to document, but documentation didn't bring in revenue: fixing programs did. For some reason, Jeff had to review code he had patched 2 weeks earlier; he came to me and said, "Ron, I can't remember what this code does or what I did to fix it; can you help me out?" So I translated the code in functional terms for him; I also knew Jeff's coding style, so it was easy to figure out what he had done and why.
Sometime there was documentation; my personal opinion is that managers were more interested in whether there was professionally-appearing documentation than its usefulness to the target audience. I remember that a timesharing manager proudly produced document literally yellow in age; the application bore no structural resemblance to the status quo. If and when IT professionals write documentation, it often reflects their own preferences; when I was firefighting, I wanted readable, practical, accurate, concisely stated, self-contained, well-organized information: I didn't have the time or interest in reading a novel or meaninglessly learning dozens of arcane acronyms irrelevant to the task at hand. I had my own motives for promoting quality standards, including more readable, well-commented code and practical application documentation; being a great maintenance programmer/analyst was a double-edged sword: I could only hope to advance in my career path if I groomed my successor.
Examples of Usable Application Development Experiences
I did get a few opportunities to write my own applications, and it directly bears on the software usability question. HP in the early 1980's was marketing a popular 4-color plotter. The APL timesharer I was working for had contracted with a programmer whom designed effectively a kit of cover functions for generating plots. However, the package required setting literally dozens of variables that had to be specified (no defaults to speak of) to generate even a simple plot: e.g., the type, size and spacing between tick marks, orientation of labels, the size, types, and color of characters, etc. It seems unthinkable today where most spreadsheets and presentation software provide impressive charting capabilities and there are cloud services that offer free plots with minimal inputs, but asking a user to making more than 50 decisions just to generate a plot was a nonstarter. So I was tasked to write a more usable cover function that simplified the number of decisions to a bare minimum. My design and implementation proved to be a smash success; we were marketing the plots at something like $20-25/each, and they were selling like hotcakes to our principal oil company clients.
In another case, my client worked for an Exxon real estate subsidiary located near Clear Lake City (NASA-Houston). He needed a small application to track his timesharing expenses. Like the plotter software application, the task was ill-defined. I quickly created a small application off the top of my head, and the customer seemed to like it. A few weeks later, the client called and told me he showed my app to other Exxon managers; my application had been bootlegged to over a dozen Exxon managers. In fact, the client was so impressed with my overall performance he encouraged me to start up my own company.
Miscellaneous Observations of Poor Human Factors Design
I remember doing an assignment at NASA-Clear Lake City as a government contractor (doing FORTRAN work), and I was asked, as a first-time task, to dump some programs or data off one server onto tape and load it on another system. What I recall is that the relevant documented command syntax was overly detailed, and documented examples were specialized (e.g., deferred backup scheduling to devices mounted on the server , not meat-and-potatoes uses like migrating data across servers). You first had to master the conventions of command syntax--e.g., what parts of the command were necessary, which were optional, the nature of (unintuitive) parameters, etc.--just to do a simple task.
Somewhere in my moving boxes I still have a copy of an old Commodore 64 floppy disk drive manual--which said NEVER to eject a disk with the drive GREEN light on. (The green light was the power indicator.) The user was also warned against powering the computer down with a disk in the drive. I recall I had inserted an expensive software disk in the drive and for a moment wondered about the safety of my software; I realized that it had to be typo (otherwise, the device wasn't very useful), but how did they fail to correct a crucial mistake involving the device's functionality?
I remember once doing a computer-based training assignment. (The training software was organized in chapter modules; most modules consisted of a reading assignment followed by relevant computer exercises.) One chapter consisted of a short narrative; when I paged over to the next module, I was rewarded with effusive praise on successfully completing the chapter's tasks. I went back paging back and forward, figuring somehow I had skipped past these difficult exercises; it finally dawned on me this was gratuitous programmed praise that the trainee got at the end of any exercise. It was condescending and a huge turn-off; yes, I know how to turn a page: my kindergarten teacher must be so proud!
It would be difficult to summarize all the problems I've encountered with software interfaces and documentation over the years: red lettering against black backgrounds, unintelligible or delayed error messages, redundant user entries, etc. Just to give some everyday examples: forms often unnecessarily call for city and state (given a zip code), you can't type standard abbreviations into state fields, like 'MD' for Maryland), and many country fields aren't listed in decreasing user count or population order (e.g., you may have to pan down a long list of countries to find the US in alphabetic sequence) and/or don't allow for use, say, of international calling codes. I've seen online forms where validation is not triggered at the completion of an item but when a form is formally submitted--and you are not presented with a short list of items to correct but need to scan for whatever errors occurred (you may have to search for necessary form items, say, indicated with an unimpressive asterisk, instead of a more suggestive cue (like a blinking indicator)).
Research Interests and the Reason for the Blog
Gordon B. Davis from the University of Minnesota was a key founder of the MIS academic field in business schools, and in fact wrote the classic textbook in the field; he was particularly interested in the distinction between data and (the value-added concept of) information and applied psychological considerations (including constraints, like the magical number 7). I was interested in examining the information-gathering process, through the tangible aspects of information system: the software and documentation. I was intrigued by the focus of prototyping methodology initially on core functionality and incremental design/review cycles and saw documentation as a key driver for the user experience. I also had concerns with the technical merits of various measures (e.g., computer user satisfaction) being used in the discipline.
I had written some conceptual articles about the prototyping approach and was looking for a suitable context when I came across John M. Carroll's work on minimalism, particularly the Nurnberg Funnel. Dr. Minnie Yen, a former office mate at the University of Houston and currently chair of the CIS Department at the University of Alaska-Anchorage, did her doctoral research involving SQL, the lingua franca of relational database software published by Oracle, IBM DB2, and MS SQL Server. (The University of Houston had implemented an early version of Oracle; in fact, we had the same dissertation committee chairman, whom taught the graduate database courses.)
I decided to write an unpublished minimal manual on learning SQL; basically the idea is modular self-contained chapters, written from an action perspective with practical tips and warnings on using the software. We had the relevant student subjects use a diary approach I had seen referenced elsewhere in the human factors literature to reflect their feedback in assessing the minimal manual and the relational database software. A fundamental distinction is that we were more interested in testing the usability and learnability of the manual and the software, not the students. It wasn't personal: it was business. If the student didn't have enough information to perform the task, if she had to ask Dr. Yen for assistance, if she didn't understand what I wrote, I needed to revise my manual. I already knew SQL, but I might use terminology or tacitly assume knowledge or experience that the user did not have.
This blog is a natural extension of the methodology I just described. I am writing from a perspective of both a software user (particularly from the Windows platform) and an academic. Most posts in this blog will be practical in nature. I'll never forget my first MIS professor, Al Napier, mentioned that investing hundreds or thousands of dollars in a PC for something a 99-cent recipe box does quite well is a mistake. I remember in the spring of 1991 teaching a microcomputer applications course at Illinois State and wanting students to devise projects that were personally useful. A number of students were uncomfortable with the ill-structured nature of the assignment; they were begging me to tell them what project to do. But some students were inspired. For example, I had a student from a farm whom built an application to track his farm animals' immunizations and other events.
There are a number of excellent websites reviewing software titles and cloud services; this blog is not attempting to compete with them. It's not a site intended to provide tutorials for software products. What I'll often write about are practical issues I've had to deal with (e.g., problems running Windows chkdsk that even tech support at a popular security software company couldn't resolve), my approaches to filtering and backing up emails, how I've categorized and maintained my browser bookmarks, and similar topics. These posts aren't intended to compare and contrast products, platforms, browsers, and the like; I would like to think that my practical tips can be generalized to other contexts.
