Building for One, Part six: four names for one app

Building for One, Part one: a calm iPad display for someone living with dementia built a calm daily tablet display for someone in the early stages of dementia, and Building for One, Part five: everybody reads it before she does got it into three app stores. This part is a coda, written while we wait for feedback rather than build anything.

It is about the names. There are four of them, and that is not an accident or an oversight.

TL;DR – A name is not a brand, it is an answer to a question, and four different people ask four different questions.

One product, four names

Most apps have one name and use it everywhere: on the icon, in the store, in the bundle identifier, and in the release notes. It is simpler, and for most products it is correct.

This one has four:

Four naming systems is more work than one. It is worth it because each answers a different question, and a single name would answer one of them well and the rest badly.

The name that never appears

The technical name is sienna. It is the namespace, the package and bundle identifier, the repository, and the database. It is also what identifies the app inside App Store Connect, Play, and Amazon, and what the signing certificates and provisioning profiles are bound to. So it is not invisible: developers read it constantly. It simply never appears in front of a user.

This is old practice rather than a clever idea. Windows 95 was Chicago for years before it was Windows 95, and Chicago was not a whiteboard nickname: it was the name in the betas, the documentation, and the developer materials, in use from the start and long before anybody settled on what the box would say. Microsoft kept the two apart on purpose, and the marketing name arrived late, which is the correct order.

The reason is that an identifier is permanent and a brand is not. A bundle identifier cannot be changed after release without shipping a different app: new listing, no reviews, no update path for anybody already using it. A product name, by contrast, is a marketing decision, and marketing decisions change.

Tie them together and you have made a reversible decision irreversible for no benefit. Call the package uk.co.multizone.daysome and the day the product becomes something else, you either live with a mismatch forever or start again from zero installs.

So for years, we have adopted the approach that every app we manage gets a neutral codename that means nothing e.g. linen, parchment, sienna. They are materials and colours, deliberately not descriptive, because a descriptive codename has the same problem in miniature. The point of the name is to be a stable handle, not to be apt.

Today was taken, obviously

The working name for the first week was Today. It is the right word, and that is exactly why it was never available.

This is a small thing that costs a surprising amount when you find it late. The name is in the repository, the identifiers, the test fixtures, and the screenshots. We found it early because we tried to reserve it in App Store Connect on day two, which is something you should do too and was part of the same instinct that built the release pipeline before there was much to release: do the boring registration work first, while changing your mind is still free.

Where the -some comes from

Read Daysome as day plus some and you will not be far off, and that is how most people will read it. But the -some in wholesome, winsome, gladsome, lissome, and handsome is doing something more particular than the ordinary word.

It is a suffix, from Old English -sum, meaning "characterised by" or "tending to" and a relative of same. It is still productive, which is to say English speakers can coin new words with it and be understood without explanation. That is not true of most old endings, and it is the whole reason the name works at all.

So Daysome is formed the way wholesome is formed, and it means roughly what it looks like it means: characterised by the day, having the day in it.

There is a second reading, which arrived after the name did. Someday is the vague one, the deferred one, the one that is always later. Turn it round and you have this day, the one actually in front of you. For a product whose entire job is to answer "what day is it and what is happening" that is a better description than anything we would have arrived at deliberately.

My Day, because the icon is read by a different person

Daysome is a good store name. It is findable, it is ownable, and it means something to somebody choosing an app for a parent.

It is a poor name on an icon, because the person looking at that icon is not the person who chose it. She has to recognise it every day, on a home screen, without being taught. Daysome is a coined word, and a coined word has to be learned. That is a cost we are happy for a daughter to pay once in a store listing and unwilling to ask of somebody who may not retain it.

So the icon says My Day. Two ordinary words, in the order somebody would say them, describing exactly what is behind them. There is nothing to learn.

This is the same argument as the icons inside the app, which part three is about. We removed the knife and fork and the cup because they carry no meaning to somebody who has not been taught them, and an icon nobody can read is worse than nothing on the screen. A coined app name on a home screen is the same problem wearing a different hat.

And it must never label anyone

There is a harder constraint on the icon name, and part five is largely about it. The app installs on an iPad that already belongs to the person it is for. Whatever is on that home screen, is read, alone, with nobody there to frame it.

Which rules out an entire category of names that would be better for search. Anything of the form "Dementia Daily Planner" is more findable, more descriptive, and completely unusable, because it labels someone on their own device every time they looks for the icon.

My Day passes that test and Daysome would too. Neither says anything about the person it is for. That was not luck; it was the constraint the shortlist was filtered through before anything else.

The releases are sea areas

The fourth system is the changelog. Each release, or short run of betas, carries a name, and Daysome's are the sea areas of the Shipping Forecast, in the order they are read out: Viking, North Utsire, South Utsire, Forties, Cromarty, Forth, and on round the coast.

Partly this is because there are about thirty of them, which comfortably outlasts anything we are likely to ship. Mostly it is because the Shipping Forecast is a list recited at the same hours every day for a century, to people who mostly are not sailors and listen anyway. It is the closest thing broadcasting has to the point of this app: the same reassuring shape, at the same time, whether or not you needed it today.

The other apps in the estate use their own sets, and the sets are deliberately different so that a name never identifies the wrong product in a support conversation.

Why we skip one

One of the sea areas is not used, and we are not going to name it here either, for precisely the reason it is not in the changelog.

It is an ordinary sandbank with an ordinary name, and has been for as long as the forecast has been read. Over the last couple of decades the word has picked up a second sense in British usage that has nothing to do with shipping, and everything to do with a headline nobody wants.

Nobody would ever have complained. It would simply have been slightly wrong, sitting in a release note for an app that exists to give somebody a calm day, for as long as the changelog exists.

The cost of skipping it is one line in the requirements documentation and one fewer name from a list of thirty. The cost of not skipping it is small and permanent, and it is the sort of thing that cannot be put right later without rewriting history.

We mention it because it is the whole discipline in miniature. Almost none of the naming decisions here were hard. They were decisions somebody had to actually make, rather than accept by default because the list was already in front of them.

What four names cost

The honest answer: less than it sounds, but not nothing.

The identifiers are set once and never touched. The store name and the icon name are two fields in three consoles, and they are written down in one place so they cannot drift. The release names are a list to work down.

The identifier is not a rename you can do later, whatever anybody tells you. We counted, in this app, which is three weeks old and uses no third-party SDKs at all: twenty-five occurrences across ten files.

Some of them are not even text. Gradle carries it twice, as namespace and as applicationId, which look like the same thing and are not. The Android source lives in a folder tree named after it, kotlin/uk/co/multizone/sienna/, with a matching package declaration inside, so that part is a directory rename rather than an edit. The Xcode project holds it once per build configuration. Fastlane has it in two files, and three of our own shell scripts hard-code it because they drive a device by package name.

And that is only the half of it inside the repository. The signing certificates, the provisioning profiles, the keystore, the entries in three store consoles, and the CI secrets are all bound to that string, and not one of them lives in your code. That is the real reason nobody supports changing it: half its footprint is somewhere you cannot refactor, so however good your find and replace, you are left holding certificates issued against a name that no longer exists.

We have had to rename an identifier on an earlier client project, and it was genuinely painful. Not difficult in an interesting way, just long, and wrong in a new place every time you thought you had finished. That is the experience this advice comes out of, rather than a rule somebody read: it would have been quicker to start a new project and move the code across. So treat it as unchangeable from the first commit, because in every way that matters, it is.

Which is also why words meaning "unfinished" have to stay out of all of them. Demo, test, sample, prototype, temporary, throwaway. The stores are for finished software, and an identifier or an app name carrying any of those reads as something never intended to ship, which is enough on its own to fail review. It is an expensive mistake precisely because of the paragraph above: the identifier you gave a throwaway prototype is the identifier you are stuck with on the day it turns out not to have been throwaway.

What it does cost is the discipline of remembering which name belongs where, in every document, listing, and support reply. It is genuinely easy to write Daysome where the reader will see My Day, or to put the codename in front of a customer. That is why all four are recorded together, with the audience for each, and why the answer to "what is this app called" is always another question: called where, and to whom?

Where it stands

Daysome is published on Google Play and the Amazon Appstore, and in daily use by the person it was built for. The iPad version is with Apple and has been for some days: their queue is slow at the moment, and as part five said at rather more length, there is nothing anybody can do about that except have everything else finished.

We are not adding features while we wait to hear what people make of it, which is why this part is about a word rather than a build.

The exception was the one thing on the list, which came from their carer, and which is already out: a meal on a list can be corrected where it sits, rather than deleted and typed in again. That is not a boast about pace. It is the reason for putting something in front of a real person before it feels ready, because the ask was obvious the moment somebody tried to use it and would not have occurred to us in a year of thinking about it.

Getting it, and telling us where we went wrong

On Android and Fire tablets it is out, so there is nothing to sign up for and no beta to join. It is on Google Play and in the Amazon Appstore, and it installs like any other app.

On an iPad it is still in testing, which needs an invitation from us, because that is how Apple's TestFlight works. Sign up at daysome.org/testers.html and we will send you one.

Either way we would like to hear from you, and that matters to us more than an install does. If you support someone in the early stages of dementia who is still living independently, or you work in dementia care and would be willing to tell us plainly where we have got it wrong, that is the thing we cannot get any other way.

Plainly, so nobody is misled: Daysome is an app centred on a display that shows the day. It is not a medical device, not a monitoring system, and not a substitute for anybody. It does not track whether medication has been taken, and it never will.