Category Archives: Articles and Books

Articles and Books

My Writing Board

Articles and Books WordPress

20 Rules of Capitalization

Yesterday, I wrote an article on technical writing. Today, I’m laying out a few basic rules with regards to when to capitalize things. This is pretty straight forward but I find it can help to remember the rules to lay them out in a basic way. These things should have their first character capitalized:

  1. The first letter of a sentence. This includes a quoted sentence inside a sentence but not a phrase within a sentence. This also includes the first letter of a terminal command when a sentence starts with a command, although I try to restructure those sentences when they come up as it’s not a hard thing to do.
  2. The letter I.
  3. Titles. Each letter in the title of books, movies, poems, songs, articles, newspaper/magazine articles and works of art should be capitalized. This includes when these objects start with a word such as Of, A, The, And, etc but not when those words are in the middle of a title. Titles can also include specific course titles (such as when there’s a number attached). When using a compound title each otherwise capitalized word should be capitalized and each word not otherwise capitalized should not be.
  4. The names of people. Each word in a persons name should always be capitalized. Also their honorary titles/high ranking officials when preceding a name, such as President, Doctor, etc as well as an abbreviated title, such as Mr and Mrs. However, when those titles are used without a specific person attached they don’t need capitalization (although keep in mind if addressing someone with their title that should be capitalized). Titles that occur after a name do not require capitalization. Additionally the name of a relative when used as a proper noun should be capitalized.
  5. Gods, religious figures and holy works should be capitalized, although when describing a group of gods you need only capitalize the region or name of the pantheon and not the non-specific use of the word gods.
  6. The names of schools. This includes any educational institution, not just a college and university. Also, the name of a degree.
  7. Places. This includes bodies of water. A River, Lake, etc. As with the names of people, if you don’t put the name of the specific lake, but use the word you don’t need to capitalize that. A place can also be a mountain or building. Specific buildings, monuments, mountains, hills, volcanoes, etc. should have their first letters capitalized. Specific street names also have the first letter of each word capitalized. Also note that planets always start with the first letter capitalized.
  8. Specific flags.
  9. Regions. When discussing the Midwest, Sun Belt or South as a noun those should be capitalized. However, when using those words as an adjective they don’t need to be. A country, county, city or other region should also have the first character capitalized. I’ve always felt though, that the region unless a specific place, should have to earn the capitalization and it’s worth noting that Big 10/midwestern football just isn’t what it used to be… Also note that you should capitalize directions that are names but not directions when referring to a compass heading. Capitalize countries, languages and nationalities.
  10. Times. Days of the week, months and holidays. Seasons when used in a title, but not when used generally.
  11. Periods and events, except century numbers that are spelled out.
  12. Trademarked names. One thing I try to avoid here is using a trademarked name in writing as a verb, even if that word has become commonplace. For example, while you frequently hear people say to Xerox something I would change that to make a copy of something.
  13. Groups and organized bodies. Athletic, civic, national, political, and racial groups should be capitalized. This includes the name of a court and some other government terms, including Administration when describing a presidents administration, Cabinet when describing that of a president or prime minister and Federal when referring to the government of a country.
  14. Lists. If the first word of any bullet or item in a numbered list is capitalized then all should be, including directions. If two or more sentences follow a colon (not one sentence) then the first word of each should be capitalized; however, if there are items after a colon that are not sentences they do not require capitalization unless another rule requires it.
  15. The first word of salutations and complementary closings.
  16. Words derived from proper nouns.
  17. Initials, initialisms, initials with names and acronyms (unless in commands where the acronym is the command as you’re actually writing the name of the command). Acronyms include the call letters of television and radio stations.
  18. Any character in text that you quote should be capitalized exactly as it appears (although if all words begin with a capitalized character then you don’t need to quote the string).
  19. The first word of each line of poetry, unless not quoted in the poem.
  20. When shouting using the written word one can capitalize each letter of the word to add inflection; however, this is not necessarily proper nor a rule, simply commonplace.

Finally, it’s worth mentioning that writing such as this is a blog. While I don’t like that word, I find that such writing typically frequently allows the writer a certain amount of flexibility with regards to grammatical rules (for better or worse). This could be due to the fact that much of what’s written is done in the middle of the night. While this isn’t an excuse to use poor grammar it does tend to mean a less stringent editorial process over the grammar used. In other words, read/use the content at your own risk. :)

Note: At the request of my readers I’d be happy to write a follow-up article on when to capitalize assets, but I might have to bust out some of my books from Accounting 101 in college to do so!

Articles and Books

25 Tips For Blossoming Technical Writers

I write a pretty good amount of content. These days, I edit almost as much as I write. And in doing so, I’ve picked up on some interesting trends in how people write. This has led me to mentioning a few tips and tricks, if I can bore you with the details for a bit:

  1. Define the goal. What do you want to say? The text on the back jacket of most of my books was written before I ever wrote an outline. Sometimes I update the text when I’m done with a book because the message can change slightly with technical writing as you realize some things you’d hoped to accomplish aren’t technically possible (or maybe not in the amount of time you need to use).
  2. Make an outline. Before you sit down to write a single word, you should know a goal and have an outline that matches to that goal. The outline should be broken down in much the same way you’d lay out chapters and then sections within the chapter.
  3. Keep your topics separate. A common trap is to point at other chapters too frequently. Technical writing does have a little bit of the find your own adventure aspect, but referencing other chapters is often overused.
  4. Clearly differentiate between section orders within a chapter. Most every modern word processing tool (from WordPress to Word) provides the ability to have a Header or Heading 1 and a Header or Heading 2. Be careful not to confuse yourself. I like to take my outline and put it into my word processing program and then build out my headers from the very beginning. When I do so, I like for each section to have a verb and a subject that defines what we’re going to be doing. For example, I might have Header 1 as Install OS X, with Header 2 as Formatting Drives followed by Header 2 as Using the Recovery Partition followed by Header 3 of Installing the Operating System.
  5. Keep your paragraphs and sentences structured. Beyond the headings structure, make sure that each sentence only has one thought (and that sentences aren’t running on and on and on). Also, make sure that each paragraph illustrates a sequence of thoughts. Structure is much more important with technical writing than with, let’s say, science fiction. Varying sentence structure can keep people awake.
  6. Use good grammar. Bad grammar makes things hard to read and most importantly gets in the way of your message getting to your intended audience. Strunk and White’s Elements of Style is very useful if you hit a place where you’re not sure what to write. Grammar rules are a lot less stringent with online writing, such as a website. When it comes to purposefully breaking grammatical rules, I like to make an analogy with fashion. If you show up to a very formal company in $400 jeans, they don’t care that your jeans cost more than most of their slacks; they just get cranky you’re wearing jeans. Not everyone will pick up on purposeful grammatical lapses. Many will just judge you harshly. Especially if they hail from the midwest.
  7. Define your audience. Are you writing for non-technical users trying to use a technical product? Are you writing for seasoned Unix veterans trying to get acquainted with a new version of Linux? Are you writing for hardened programmers? The more clearly you define the audience the easier it is to target a message to that audience. The wider the scope of the audience the more people are going to get lost, feel they’re reading content below their level, etc.
  8. Know your style guide. According to who you are writing for, they probably have a style guide of some sort. This style guide will lay out how you write, specific grammar styles they want used, hopefully a template with styles pre-defined, etc. I’ve completed several writing gigs, only to discover I need to go back and reapply styles to the entire content. When you do that, something will always get missed…
  9. Quoting is important when writing code. It’s also important to quote some text. If you have a button or text on a screen with one word that begins with a capped letter, you don’t need to quote that in most style guides. But if there’s only one word and any of the words use a non-capped letter or have a special character then the text should all be quoted. It’s also important to quote and attribute text from other locations. Each style guide does this differently.
  10. Be active. No, I’m not saying you should run on a treadmill while trying to dictate the chapter of a book to Siri. Use an active voice. For example, don’t say “When installing an operating system on a Mac you should maybe consider using a computer that is capable of running that operating system.” Instead say something like “Check the hardware compatibility list for the operating system before installation.”
  11. Be careful with pronouns. When I’m done writing a long document I’ll do a find for all instances of it (and a few other common pronouns) and look for places to replace with the correct noun.
  12. Use examples. Examples help to explain an otherwise intangible idea. It’s easy to tell a reader they should enable alerts on a system, but much more impactful to show a reader how to receive an alert when a system exceeds 80 percent of disk capacity.
  13. Use bullets or numbered lists. I love writing in numbered lists and bullets (as with these tips). Doing so allows an author to most succinctly go through steps and portray a lot of information that is easily digestible to the audience. Also, if one of your bullets ends with a period, they all must. And the tense of each must match.
  14. Use tables. If bullets are awesome then tables are the coolest. You can impart a lot of information using tables. Each needs some text explaining what is in the table and a point that you’re usually trying to make by including the table.
  15. Judiciously use screen shots. If there’s only one button in a screen shot then you probably don’t need the screen shot. If there are two buttons you still probably don’t need the screen shot. If there are 20 and it isn’t clear in the text which to use, you might want to show the screen. It’s easy to use too many or not enough screen shots. I find most of my editors have asked for more and more screens until we get to the point that we’re cutting actual content to fit within a certain page count window. But I usually have a good idea of what I want to be a screen shot and what I don’t want to be a screen shot from the minute I look at the outline for a given chapter. Each screen shot should usually be called out within your text.
  16. Repetition is not a bad thing. This is one of those spots where I disagree with some of my editors from time to time. Editors will say “but you said that earlier” and I’ll say “it’s important.” Repetition can be a bad thing, if you’re just rehashing content, but if you intentionally repeat something to drive home a point then repetition isn’t always a bad thing. Note: I like to use notes/callouts when I repeat things. 
  17. White space is your friend. Margins, space between headers, kerning of fonts. Don’t pack too much crap into too little space or the reader won’t be able to see what you want them to see.
  18. Proofread, proofread, proofread. And have someone else proofread your stuff.
  19. Jargon, acronyms and abbreviations need to be explained. If you use APNS you only have to define it once, but it needs to be defined.
  20. I keep having editors say “put some personality into it” but then they invariably edit out the personality. Not sure if this just means I have a crappy personality, but it brings up a point: while you may want to liven up text, don’t take away from the meaning by doing so.
  21. Don’t reinvent the wheel. Today I was asked again to have an article from krypted included in a book. I never have a problem with contributing an article to a book, especially since I know how long it takes to write all this stuff. If I can save another author a few hours or days then they can push the envelope of their book that much further.
  22. Technical writing is not a conversation. Commas are probably bad. The word um is definitely bad. Technical writing should not ramble but be somewhat formal. You can put some flourish in, but make sure the sentences and arguments are meaningful, as with a thesis.
  23. Be accurate. Technical reviewers or technical editors help to make sure you’re accurate, but test everything. Code, steps, etc. Make sure that what you’re saying is correct up to the patch level and not just for a specific environment, like your company or school.
  24. Use smooth transitions between chapters. This means a conclusion that at least introduces the next chapter in each. Don’t overdo the transitions or get into the weeds of explaining an entire topic again.
  25. Real writers publish. If you write a 300 page document and no one ever sees it, did that document happen? If the document isn’t released in a timely manner then the content might be out of date before getting into a readers hands. I like to take my outline (step 2) and establish a budget (a week, 20 hours, or something like that).
Articles and Books iPhone Mac OS X

Apple Style Guides

Before you send me an email correcting something I’ve written, or more specifically how I’ve written it, check style guides. If it’s something Apple related, those are at

Thank you,

The mgmt

Articles and Books iPhone Mac OS X

Instant Apple iBooks Review

I just finished reading Instant Apple iBooks, by Zeeshan Chawdhary., available at Packt at As with mine and TJ’s Instant Apple Configurator book, it’s a nice, quick read. It has very specific recipes for getting your iBook written quickly. The thing I like about this book is that it allowed me to focus on my content rather than thinking so much about how to technically put the words, images and other elements I wanted where I wanted them. I also have to say that while iBooks is pretty easy, using a book like this will get you up to speed much quicker than just knocking around the system hoping to find that one button that allows you to insert a video at just the right size in just the right spot.


I also like the fact that the layout allowed me to read only the parts that mattered to me. For example, I have used the iBooks app for awhile, so I really just wanted to jump straight into writing. While some of the book is very specific to shopping on the iBookstore much of it is also dedicated to writing. I like it when I can pick something up and have no dependencies looking at earlier elements of the book.

Overall, it’s a nice quick read and very practical. Even if you’ve been using iBooks, check it out; you may learn something new (I did).

Articles and Books iPhone Mac OS X

Book On Apple Configurator Finally Shipping

The Packt book I did with TJ Houston is finally shipping! WooHoo!!!


Articles and Books Consulting Interviewing

Amsys Interview Part II

Awhile back I did an interview with Amsys for their blog. If you’d like to see Part two of that interview (which outlines what weed does to computers amongst other things), check it out at

Possibly The Most Important Command On The Mac

curl -L | bash


Tip of the ‘ole hat to Erin for April fools fun for that one…

Articles and Books Interviewing Mac OS X Mac OS X Server Mac Security Mass Deployment personal

Interview with Amsys

I’ve followed Amsys for awhile, with their training materials and the such. Now, they’ve published an interview with me. If you want to know what I think of skinny jeans, griffins and most importantly where you should (or should not) keep your weed, check out the interview here:

Screen Shot 2013-02-27 at 10.28.03 AM

Articles and Books iPhone

iPads In The Enterprise Training From TrainSignal

TrainSignal, a popular site for computer based training videos, has built a course for iPads in the Enterprise. As a technical reviewer, I’ve had a chance to check out all the content, and it’s a good overview of what it takes to deploy iOS in enterprise environments. The course covers Apple Configurator, iPhone Configuration Utility and other tools common in such a deployment as well as the general concepts that those not yet familiar with iOS should get before embarking on such a deployment.

The course is narrated by and developed by John O’Neill Sr., who brings a really upbeat and refreshing tempo to the table. To access the content, check it out at