TweetFollow Us on Twitter

Writing A ReadMe File

Volume Number: 14 (1998)
Issue Number: 10
Column Tag: Electronic Documentation

Writing a ReadMe File? Read This

by Tonya Engst

A member of the Macintosh press tells all. Learn about the link between a ReadMe file and press coverage, plus discover the secrets of a great ReadMe file

ReadMe First!

Nobody expects to find great literature in a ReadMe file, and that's good news for busy developers writing ReadMe files for their software. There's no need to consider the symbolism behind RAM requirements or make metaphors out of multiple minor updates. Even so, taking the time to construct an informative, user-friendly ReadMe file will create satisfied, paying customers; win you friends; and even help turn the limelight of press coverage in your direction.

Although plenty of products have wonderful ReadMe files, over the years, I've encountered a disturbing number of ReadMe files that practically cripple their products through inattention to detail or random organization. Sometimes a bad ReadMe file causes my attention to wander so I never get around to trying its associated software; other times, I'm writing about software for publication and the more time I spend chasing down basic information about the software (for instance, how much it costs), the less time I have to appreciate the good qualities of the program and expound on them in print.

In this article, I'll look at what information to put into a ReadMe file, offer a sample ReadMe file outline, talk about file types, and give tips for polishing writing quickly. The article ends with a checklist: if a ReadMe file meets the criteria in the checklist, it's ready to ship.

Just The Facts Ma'am

Whether a product is distributed electronically or in shrink-wrap, a good ReadMe file concentrates on basic, vital facts: Where does this come from? When was it made? What is it? Why should I use it? How do I use it?

Daddy, Where Does Software Come From?

This part is easy. In the ReadMe file, type your complete contact information, or at least all the information that you want to share. Consider reasons why people might want to reach you: feature suggestions, bug reports, questions, payments, and even flattering comments. Users will look for contact information in order to send payments or ask questions (often users will have a question or two that needs answering before they're willing to pay for shareware), and journalists reporting on your software will look to the for contact information to include in their articles. I've actually had to scratch covering products because I could not locate contact information before a deadline. Here's an example of how to do it right:

Contact us at:
Joe-Bob's Software Mill
http://joe.bob-soft.com/
joe@bob-soft.com (sales, distribution requests, administration)
support@bob-soft.com (bugs, problems, questions)
800/555-1212 (M-F, 9 AM-4 PM PST)

When?

This key piece of data is so small that it's easy to overlook. Nevertheless, be sure to date the ReadMe file. It's a polite way to help people place the era in which your software shipped. For instance, if I see a ReadMe file dated from 1992, I'll be much more forgiving of a lack of Web URL or current contact information. I'll be more cautious about installing it on an up-to-date system, and I'll cruise the net to check for a later version.

What is It?

A good ReadMe files tells what the software is named, what its version number is (rank and serial number are optional), what it costs, and what it does. Provide these details and you make many people happy - users can figure out what to expect from the software, those who run download sites can categorize it rapidly, and members of the press can wrap their minds around it does quickly.

You'd think that writing the name and version number of software would be simple, but some ReadMe authors slip up and don't consistently give the same name throughout the file. Though most users won't care, it looks unprofessional and makes journalists grumpy because they then must figure out which spelling you meant. In particular, watch out for spacing and capitalization - screenCruiser isn't the same as Screen Cruiser. (While you're at it, make sure the name is also the same in the software's Get Info box and Finder icon name.)

If you sell the software as shareware, postcardware, donationware, or the like, tell people about it up front. And, if your software is freeware, mention that as well. I prefer that pricing information be given in a clear, business-like fashion, without long-winded discussions about ethics. Be sure to tell people exactly what to pay and how. (As an aside, for shareware consider using a credit card handling service for payments; typically such services make it significantly simpler to pay and thus increase the number of registrations. They also decrease the amount of time you spend bookkeeping.)

If you sell the software in shrink-wrap, you can probably skip the price (though if the ReadMe file in question goes with a free update, do clarify that the update is free). I strongly recommend providing a pointer to pricing and sales information, by phone and Internet. You never know when someone will want to order more copies or when a pirate will want to come clean. Further, you'll make software reviewers happy, since they often write about software at weird hours when phones are not staffed.

Once you jump the hurdles of name and price, your next concern is an "elevator statement," a short, compelling description that can be rattled off in the time it takes an elevator to climb from the ground floor to the penthouse (that's all the time you may have to sell your software to the busy person who works in the penthouse suite). Writing a short description is easy: "it changes the desktop pattern," or "it's a database of amusement park rides." The compelling part is harder because it identifies what makes your software special. A full elevator statement might be, "it monitors a user's actions to figure out her mood, and then changes the desktop pattern to match," or "it's a database of amusement park rides with ride ratings from Macintosh programmers."

Why Bother?

The elevator statement acts as a hook that catches interested users, but to reel them in, you must give more details. You don't have to write an essay - all you need is a paragraph or so that backs up the elevator statement with more information. Why did you bother to code the software? Why should potential users bother to install and launch it? What unique features does it bring to the table? In particular, be sure to mention the unique features, especially if your product resembles others in its category. For example, Jerry Åman from Optima System wrote in the MailSpinner 1.2 ReadMe file, "This folder contains a kit with an AppleScript and templates that show how all mail in an Eudora or Emailer mailbox can published on the Web using PageSpinner. This kit can be useful if you run a small mailing list and you need to publish mails on the Web or you want to maintain a simple guest book at your site."

If your software only serves one simple function, you don't need much more than a slightly elaborated elevator statement; however, if your software has a number of capabilities, list them, perhaps in a bulleted list. That way, users can quickly get a broad picture of the features.

Also, when releasing an update, give the scoop on what's new in it. Some ReadMe files even include complete version histories, which is fine, though I recommend relegating version histories to the bottom of a ReadMe file or even to another document since they serve more as reference material than as newsworthy information.

Help Users Jump the Learning Curve

Pushing users up the learning curve goes a long way toward creating happy users. Every product should ship with fundamental information like system requirements, major conflicts, and what files get placed where by your installer. Often, the ReadMe file is a good place for that information.

At times, the ReadMe file is the perfect location for installation directions. If files need to be located specifically inside certain folders, say so. If the software only works in tandem with a particular system component, mention it.

In some cases, it makes sense to put basic documentation in the ReadMe file. In particular, give readers the benefit of your experience with the software - tell them about special keyboard shortcuts, unique preferences, and smart techniques for working efficiently.

Outlining the Facts

Writing the basic facts is a good start for a ReadMe file, but the text will be more user-friendly if you arrange the facts in logical order. Of course, there are many different ways to accomplish this, but here's a sample outline that should be a handy starting point for most ReadMe files. In the sample, in some cases, the headings correspond to topics that could be quite long, such as documentation and version history. For many ReadMe files it won't make sense to include these long sections; however, in any ReadMe file you can refer readers to other documents, such as a separate version history file or the printed manual.

Product name and version number
Company name
Elevator statement
New and special in this release
Hardware and software requirements
Installation instructions, getting started tips, and documentation
Important known problems
Version history
Pricing information
Contact information
Date or copyright date, and other legal information

Be a Pro

In addition to creating a ReadMe file's content, it's important to make the content look good and read smoothly.

The Argument for SimpleText

When it comes to ReadMe files, content is king, and it takes precedence over looks and glamour. To ensure readability, I suggest using SimpleText as a file format. SimpleText may be dull, but it's also universal. In addition, SimpleText has an easy user interface - users navigate simply by using the scroll bar or the keyboard, without having to master a special user interface. Also, anything but text makes people like download-site administrators crazy because these people often must extract the text for use on their systems.

HTML in particular seems a likely possibility as a SimpleText alternative, and until yesterday, I hadn't decided whether to recommend HTML as an alternative format for ReadMe files - most people have Web browsers, and I find the capability to link a ReadMe file to pages on the Web fairly compelling. Yesterday, however, I downloaded the version 1.2 update to Macromedia Dreamweaver, a high-end Web authoring program. In the update's ReadMe file, I found a lesson in how not to do a ReadMe file in HTML.

My first stumbling block came when I blithely double-clicked the ReadMe file's icon before realizing that I'd have to wait for Navigator to launch (right now, I use Internet Explorer as my primary browser). The second stumbling block, however, was far more annoying. The ReadMe file itself lacked almost all information normally found in a ReadMe file and instead linked to Macromedia's Web site. To view the release notes, feature overview, FAQ, and so on, I had to go out on the Internet and wait for Web pages to load. And, to learn some details, I had to hunt around on Macromedia's Web site. The ReadMe file had been created for Macromedia's convenience, not mine. Unless Macromedia updates the ReadMe file, you can view it as I saw it at http://www.macromedia.com/support/dreamweaver/releasenotes/dw1_2_readme.html.

Despite this recent bad experience with an HTML-based ReadMe file, I think HTML-formatted ReadMe files can work well if they provide all the important core details and then use links to give fast access to related information, such as extended documentation or an online order form. Without providing substantively useful links to extended information, though, I can't see much point in doing a ReadMe file in HTML, since SimpleText works better for presenting local information.

ReadMe files come in plenty of other double-clickable formats, but they all require more brain cycles from busy readers than a SimpleText file. A software update or shareware program may only get 30 seconds of attention from users cruising software archives or reviewers checking out all the applications in a category, so to attract attention you must make opening the ReadMe file take only a fraction of those 30 seconds. For serious commercial software, you'll receive more than 30 seconds of attention, but you'll make people's lives easier if you distribute ReadMe files in a format that's easily accessible.

SimpleText Authoring

If you've never delved into hard-core SimpleText authoring and want pointers on using ResEdit to incorporate styled text or graphics into a SimpleText file, read the Apple Developer Technical Support Technote 1005, "The Compleat Guide to SimpleText," by Bryan Stearns and revised by Mark Cookson The Technote has general tips for ReadMe authors and lots of detailed information about adding graphics and movies to SimpleText document. http://developer.apple.com/technotes/tn/tn1005.html.

Many of my programmer friends, however, do not recommend SimpleText as an authoring environment; instead, they use a word processor like ClarisWorks with an XTND translator that converts the file into SimpleText format.

Users like unlocked ReadMe files because it's easy to grab URLs and email addresses from them. As a software reviewer, I love them because I would far rather copy contact information than retype it - copying is faster and reduces errors. Although I acknowledge that people can easily alter an unlocked SimpleText document without your permission, an unlocked ReadMe file will also make you many friends.

Unfortunately, as the Technote 1005 confirms, unlocked SimpleText documents experience buggy behavior if they include graphics. I'd much rather be able to copy text from a ReadMe file and have URLs potentially be live (through ICeTee, for instance) than be able to see a screen shot.

The Naming Game

Naming a ReadMe file is much easier than naming a pet. Simply make the name descriptive and include the name of the product. I recommend putting the product name first so the ReadMe file can sort by product name within a Finder window. Examples of good names include: ScreenCruiser: Read Me First!, RideRater-ReadMe, and Mood Scanner Users Read Me. Avoid non-descriptive names like ReadMe and ReadMe First! Additionally, unless you are in grade school, skip overly enthusiastic names like README!!!!!!

Letting It All Lay Out

Layout and fonts also play a role in creating a ReadMe file. The point of a ReadMe file is to present textual information, so it's terrifically important to use fonts that read nicely onscreen. I recommend tried-and-true screen fonts like Geneva and New York; other commonly installed fonts include Chicago, Helvetica, Monaco, and Times. Above all else, resist the temptation to use a font size that looks good when printed but tiny onscreen (never use type smaller than 12-point). If you ship a ReadMe file in read-only format, it's particularly discourteous to use a small font size. Similarly, italic text is hard to read onscreen and is best avoided.

Beyond font choice, SimpleText doesn't offer much in the way of layout options, but when in doubt, I suggest following the advice of Macintosh layout expert Robin Williams. In the excellent The Non-Designer's Design Book, (Peachpit Press, 1-56609-159-4), Robin points out four principles of design: proximity, alignment, repetition, and contrast. In essence, information should be positioned near like information (i.e. put all contact information in the same place); chunks of information shouldn't be splatted down randomly, but instead should be placed next to one another in a logical manner; items like big headlines should repeat in a consistent manner with regard to their styles and the white space surrounding them; and you can add visual excitement by using layout elements that contrast (in a ReadMe file this might amount to using contrasting text styles for heading and body text).

Seven Steps to Writing Success

The most important aspect of a ReadMe file is the text it contains, and the quality of the writing counts. Because casual writers often compose ReadMe files, I submit to you seven quick tricks for taking any piece of ReadMe file writing and making it read more like it was written by a professional:

  1. When referring to a command or dialog box, spell it exactly as it appears in the program. (Optional points - contemplate why software reviewers love dialog boxes that stick around when the reviewers switch out of the software to a word processor.)
  2. When referring to a menu command, don't use quotation marks and mention the menu in case readers don't know which one to use.
    • Do: Choose Arrange All from the Window menu
    • Don't: Use the 'arrange' command on the 'window' menu.
    • Do: From the Special menu's hierarchical Find menu, choose Search.
    • Don't: Pop up the "Find" menu and click the command for searching again.
  3. Remove these words and phrases: "actually," "a lot," "very," "really," and "just." By and large, your writing will be far stronger if you take them out.
  4. This step is hard, so skip it if you don't have time. Look for instances of the passive voice (sentences containing words like "is," and "are") and try to rewrite at least half the sentence so the "is" or "are" disappears. Generally, avoiding the passive voice makes your writing more precise, more understandable, and more powerful.
  5. Use a spell checker.
  6. Read the ReadMe file out loud. If you make changes based on what you hear, run the spell checker again.
  7. If the ReadMe is written in a language that is not your primary language, consider having a native speaker tweak it. If that's not possible, make it clear through your contact information or a short note that you did your best. Most people will forgive errors once they understand the cause.

If you truly can't justify the time it takes to polish the writing in a ReadMe file, I recommend acknowledging bluntly that you didn't think it was worth the effort. For example, the IMPORTANT README that comes with IADD 0.0.2 modeled itself after a FAQ (a format that, in fact, works rather well). Here's an excerpt:

Did you do a lot of testing on this? No, This took about 3 hours to make and has been tested for about 15 minutes. It seems to work.

How much memory does it use? I'm not sure, but I would guess around 5K.

How much does this cost? $0.00 (It is free.)

Didn't you proofread this document? No, I didn't. I made it in SimpleText and did not proofread it. If you find a mistake that really bothers you, let me know.

ReadMe Checklist

Creating a great ReadMe file requires far more perspiration than talent. Here's a checklist to sweat over as you finish a ReadMe file; if the document meets the requirements on this list, it's probably ready to ship.

  • The ReadMe file makes it a complete no-brainer to figure out your company's name (or the programmer's name), the application's name, and the version number.
  • The ReadMe file includes the release date of the software.
  • The ReadMe file contains reasonably complete contact information.
  • Readers of the file can easily determine pricing information (for some commercial software, this criteria isn't necessary, but for shareware it's terrifically important).
  • The first screen of the document has a description of what the software is and why it's cool.
  • The ReadMe file mentions new features in this particular release of the program.
  • The ReadMe file notes system and hardware requirements for the software.
  • The ReadMe file contains installation instructions, tips and tricks, documentation, and a version history (or if it doesn't, it refers readers to other documents that do contain this information).
  • The application's name is spelled consistently throughout the ReadMe file (make sure you have also spelled the company name consistently).
  • The file format is SimpleText (or, if not, you have a good reason for using something else).
  • If feasible, the document is unlocked so that readers can freely copy information and access URLs.
  • The file's name is descriptive (ReadMe alone is not sufficiently descriptive).
  • The font styles and overall layout are appropriate for onscreen reading.
  • You have followed the seven steps to writing success outlined in this article.

ReadMe Last

Writing a good ReadMe file shouldn't be a back breaking task, and I hope this article has given you ideas for improving your next ReadMe, or even given you tools in the form of the suggested outline, seven steps to writing success, and shipping checklist. If you remember nothing else from this article, I hope you'll remember that for a ReadMe file, content truly is king - provide good information in a useful format and you'll not only make friends, you'll also gain paying customers and be more likely to receive favorable press coverage.

Bibliography and References

  • Williams, Robin The Non-Designers Design Book, Peachpit Press. Berkeley, 1994.

A freelance writer and Macintosh enthusiast, Tonya Engst is best known for her work on TidBITS, an electronic newsletter centering on the Macintosh Internet community. She has been reviewing Macintosh software since 1990, often under tight deadlines, and has strong opinions about what constitutes a useful ReadMe file. Tonya holds a degree in communications from Cornell University. Her home page is at: http://www.tidbits.com/tonya/.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

Latest Forum Discussions

See All

Fresh From the Land Down Under – The Tou...
After a two week hiatus, we are back with another episode of The TouchArcade Show. Eli is fresh off his trip to Australia, which according to him is very similar to America but more upside down. Also kangaroos all over. Other topics this week... | Read more »
TouchArcade Game of the Week: ‘Dungeon T...
I’m a little conflicted on this week’s pick. Pretty much everyone knows the legend of Dungeon Raid, the match-3 RPG hybrid that took the world by storm way back in 2011. Everyone at the time was obsessed with it, but for whatever reason the... | Read more »
SwitchArcade Round-Up: Reviews Featuring...
Hello gentle readers, and welcome to the SwitchArcade Round-Up for July 19th, 2024. In today’s article, we finish up the week with the unusual appearance of a review. I’ve spent my time with Hot Lap Racing, and I’m ready to give my verdict. After... | Read more »
Draknek Interview: Alan Hazelden on Thin...
Ever since I played my first release from Draknek & Friends years ago, I knew I wanted to sit down with Alan Hazelden and chat about the team, puzzle games, and much more. | Read more »
The Latest ‘Marvel Snap’ OTA Update Buff...
I don’t know about all of you, my fellow Marvel Snap (Free) players, but these days when I see a balance update I find myself clenching my… teeth and bracing for the impact to my decks. They’ve been pretty spicy of late, after all. How will the... | Read more »
‘Honkai Star Rail’ Version 2.4 “Finest D...
HoYoverse just announced the Honkai Star Rail (Free) version 2.4 “Finest Duel Under the Pristine Blue" update alongside a surprising collaboration. Honkai Star Rail 2.4 follows the 2.3 “Farewell, Penacony" update. Read about that here. | Read more »
‘Vampire Survivors+’ on Apple Arcade Wil...
Earlier this month, Apple revealed that poncle’s excellent Vampire Survivors+ () would be heading to Apple Arcade as a new App Store Great. I reached out to poncle to check in on the DLC for Vampire Survivors+ because only the first two DLCs were... | Read more »
Homerun Clash 2: Legends Derby opens for...
Since launching in 2018, Homerun Clash has performed admirably for HAEGIN, racking up 12 million players all eager to prove they could be the next baseball champions. Well, the title will soon be up for grabs again, as Homerun Clash 2: Legends... | Read more »
‘Neverness to Everness’ Is a Free To Pla...
Perfect World Games and Hotta Studio (Tower of Fantasy) announced a new free to play open world RPG in the form of Neverness to Everness a few days ago (via Gematsu). Neverness to Everness has an urban setting, and the two reveal trailers for it... | Read more »
Meditative Puzzler ‘Ouros’ Coming to iOS...
Ouros is a mediative puzzle game from developer Michael Kamm that launched on PC just a couple of months back, and today it has been revealed that the title is now heading to iOS and Android devices next month. Which is good news I say because this... | Read more »

Price Scanner via MacPrices.net

Amazon is still selling 16-inch MacBook Pros...
Prime Day in July is over, but Amazon is still selling 16-inch Apple MacBook Pros for $500-$600 off MSRP. Shipping is free. These are the lowest prices available this weekend for new 16″ Apple... Read more
Walmart continues to sell clearance 13-inch M...
Walmart continues to offer clearance, but new, Apple 13″ M1 MacBook Airs (8GB RAM, 256GB SSD) online for $699, $300 off original MSRP, in Space Gray, Silver, and Gold colors. These are new MacBooks... Read more
Apple is offering steep discounts, up to $600...
Apple has standard-configuration 16″ M3 Max MacBook Pros available, Certified Refurbished, starting at $2969 and ranging up to $600 off MSRP. Each model features a new outer case, shipping is free,... Read more
Save up to $480 with these 14-inch M3 Pro/M3...
Apple has 14″ M3 Pro and M3 Max MacBook Pros in stock today and available, Certified Refurbished, starting at $1699 and ranging up to $480 off MSRP. Each model features a new outer case, shipping is... Read more
Amazon has clearance 9th-generation WiFi iPad...
Amazon has Apple’s 9th generation 10.2″ WiFi iPads on sale for $80-$100 off MSRP, starting only $249. Their prices are the lowest available for new iPads anywhere: – 10″ 64GB WiFi iPad (Space Gray or... Read more
Apple is offering a $50 discount on 2nd-gener...
Apple has Certified Refurbished White and Midnight HomePods available for $249, Certified Refurbished. That’s $50 off MSRP and the lowest price currently available for a full-size Apple HomePod today... Read more
The latest MacBook Pro sale at Amazon: 16-inc...
Amazon is offering instant discounts on 16″ M3 Pro and 16″ M3 Max MacBook Pros ranging up to $400 off MSRP as part of their early July 4th sale. Shipping is free. These are the lowest prices... Read more
14-inch M3 Pro MacBook Pros with 36GB of RAM...
B&H Photo has 14″ M3 Pro MacBook Pros with 36GB of RAM and 512GB or 1TB SSDs in stock today and on sale for $200 off Apple’s MSRP, each including free 1-2 day shipping: – 14″ M3 Pro MacBook Pro (... Read more
14-inch M3 MacBook Pros with 16GB of RAM on s...
B&H Photo has 14″ M3 MacBook Pros with 16GB of RAM and 512GB or 1TB SSDs in stock today and on sale for $150-$200 off Apple’s MSRP, each including free 1-2 day shipping: – 14″ M3 MacBook Pro (... Read more
Amazon is offering $170-$200 discounts on new...
Amazon is offering a $170-$200 discount on every configuration and color of Apple’s M3-powered 15″ MacBook Airs. Prices start at $1129 for models with 8GB of RAM and 256GB of storage: – 15″ M3... Read more

Jobs Board

*Apple* Systems Engineer - Chenega Corporati...
…LLC,** a **Chenega Professional Services** ' company, is looking for a ** Apple Systems Engineer** to support the Information Technology Operations and Maintenance Read more
Solutions Engineer - *Apple* - SHI (United...
**Job Summary** An Apple Solution Engineer's primary role is tosupport SHI customers in their efforts to select, deploy, and manage Apple operating systems and Read more
*Apple* / Mac Administrator - JAMF Pro - Ame...
Amentum is seeking an ** Apple / Mac Administrator - JAMF Pro** to provide support with the Apple Ecosystem to include hardware and software to join our team and Read more
Operations Associate - *Apple* Blossom Mall...
Operations Associate - Apple Blossom Mall Location:Winchester, VA, United States (https://jobs.jcp.com/jobs/location/191170/winchester-va-united-states) - Apple Read more
Cashier - *Apple* Blossom Mall - JCPenney (...
Cashier - Apple Blossom Mall Location:Winchester, VA, United States (https://jobs.jcp.com/jobs/location/191170/winchester-va-united-states) - Apple Blossom Mall Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.