The mute switch disables all audio except alarms. Some people argue that the mute should disable
all audio or that this behaviour should at least be configurable. Turning off all audio allows the
possibility of forgetting about it and missing an important alarm. Making it configurable only makes
the situation more complex, and user error more likely. Neither of these choices is a good option.
It’s a difficult problem which John Gruber summarises nicely.

I think that the current iOS mute switch behaviour is perfectly fine and I often have my iPhone on
mute. The feature that I think is missing that would resolve this situation is a “do not disturb”
mode.

Imagine that you have a “Do-Not-Disturb” (DND) Mode switch in the Settings App below the Airplane
Mode switch. Similar to the way that Airplane Mode disables all networking, DND Mode disables all
audio but only for a limited time. When you enable DND Mode, you are presented with a menu to select
a time period: 15 minutes, 30 minutes, 1 hour, 3 hours, 6 hours. Once the time period expires, the
phone automatically turns DND Mode off. This avoids the possibility of the user accidentally
forgetting that they enabled it. (People don’t forget to turn Airplane Mode off because the cabin
crew of the plane remind them of it during the post-landing announcements.)

If there is an incoming call while in DND Mode, the phone makes no sound, but vibrates and activates
the screen to show the call just as it does in mute. This allows the user a chance to receive
critical calls if necessary. If a call is answered (or if the user initiates their own call), then
audio is enabled only for the Phone app for the duration of the call.

DND Mode could also be activated using Siri. More flexible time periods could be specified using
Siri as well.

“Do not disturb me for 30 minutes.”

“Do not disturb me until 4pm.”

“Don’t disturb me for an hour.”

“I am not to be disturbed for the next 2 hours.”

And if you use location services:

“I am not to be disturbed me until I have left this theatre.”

“Do not disturb me until I get home.”

The described Do-Not-Disturb Mode gives the user more control over their iPhone while reducing the
number of things that the user has to worry about. By requiring the user to specify not only what
the phone has to do but when it has to stop doing it, the phone now has the responsibility for it
instead of the user. And isn’t this what science-fiction has always been promising us? A world where
computers perform the mundane tasks and free our minds?

So random thoughts about what might be cool if it was related to textbooks and the iPad as so many people think it will be.

Forget about the iBookStore and ePub.

Think more about how magazines, subscriptions and NewStand have been implemented on the iPad. Now think about text books, but don’t think about them as ebooks, think about them as apps like how magazines have been done.

Assume that a school/university provides each student with an iPad, either on a rent/lease basis or to keep as part of their fees.

Now imagine that a school/university could setup their courses within iTunes Connect, specify the texts required for each subject and link this to their enrolment database. Students could then download the “Library” app from the AppStore, login to it using their student credentials and immediately have access to purchase their assigned textbooks within the App. This “Library App” could look and behave like the NewsStand app.

The question is whether the student have to pay for their texts, or would the institutions pay publishers a subscription to grant students access to a number of specific texts.

I think publishers would prefer having a regular subscription style income from the education institutions. Institutions would pass on the costs to the student in fees anyway. Under this model when the student logs into the “Library” app, their assigned texts would just automatically download, no questions asked, no credit card required.

This would eliminate the market for second-hand texts (which the publishers hate), make it easier for students, and reduce the number of financial transactions. The drawback would be that students would probably only have access to their texts during the duration of their enrolment.

Perhaps a hybrid of these systems where you could purchase individual texts if you wanted, and schools could also provide texts to students as well.

The NOTE, IMPORTANT and WARNING admonitions are the most commonly used. Publican does not support TIP and CAUTION, considering them adequately covered by NOTE and WARNING. Examples of what these look like in Publican can be seen in the Document Conventions section of any document built using Publican and any of the standard brands.

In my opinion, the use of admonitions leads to inferior document design and a poor reading experience. Admonitions “call attention to specific information” and to achieve this aim they are formatted to seize the reader’s attention. This creates distractions for the reader and clutters documentation with material that is unnecessary or at best misplaced. With the exception of WARNING, the information that each admonition represents can almost always be incorporated in a more usable (and maintainable) fashion.

To demonstrate this, I will discuss the three admonitions used by Publican. I will cover their purpose and how you can structure your documentation to present the same information in a clearer fashion.

NOTE

The Publican document conventions describes NOTE as follows:

Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier.

NOTE is described as containing non-essential albeit interesting information about the subject at hand. This is counter-intuitive. Why do you want to draw attention to non-essential information? Remember Strunk & White’s Rule #17: “Omit Needless words” ? The same principle applies to the document . Omit needless content. If content can be removed with no negative consequence then it should be. If the content is required to be included then at the very least it should be removed into a footnote, or an appendix. Unnecessary information should not be included in the main flow of the document.

IMPORTANT

Again I refer to the Publican document conventions:

Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring a box labeled ‘Important’ will not cause data loss but may cause irritation and frustration.

The IMPORTANT admonition seems to make a great deal of sense, highlighting information that readers often miss or steps that they skip over. However it is not the best solution to this problem.

The problem is that readers sometimes miss important information or skip over procedure steps. Sometimes this is accidental, and sometimes a reader intentionally skips a step, intending to come back later and forgetting to do so. There isn’t much point in trying to figure out which steps are likely to be skipped or forgotten because you don’t know the circumstances of the reader. If you do this, you will find yourself filling your procedures with unnecessary information that will make them more difficult to follow.

A cleaner solution is to put this additional information afterwards in a Troubleshooting section. When the reader encounters difficulties there will be one definitive place to look for help. This is easier for the reader, and is also easier for future writers to maintain. Keep your content as lean and as clear as possible. Only supply additional information at the point when it is required.

WARNING

WARNING is the one admonition that I am in favour of in general use. The Publican document conventions defines WARNING with:

Warnings should not be ignored. Ignoring warnings will most likely cause data loss.

WARNING differs from IMPORTANT in that it is critical that the reader is aware of it before performing a task. The reader is unlikely get a second chance. WARNING is for those situations where mistakes or deviating from a procedure will cause unrecoverable failure.

WARNINGs should be placed before instructions so the reader is forewarned. Procedures that can fail in this fashion could be preceded with a WARNING detailing the risks. The specific risky steps may also require a WARNING as well but this may be overkill.

One edge case that favours admonitions

Although it is preferable to not use admonitions, I have to point out that there is one use case where the disadvantages of admonitions can be leveraged to the benefit of readers: the update of documents in time-critical situations.

When a document must be updated and made available as quickly as possible, admonitions can be easily used to insert new content that is delineated from the existing material and highly visible to readers with very little effort. However this technique must be acknowledged as a temporary solution. The work which must be done to correctly incorporate this new information is hinted at by the types of admonition that are used as discussed above.

Conclusion

Admonitions, with the exception of WARNING, should not be used as a standard part of documentation because they reduce usability. The information they encapsulate can always be presented in a clearer form that does not disrupt the reader. The WARNING admonition is different in that the information it presents is critical to the reader.

The one exception to this is time-critical updates to documents, where the ease of use of admonitions and their high visibility to the reader is advantageous.

Without admonitions as a crutch, documentation does require more forethought. However your readers (and future maintainers) will thank you.

When adding a new rule to a Smart Playlist, hold down Option, click the Add button and a new indented group of rules is created. From within this new group you can create further nested groups. This lets you create very complex Smart Playlists combining both All & Any rule matches.

There doesn’t appear to be any obvious limit to the amount of rule nesting that can occur. However the dialog window doesn’t resize horizontally which limits the number you can add and still be able to work with them.

I don’t know how long this functionality has existed in iTunes but it is very neat and especially useful for iTunes Match users.

On a side note, iLounge.com has a great overview on iTunes Match features with details on the features and limitations of the service.

I have to believe that a lot of the problem comes from how we train
developers. I’ve said it before but most software students have never seen a
requirements document. And if you count a class assignment as a requirement
they’ve certainly never seen feature creep or shifting requirements. How can
they deal with something they’ve never trained for?

Brian Tarbox, Root Cause Analysis from Long Ago

Rob Stewart

http://en.wikipedia.org/wiki/Merlin_Mann

Of course the obligatory 2001 A Space Odyssey request:

And some bonus 2001 material

And some of my favourite things:

“Don’t worry about what anybody else is going to do… The best way to predict the future is to invent it. Really smart people with reasonable funding can do just about anything that doesn’t violate too many of Newton’s Laws!”

Alan Kay during a planning meeting at the XEROX Palo Alto Research Center (PARC) in 1971.

“Or they say it’s not necessary. As if that should stop one doing it.
It’s not necessary to have coloured socks. It’s not necessary for this cushion to be here
but is anyone going to write in and say I was shocked to see that cushion there,
it really wasn’t necessary? No. Things not being necessary is what makes life interesting.
The little extras in life.”

Stephen Fry on swearing, and the people who object to it.