Software products as notation

Yesterday I touched on Ken Iverson's "Notation as a Tool of Thought" and how features in a software product can have "suggestivity", not only complementing existing functionality but inspiring new features. In fact, looking again at Ken's list of important characteristics of a notation, each characteristic can be applied to software products. Here's my interpretation of how, using a hypothetical packing list app for concrete examples.

Ease of expressing constructs arising in problems

The whole point of a software product is to make it easier to deal with a specific problem. We do that by inventing conceptual models (constructs), but the right concepts aren't enough. Product owners also have to make sure it's easy to create those constructs, manipulate them, and relate them to each other.

An app that manages packing lists for family travel might have a "trip" construct where the user names the jobs that need to be accomplished on the trip, whether they be camping, staying warm, or entertaining kids on a long road trip. The model is simple and closely related to the problem. But the app can make using that model awkward—such as by requiring all choices about a trip to be made up front—or it can facilitate changes.

Ability to subordinate detail

Every problem has multiple levels of abstraction, and though users occasionally have to attend to the finer details, a good product shouldn't mire them in minutiae.

Our packing list app shouldn't require a user planning a trip to go through the full list of their gear and say whether each individual item is needed for that trip. Instead, it should require that the user go through—once—to name jobs that different gear is useful for, then after that ask only for what jobs the trip needs, and from that information assemble the sublists of gear that are needed into one packing list. The details have to be entered at some point, and they should be editable later, but the user shouldn't have to deal with them every time. The user should be able to operate at a higher level.

Economy

A good product does not do everything. It has a constrained set of capabilities, preferably the smallest possible set that solves a problem.

A packing list app could just create a checklist. It could also allow the user to say where each item is packed, to help them find items later ("Where did I put the flashlights?"). It could store pictures of gear and support sharing lists with family members. It could even support ad hoc queries ("How many times have I packed the flashlights in the luggage instead of with the camping gear?"). The product owner has to decide what's vital and what's bells and whistles.

The word "economy" suggests fewer features are better, but the word actually means "careful management of resources." How much effort are features to develop, maintain, and document? How confusing are features to users? Often, one well-designed feature can support lots of less critical features. In our packing list app, being able to export data enables other programs to query and visualize it. The app itself doesn't need those abilities.

Amenability to formal proofs

Only specialized software products tend to deal in formal proofs, but any product has to offer social proof. The user needs to see that their problem is solved correctly. They may also need to show their boss that the problem is solved correctly. If the software makes that difficult, it's not doing its job.

A packing list app has to make it apparent what's packed and what's not. It may also need to say why something is being packed, i.e. what job it's needed for or what other gear it's used with. If it shows where items are packed, it should make it easy to spot mistakes. It could even be proactive about ensuring the task is complete by suggesting gear based on past trips ("Trips that used the frying pan often used the camp stove too, but that's not on this list").

Conclusion

Until exploring suggestivity of features, I hadn't considered a product to be a form of notation. A graphical UI seems to lack the aspects we usually expect in a notation, like compactness, but when termed as the more abstract "subordination of detail", it's more apparent that UIs do in fact share characteristics of a good notation, just in their own way. Unlike mathematical notation, software UIs spread across a two-dimensional surface and extend through time as a series of steps, which makes their notation harder to recognize. But our goals for notation and software are similar. We want a tool that helps us think better. We want to get more done, faster and more reliably, and with less expense, including the resources we have to spend creating and maintaining the tool.

Do you have thoughts on software as notation? Send them to me! I'm curious to explore your perspective.