File: METAPROD.TXT Guy Dunphy 1/Aug/97 The Software Package From Hell ------------------------------ A great deal of money is made by some companies in the software industry. Being a programmer myself, and most definately not a wealthy one, I have been attempting to identify what features of top selling software products guarantee their commercial success. My hope is that with such a list I may be able to produce such a fortune maker myself. Or perhaps, a number of us financially constrained programmers could cooperate in the writing of such a product. If Bill Gates and Microsoft can do it, why can't we? Here is my list so far. It certainly would be an interesting and useful project to blend all these features into one package; one Meta-Product. Anyone interested? Email me if you are, or you feel there are important features I've left off the list. Purpose of the package ---------------------- Its not important what it does. In fact it doesn't have to do anything useful. It only has to look impressive in the box, and mention lots of buzz-words and phrases. Like 'interoperability', 'WAN', 'home solution', etc. The box artwork must be very eye-catching and professional looking, with images of happy, shiny people at work and play. (I call these people you see on software boxes and book covers 'frunts'.) What _is_ important is that purchasers encounter such a shattering wall of incomprehensible installation and operation complexity, that they become convinced that the reason they can't get the software to do anything useful is because they are too stupid to understand it. This will cause them to recommend the package to all their friends, firstly because they will be too embarassed to admit that (a) they've been had, and (b) it demonstrated their inability to cope with computers. Secondly, when the friends buy and try the package, they will be impressed at how clever the first person was to get anywhere with it, etc. A sort of pyramid selling scheme, but dependent on pride and stupidity for success. Guaranteed to work! Plausible Denyability --------------------- Under no circumstances should anything associated with the Meta-Product ever unambiguously state what the product is _for_. Neither the printed manual(s) or the online help files should give such information. Wherever a reasonable person might look for this info (such as in 'About...' or 'Introduction...' there should be lots of info about MegaCorp itself, the company's dedication to quality, the professionalism of the production team, the product serial & version number, who the product is licenced to, where to get help with problems (the start of a long, costly and ultimately fruitless paper/phone chase), the benefits of this product versus others (unspecified), and so on. The Uses of Manuals ------------------- The printed manuals are very important to a product's success. However, their purpose is not to inform but to impress, confuse and delay the user. Firstly, its important for the manuals to demonstrate that the product is so great that it is used in every country of the world. Hence only a very small amount of the text should be in English. The rest of the very large manual (or set of manuals) should consist of the same thing repeated in very many obscure languages. Like the MS SideWinder 3D Pro joystick, which has pg 1-12 in English (much of which is copyright, EMI and RSI warnings) and pages 13-96 in other languages. Including French, German, Italian, Spanish, Suomi, Svenska and Dutch. [Joke story- "I learned 7 languages from a computer peripheral manual!"] 'Same thing repeated'? No, why should it be consistent! Better to have gross discrepancies between the different language versions. After all, any user who knows more than one language deserves to start with an extra handicap. Never include a brief list of commands and their precise syntaxes. Especially never attempt to list the classes of actions performable (with links between similar types of operations) and the commands/acts used to achieve them. After all, this would require mention of the software's purpose! Manual Confusion ---------------- Confusion is the next weapon to wield against users. To this end it is a good idea for 'the product' to actually consist of many different and independent operational components. These should all have their own cryptic names, and manuals. However, never give these components _seperate_ manuals. Instead, group the manuals randomly into larger volumes, that don't have any mention on their spines of which sub-manuals are contained in which. Naturally don't provide any overview of how the different modules interact (if in fact they do.) The larger size also makes them harder to leave open on a desk. MS Visual C++ demonstrated this beautifully. Ringbound manuals with a thick wad of errata and change-pages seperately shrinkwrapped are always a good way to add confusion to the manuals. Either the user will not bother to spend the time updating the manual (and so never be sure if what they are reading is current or true), or they will attempt the changes. If the errata sheet set is carefully planned, its possible to get quite high odds on the user totally disordering the manual pages, even (hopefully) losing some pages or whole sections. Lastly, to obstruct use of the manuals as references, before printing take the index and discard about 30% of the entries (randomly selected). Obnoxiate the Manual -------------------- To delay the user as much as possible, its important for the manuals to begin with a long and tedious first section, that does nothing to aid the user in operating the software. This is where its most appropriate to goad the user into a state of rage, that will cloud their judgement during later stages. The angrier they are during the early 'beginner' period, the more likely they will be later to feel guilty and suspect that they made stupid mistakes during the first stages - due to anger. Much of these first chapters should be in the form of a treacley 'happy families learning together at work and play with this wonderful product' storyline. See example of the Netscape Navigator V2.0 handbook: Chapter 2 'Heartwarming Introduction'. Actual subtitles from the manual: 'Hey, Ma. On to Dad. Sister. My sweetie. Who calls? Brother. Dad discovers bookmarks. My sister, my search. Ma and ftp. Brotherly morass. Pages you can write on. Speaking of goats. This sort of stuff is excruciatingly painful to read. Users are certain to skip over at least some of it. Therefore bury some really critical items of information in the depths of this too. With no reference in the index. Manual Version Ambiguous ------------------------ The actual version number of this package should never be mentioned anywhere in any printed material - neither the packaging, the manuals, on the CD, or the registration forms. If possible it should occur _only_ in a startup message that flashes briefly on the screen. Never mention in the manual which version or release date of the software the manual relates to. Especially don't put it on the spine or cover. For that matter, the spine should be entirely blank, so that it's anonymous on a shelf. If the book is thick enough to make this look odd, split it up into several smaller manuals. Definately do not have anything like "Vol 1 of 4", "Vol 2 of 4", etc on the spines to show their correct order or whether they are all present. Microsoft language compiler manuals are famous for this lack. Of course, the ultimate trick to play with manuals is to provide none at all - just an online hypertext help system. This prevents the user from ever simply reading through the information in a linear fashion, without the distractions of hopping around in a hypertext stack, dealing with other things running in the computer, and suffering eyestrain from lengthy screen reading. Hypertext puts paid to reading in bed or on the train. Confuse the version progression sequence ---------------------------------------- Never let the product go through more than 3 or 4 major version increments without radically changing its name and resetting the numeric version number. If it ever gets up to, say, 'Meta-Product Ver6', then its time to change the name to something like 'Visual Meta-Product!' with no version number at all. Obfuscate the Readme.txt file ----------------------------- If by some uncontrolled benevolent impulse, the disks or CD actually contains an 'informative text file', it should:- - Have a non-obvious filename. Like IMPLEM.INF Certainly never something that stands out or sorts to the top of the filelist, like !_FILES.DIZ - Be in some obscure format. Definately not plain ASCII 75 column text. If text must be used, ensure that CR/LF (end of line) codes are only used to mark paragraph ends. This ensures that the lines go off the screen to the right on plain text reader utilities. otherwise, it is best to use a format like HTML, Postscript, or Acrobat, that requires a special utility to read. Postscript or Acrobat are prefered, since they can mangle the text content sufficiently to prevent grep-like searches. - Not be mentioned in any printed documentation. Only those uses who actually go searching for information files should ever learn of them. - Need a viewer that is only setup as part of the main install. (and will not run unless the install was successful - ie no way.) - Within the file (at the very start) it should _insist_ that you must read the rest of the file before attempting the install, or dire consequences (unspecified) may occur. - Actually contain (vaguely) some essential 'can't do without' info re the software setup & running. Support the Legal Profession ---------------------------- Always put lengthy, boring and aggressive legal disclaimers and limitations texts at the start of any piece of text that might conceivable be useful to someone. These legal padders should always be at least two pages of fine print long. This especially applies to any 'Readme.txt' file. Outrageous Licence Agreement Clauses ------------------------------------ Always warn the purchaser that: "By opening this package you agree to be bound by the terms of the licence agreement." But best if this is found in an appendix of a manual _inside_ the package. Some paragraphs of the actual agreement:- * You agree to obey to the best of your abilities all and any directions given you by designated representatives of Mega-Corp Inc. * Failure to comply fully and promptly with such directions shall be deemed a breach of contract, and will also void your rights to retain or use the product. You will in addition incur a severe and strict penalty, the nature and duration of which shall be determined at the disgression of Mega-Corp or its representatives. * This agreement may not be enforcible in some states, where slavery is illegal. In these cases, Mega-Corp reserves the option to transport you to a location where this agreement can be complied with. See also my file 'LIC_AGRE.TXT' Voiding the warranty -------------------- If there is any hardware included, there should be some part of it that just begs to be opened, and looks very innocuous. Such as a little metal plate/flap, held with one screw (with an arrow pointing at it). When opened, some small internal part should fly off into the recesses of the room, with a p-tiiing! sound. Never to be seen again. There should be a label revealed (under the missing part) that says "Tampering with this device voids the warranty." Or: "If you are reading this, your warranty is void." Ghost utilities --------------- Some products for MS Windows install themselves totally 'into the walls' of the OS. They emplace heaps of .DLLs, .INIs, mods to main windows files, etc, but don't create any visible program item icon anywhere. Often not even any disk directory of their own. eg: The STB Velocity 3D graphics card comes with a 'Windows 3.1 MPEG driver' disk, that installs without making any 'MPEG player' tool icon. What this means is that it _forces_ you to use _it_ to view MPEGs, rather than letting you choose one viewer tool or another to select and view an MPEG file. This is the down side of file-tool associations: it lets things get automated to the point of being way out of control. Whats more, there is no easy way to delete a utility that you can't see to get a grip on (or point an uninstaller at). Not only have you no way to manipulate any controls the tool might have, but you can't even be sure whether its there or not! Let alone active/disabled. For the Meta-Product, this potential to 'install and hide' is excellent. It offers great scope for obfuscating the matter of what the product is for. Another example: a kid's 'Wonderful World of Music' CD I recently installed into Win 3.1 (which it was intended for) installed a 'Video for Windows' set of files, which _totally_ screwed up everything in Windows to do with sound or video. Even the windows 'media player' could no longer play .WAV files. Nor did the software itself work at all. I'd watched its install process rapidly emplacing at least 10 files throughout the guts of Windows, with no record kept of what and where. A simple re-install of Windows failed to fix it. Had to delete the entire D:\WIN tree, and re-install everything. Thank goodness it was was just a 'games only' machine. A good OS or utility would conform to the following simple rules. Therefore these are exactly what the Meta-Product should _not_ do:- - Remain self-contained, and removable in a single block. Effectively any complete utility should be permanently wrapped up as a single data unit. Even when loaded and running in memory. - Every identifyable code entity, either loaded, running, in standby, or static on a mass store, should _always_ have a human reachable and seperately manipulatable 'handle'. A handle may be an icon in a GUI, or a text name in a text based interface. - Just as important as a handle, is an identifyable 'excission boundary'. Software that 'blends' itself into the OS, with no easily identifyable boundary between 'self' and 'OS', is like a metastasised cancer - impossible to remove without causing gross damage to its host. Its beyond me how anyone could forget or deny this. Prevent Recycling ----------------- All paper used in the product should be the hard shiny type that can't be written on with a pencil. Especially the diskette/CD covers/labels. Any 3.5" diskettes with the product should be missing the write-enable slider tabs, so they can't easily be formatted and reused when the customer admits to themselves that they've been had, and the software is useless crap. Likewise the disk labels should be non-removable and be covered in large black type. Help That Only Pretends to be There ----------------------------------- Another good trick with online help manuals, is to have the 'Help!' button prominently displayed on screen, (for maximum warm feeling) but when the user clicks on it, they find that the actual help stack files are not provided with the purchased package. The software should then suggest that the customer download 'the latest version' (thus justifying the total absence of any help) from the producer's web/ftp site. This is especially neat if the software package is something to do with networking, and if it isn't working it stops the customer from accessing the net at all. Netscape Navigator 2 used this cool catch-22. *All* of its help text is supposed to be downloaded from Netscape's web site. FAQ files on the Internet ------------------------- The Meta-Product may have a support web site, with a FAQ (frequently Asked Questions) file. This should include several hundred typical pithy user questions - but not answer any of them. After all, this is a FAQ file. If it was a 'FAQAA' file (...And Answers) it would be called that, right? Remember above all, to never jeapardise your ability to charge $75 per technical support phone call. And receive lots of them. Required Ancilliary Software ---------------------------- There should be at least one bit of code that is needed for the Meta-Product to work, which is produced and marketed by a third party. And hence not included in the package. The existence of this, and the criticality of its presence, should be only briefly mentioned in passing. If mentioned in the index at all, it should only be in a meaningless context, such as the code's file name. Certainly not under 'Required...', or 'System Requirements..'. Nor should there be any but a very superficial and useless description of how to get it, and the relative merits of different alternatives (if any). Once again, Netscape Navigator does this, needing a winsock stack to run with Win 3.1. But it doesn't say where to get one, and naturally your browser (Netscape) isn't working... Installation ------------ Now that most PCs have CD drives it is unfortunately difficult to justify the traditional pile of 30 floppy disks required to install any 'serious' software package. Which is a pity. The floppy disk shuffle offered endless opportunity for user confusion, delay and error. The best systems required users to load floppies in random order in response to request. Sometimes the disk name requested did not correspond to the names on any of the provided floppies.