Written by David Tebbutt, Soft 09/83 - scanned
SO YOU WANT TO BE A SOFTWARE WRITER?
Some program authors set out to give their users good value for money. Others prefer a 'quick and dirty approach which gets the product to market as speedily as possible. Either approach has its merits - ie. the balance is between a good reputation and rapid income. Since almost anything will sell given sufficient advertising hype, you really do have a choice. Just like a book author, you can be remembered as a good writer or as someone who made a lot of money churning out trash. You need to make this decision early on in your product development cycle so that your efforts are given the correct focus.
I have written this article with 'quality' authors in mind. No doubt the 'quick and dirty' brigade will find some of the observations rather quaint. Like this one for example: The most important person in the world to the serious programmer is the end user. Why not try to imagine the user looking over your shoulder as you make each of the hundreds of design decisions involved in the development of a program? This way the usability becomes an inherent part of the product rather than an afterthought, which it so often is.
Taking the four main application areas - learning, leisure, work and system development - you will find that some users are more demanding than others. For example a businessman will want something usable and reliable whereas a game player will be after something exciting and probably not mind the occasional crash. Educational programs will need a sound psychological basis as opposed to system developers who will quite often trade psychology off against useful facilities. The important thing is to bear in mind the different requirements of each application while at the same time remembering that users themselves differ according to their own experiences. It is important to aim your product at the lowest common denominator of your target audience. One way of doing this would be to offer different levels of 'help' screen. Another would be to have tutorial documentation designed to bring all users to the same standard before they start using the system in earnest.
PROGRAMS
One of the buzz words doing the rounds is 'intuitive'. Intuitive programs are those which can be used without the need to refer to a manual. A user should 'know' what to do next either because it's the way he works normally or because the program has been structured in a very obvious way. The more intuitive a program is, the more points is scores with users. I use a wordprocessor called Spellbinder and most of that it intuitive. If I want to go to the top of my document I type 't', to go to the end I type 'e', to hold stuff in a buffer I type 'h' while read and write are activated by 'r' end 'w' commands. Programs need to be structured and sequenced in the way a user thinks. I was evaluating a program recently which asked the user to define the number of characters in a record before it had asked for the individual fields and their contents. Most people just don't think that way round. The ultimate in intuitive user images is the Xerox Stor software and its relatives. This displays pictures called icons, of the various elements in an average office filing cabinets diaries, folders, memo pads in and out trays calculators and so on. The user simply uses a point device to choose the icon for the activity to be performed. If, for example, you chose a folder then you would get a display of the title pages of all the documents in the folder. Choose the appropriate one and the contents would be made available for editing. Choose a floppy disk icon and the changed contents will be stored on your local floppy drive.
This is the way the business market seems to be moving and we must either join in eventually or find less demanding niches for our products. For the next several years, we will still be able to address the base of users who bought 'old-fashioned' machines with twin floppy-disk drives and a Z80, 6502 or 8088 processor As graphics resolution rises and the prices of memory and disks fall then business software writers will find themselves in an increasingly 'Lisalike' world.
I can think of all sorts of ways in which a similar approach would work for educational programs and system development tools. Games programs, however, are in a class of their own. The good ones have certain characteristics in common. They have to involve the user. Passive games just do not work. The first program I ever wrote in Basic emulated a fruit machine. It drew a nice picture of the machine, showed the fruits whizzing round and even showed money tumbling out after a win. After spending a couple of days perfecting the program, I couldn't immediately see why it was so stupefyingly boring. There are many answers of course but the main ones were that I wasn't required to do anything demanding, the machine did all the work. I was limited to choosing my stake and deciding which fruits to hold. There was no excitement, variety or suspense. In fact it was rubbish, despite the lovely graphics. Like so many programmers I got hooked on the technical problems and became oblivious to the user's needs This is a danger in all programming but I suspect that it's even 2 more common in games. After working so hard on the details it just seems so unfair that no-one's interested in the end result.
Several types of game have met with great success and unlike business programs, there seems to be an insatiable demand for variations on the same basic themes. For example, there are endless versions of the classic adventure game which gives the programmer the opportunity to play God. He has to create a world, populate it and provide artifacts for use by its population. The user has to navigate this world in the search for something, a pot of gold perhaps, but on the way he has to deal with all the odd characters encountered. Riddles have to be solved, duels fought and mazes fathomed out. Such games offer limitless opportunity for software authors. Good graphics move the game up in the user's estimation, although too many of them on today's fairly slow machines tend to irritate after a while. Chase games are popular too and I must confess to a soft spot for Psion's Horace because he was the first game character that I got to actually like.
The games are not particularly original in concept although in execution they are quite unique. The selling point is Horace himself, I think The speed of execution, simplicity of the controls, quality of the graphics and excitement of going further into the game are what makes this type of game so popular. Sound effects are necessary to create a sense of urgency and to give rewards. For example, Hungry Horace involves a bell tolling continuously, a 'bloop' when he eats the parky's lunch and a crashing noise when the parky catches him. We live in a noisy world and silence would seem to be the wrong accompaniment for fast moving action games.
Traditional games are always good for sales but you will have to go some to find one that hasn't been tackled. Ever better chess games will sell to existing users although I rather doubt that you will make your mark with a better game of awari. These games succeed for the same reasons that their pasteboard counterparts succeed. It is important to offer levels of play, at least one of which will let the user beat the computer. The other important thing is clear graphics and simple operating instructions.
Atari really scored with its Star Raiders game. This made the TV screen appear to be the forward porthole in a space ship. Joystick controls made this one of the most exciting computer games I have ever played. The user is responsible for the direction of the ship, its fuel, its speed, use of missiles, control of docking with the mother ship and so on. There is plenty to do, plenty of decisions to make and all the time the player is under threat from raiders who can attack at any time with little warning. It is a very realistic game and the outstanding feature is that you are actually there inside the game. This is a rare achievement indeed. I suspect that the Microsoft flight simulator is in the same category but I've not tried that yet.
These examples give you an idea of what constitutes a good game. If I were to summarise the key features they would be: Users active participation, a physical or mental challenge, simple rules, room to grow as you become more skilled, occasional suspense and a random element so that next time you play, things work out differently. Other features worth including are a 'freeze' key to stop play if you need to answer the door or go to the bathroom and a 'save' command which saves the frozen game for use later on.
Educational programs need to be carefully thought out if they're not going to do more harm than good. If you've got such a program in mind, you must already have the knowledge of how to teach the subject manually, so to speak. The program should be totally robust and not fall over under any user-induced circumstances. If a program is to teach someone something then it is as important to build trust between the user and the program as it is to do the same between a student and a real teacher. The sequence of an instructional program must be logical, building on concepts developed earlier in the program. The user needs to be able to start learning at any point because earlier lessons may have already been covered.
I looked at a number of educational packages last year and felt that the best ones were those which took particular advantage of computer features. The ability to time the student during tests is particularly useful and it means that students can go at their own pace, testing themselves whenever they feel they've made sufficient progress. See if you can introduce an extra dimension into a training package which provides a sort of 'spin off' benefit. One of the typing tutors also introduces the user to the 1000 most common English words. This seems such a sensible idea that it seems odd that no-one has thought of it before. Imagine the publisher's surprise when Scandinavian and Dutch companies expressed interest because of this extra learning dimension. A lot of programmers try to automate existing teaching methods and courses. If you are planning to do this, you need to bear in mind that if a conventional method is boring then its computerised counterpart will be equally boring. It's rather like companies with messy accounting buying computers. All they do is speed up the mess.
Business programs so far have pretty well emulated conventional ways of working. Word processors aren't that different from typewriters, spreadsheets look like accountants' working papers and databases could be likened to card index systems or paper files. It makes sense to let the user feel he is on familiar ground. If the screen or the printouts look like things he's used to then he is more likely to buy the product. That's not to say that the operation of the program needs to resemble his manual approach. In fact database programs are capable of retrieving and manipulating information in ways that most users find quite astonishing. The spreadsheets take the tedium out of 'what-if' questions, many of which the accountant wouldn't dream of calculating in the old pencil and paper days. Word processors bring all sorts of time-saving commands such as the global replacement of misspelled words.
Preparing a business program is a bit like teaching. You take people from the known and familiar to the new and unfamiliar. Make sure that programs are easy to use and backed up with good documentation which covers every possible circumstance they may find themselves in. Drive the program by menus if you like but if you do, try and make the selection by cursor movement to the appropriate command or, failing that, try the initial letter of the function required. I was using a package recently which asked me to key '0 for l', '1 for l.5' and '2 for 2'. I also had to key '5 to exit'. Where's the sense of that? The machine had direct cursor addressing and the program was dedicated to that machine. Surely they could have done better.
You need to make sure that the program won't bomb if the printer is switched off or if the disk directory fills up. These things aren't difficult, they just require thought at the design stage. One chap I know [Mike Liardet actually] sends a message to the screen PRINTER NOT SWITCHED ON as soon as a print command is issued. He then sends a single non-printing character to the printer. His next instruction clears the screen message. The result is that if all goes well, the screen message appears and disappears in the twinkling of an eye but if the printer isn't working, the system hangs while waiting to send the non- printing character and the warning is still there on the screen. Thoughtfulness like that is what distinguishes the excellent from the merely good. All illegal keyboard operations must be trapped. The exception to that is the RESET key which, fortunately, is becoming something of a rare beast on the normal keyboard these days. If it is possible for someone to cause havoc by unplugging the system, hitting RESET or removing disks prematurely then you should consider the possibility of providing recovery facilities to unravel messed up files.
Systems developers like to use products that work. The more useful functions in them the better. You are a systems developer so you know exactly what you expect of such a product. By and large these people are the most forgiving users although this doesn't mean that you shouldn't do the best job you can for them. After all, if you don't then someone else may come along with a computing product and, because it's easier to use, capture the market which you just lost because of your own laziness. The same sort of criteria apply to systems developers as to business users. The only difference is that system developers are much more familiar with computers so your messages don't need to be quite so noddy.
Once you have a working version of your product, you should try it out on a few typical users. Try and explain the program entirely in terms of what they will see on the screen. The thing to avoid is that of explaining how it works or your own conceptual understanding of the product since this will colour their feedback to you. Even if a sequence is strictly logical, it doesn't necessarily follow that the user will want to use it in its 'pure' form. I know a product fairly intimately which asks you to type two letters to quit. This instruction is entirely consistent with all other instructions at that level but even now, after using it daily for over a year I still want to hit ESCAPE followed by 'Q', because this sequence is used elsewhere in the program. The author argued for logical consistency and I backed him up. The truth is that while the logic is impeccable, users just don't work that way. So be prepared for a few surprises in the feedback. If enough people make the same comments you should forgo a little perfection After all, 'the customer is always right'.
DOCUMENTATION
This varies with the type and price of a product from the minimal cassette sleeve to the full blown 3-ring binders plus reference cards. Once again the answer can be found by studying the users. It is your job to make them skilled users of all the functions in your software package. Assumptions are always dangerous but you may like to assume that they can operate their computer. You may prefer not to and assume that they've carried your program home under one arm and the computer under another. If you've got software publisher then it may make the decision for you and, with a bit of luck, write the documentations as well. I'm ignoring games in this section. Most of them simply require a description of the rules and notes about implementation on different machine versions.
An introduction to the application and how your package handles it is essential. This need only be in outline since the operating instructions will cover the details later on. Depending on the package, you may care to introduce a simple worked example at this stage. Programs which run on a variety of machines usually need to be configured to take advantage of the user's equipment so a section on getting going is needed. This may include homilie on handling disks, copying the master disk, configuration restrictions and anything else you feel the user needs to know about running your package on his machine. The user will then want to know how to run the application and a comprehensive worked example is one of the best ways of introducing its various features. As you introduce each new aspect of the package, describe the theory underpinning it. Aim to have the user fully conversant with the package by the end of this section. A separate reference chapter which summarises the theory is useful for the user who is confident enough to skip the worked example or who simply needs a reminder of some forgotten feature. A message section should cover every possible untoward message which may occur. Please put them in alphabetical order, some manuals don't. Security and recovery ought to be covered somewhere just to make sure the user knows the consequences of disk corruption or power failures. Tell him how to back up the data disks and, if appropriate, how to recover valid data from a suspect file. If you need to give the user technical information which might impede his progress through other parts of the manual then stick it in an appendix. It is vital that you create an index to the manual. If you've ever tried to find information in an unindexed manual, then you'll know how frustrating it can be.
As far as style is concerned, you should try to make your writing friendly and positive. Avoid passive sentences such as 'the return key should now be pressed'. Say 'PRESS (RETURN)'. It makes life a lot easier for the user and cuts down on printing bills too. Write at the same level as the daily paper or the Readers Digest or, dare I say it, this article. Keep sentences and paragraphs short and use plenty of illustrations [screens usually] so that the users know they're on the right track. When you've finished the manual give it and the program to a typical user and see how they get on with it. Don't rely on someone who has already used the package. Listen to the feedback and act on it. If you are submitting the documentation to a software publisher for editing and printing then it will probably need to be double spaced. Some publishers will accept documentation on a disk.
Although this isn't strictly documentation, you may consider a series of help screens which the user can call up while running the program. As time passes and disk and memory capacities increase, this will be less of a problem to implement. Right now you may find that you are restricted in the amount of help you can provide in this way. The final document you may consider is a quick reference card which covers all the key aspects of your program.
OTHER RESPONSIBILITIES
You must, of course, fix all bugs as soon as they are found. You should aim to release a bug free product but as I mentioned in an earlier article, this can be achieved for 99 percent of users but there's always going to be someone who does something weird and makes the program fall over. Once the product is on the road then your users must be supported. If you are publishing the product yourself then you must ensure that a hot line is manned during normal working hours. At worst you need an answerphone to take messages in your absence. If you are selling through a publisher then it will take the responsibility for support and only come to you when stuck. If a serious bug is discovered then it must be fixed within a couple of days. Minor ones may take longer. Serious bugs at this stage of the game are a publishers nightmare because all existing copies of the product will need to be replaced, a costly exercise compared with seeking out the bugs during testing. It is important that you keep program source documentation up to date and that it is clearly structured and well commented. If not, then you will have to re-learn the package every time you have to analyse a problem or correct an error. Do bear such maintenance activities in mind when writing the program in the first place. You should also bear in mind that you may not always be around to fix things Your code and its supporting documentation should be in a form which would allow other programmers to support the product.
Opportunities will arise to transfer your program to other machines. As its reputation spreads you may find manufacturers coming to you or your publisher prior to the announcement of a new machine. If you want to maximise your income from a product then you should mentally budget for such adaptations. Of course, if you're smart you will have written your program in C or some other similarly portable language. After six months or so, you will find that you have built up quite a body of knowledge about the user's view of your product. You may, in the light of this, want to bring out a new and hopefully final version. Another way of tackling this would be to come out with new products which dovetail into your original. This second option is less tidy than the first but it has an advantage in that you can sell to the original user base and they won't feel you've done the dirty on them.
FINALLY
Opportunities abound for good programmers with original ideas. I firmly believe that Britain is uniquely equipped to take advantage of this growth in personal computers by becoming a key software centre. British brains are a renewable national resource and their products can stimulate a significant inflow of cash to these islands and into your pockets in the form of royalty payments. If you've got an original idea for a mass market software product then you will regret if for the rest of your life if you don't get it published. Go on, give it a try.