There are only two hard things in Computer Science: cache invalidation and naming things. —Phil Karlton
Karlton’s quote isn’t just for techies. Interface designers are in the business of naming things too. We’re copywriters. It matters if we call something an Event or a Milestone or a Deadline. And it also goes deeper than that. The names we choose shape our software. They define the way we think about it and the way our customers interact with it. To understand why this all matters, you should meet two important ideas from the programming world: domains and domain languages.
When you’re working on software, the domain is the life situation your software is involved with. Basecamp’s domain is the life situation where people are trying to collaborate together on a project. iPhoto’s domain is that situation where someone has a collection of photos and they want to look at those photos and share the photos with others.
Now here’s where it gets interesting. Each application has a way of approaching its domain. Software designers think of a domain like a big cake and cut it into slices. Basecamp cuts project management into Messages, Files, Milestones, To-Dos. Photo organizers before iPhoto ‘08 always sliced their domain into Photos and Albums. In both cases, the software designers take a complicated life situation and boil it down to a few easy pieces with names. No domain comes pre-sliced—unless you’re blindly copying someone else’s software. It’s up to the designer to cut the pieces and give them names.
This process results in a domain language. A domain language is the set of words that reflect the way you cut up a domain. It consists of the pieces you sliced and the names you chose to give them. This language defines an application and makes it special. And for the last couple years Apple has been innovating iPhoto’s domain language very intentionally.
Before iLife ‘08, iPhoto’s domain language was the same as any other photo app. You had Photos and you had Albums. Then in iLife ‘08 something changed. Suddenly you also had Events in the mix. This is huge. Apple realized that people don’t just want to find photos. Go back to iPhoto’s domain: it’s that situation where you have a bunch of photos and you want to look at them and share them. When you’re in that situation, you don’t just want to see random photos. You want to see and share photos of certain things. Like photos of your wedding, photos of your trip to Maine, or photos of that dinner in Paris. These are Events. They’re part of the domain, and since 2008 they have been expressed in iPhoto’s domain language.
Now iPhoto ‘09 has kicked their language up a notch further. In addition to Events there are also Faces and Places. Apple has made a few new slices into the photo organization cake, and they’ve opened up a new field of possibilities for people to find and enjoy their photos.
Keep this in mind the next time you’re designing an app or a feature. There is a strong tendency to use the same words that you see other software using. Be cautious about copying domain language, because copying language is copying a whole approach. Think through the domain yourself. What are people trying to do? What do they care about? Find your own language to cut closer to the bone and touch your customers’ real interests. Your software will be all the better for it.
James
on 06 Jan 09I agree with what you said up to Domain Language. For me a domain language/domain specific language would be a custom language written to express domain concepts in a more readable and easier to maintain way e.g.
When customer.HasGoldAccount: apply 50% discount When customer.HasSilverAccount: apply 25% discount etc.
See http://www.martinfowler.com/bliki/DomainSpecificLanguage.html for more info.
Jeremy
on 06 Jan 09Domain language also comes into play when you look at the complementary things that surround a product, but are outside the direct responsibility of the design or development team. Depending on the company, some examples might include the marketing site for the product, the training videos and documentation, and even the press releases announcing it. In a well-run organization, you’ll see a common base of language used to describe things throughout these disparate realms—even if different teams of people were responsible for each of them.
Ricky Irvine
on 06 Jan 09This is great insight and great advice. Reminds me of all the blogsites out there that are exactly the same, and at least one alternate approach. I think a lot more can be done still.
Ricky Irvine
on 06 Jan 09In the music domain, another approach. Yes. Rethink. Think. Think different. Think differently.
RS
on 06 Jan 09James—Yes we also use the phrase in your stricter sense of a DSL. However it’s a shame if the insight about names stops at the code level. It’s very useful to apply the same ideas higher up at the interface design and feature design levels.
Jeremy—Definitely. Eric Evans calls that “ubiquitous language” in Domain Driven Design. The phrase is a little clumsy but his treatment is excellent.
Jorge Arango
on 06 Jan 09Hi Ryan, thanks for this post—it’s very clearly stated.
The domain language concept sounds very similar to information architecture, which is a well-established field. Do you see any major differences between the two?
Stacy
on 06 Jan 09This is great insight! Thanks.
Tim
on 06 Jan 09Thanks for the post!
I usually don’t like comments that say that but: it did open my eyes.
The domain language is the kind of things we tend to accept and re-use without ever really thinking about it. It might be the right words from the start but I can see why it’s good to take a step back and really figure out what the words mean and represent.
RS
on 06 Jan 09IA and DDD have some similarities on the surface, but they are different practices with different histories. Information architecture is something that web designers and content people mainly talk about. It has to do with navigation, organizing information, and making a large volume of content findable and digestable. The IA’s main goal is helping humans manage a lot of information.
Domain-driven design on the other hand comes from the object-oriented programming culture. Things like “domain models” go back to the 80s, and my particular understanding of these terms has roots in the Smalltalk culture. Rails has actually been a big meeting place between the web culture and this programming culture. DDD’s main goal is to tackle the complexity of software design.
I can see the similarity you point out. For example Ubiquitous Language in DDD sounds a bit like Controlled Vocabulary in IA. However the practices, cultures and goals are quite different.
Andrew Hinton
on 06 Jan 09Ryan: I was just reading your response to Jorge.
Actually, the “controlled vocabularies” you mention are just a tool used in IA—but the goal is very much like what you describe for Domain-Driven Design. Not all IA focuses on “large volumes of content.” Much IA work actually deals with application design, and shaping how contexts (domains) interact, embed within or share information with one another in a way that works well for the user.
I first encountered such an approach when I learned about Contextual Design (which also models user situations ‘domains’ or contexts, and structures systems around them).
But I’m intrigued now with DDD—I’ll look into it more.
I suspect what we’re discovering is that very similar design approaches are evolving in their own silos, just with different names and some minor differences in approach. It’d be great to see what each silo could learn from the other.
Chris
on 06 Jan 09It’s three of the five Ws. “Who”, “what” and “where”.
As a thought experiment, does it make sense to find a way to add “why” and “how?”
luke hartman
on 06 Jan 09While I like events (primarily because of how iPhoto automatically detects and organizes them), I’m not sure how they are functionally different from albums. Perhaps I’m missing something, but in that case, I think the domain for organizing got a little too muddled.
Jeremy Roush
on 06 Jan 09Luke: Events in iPhoto contain all of the photos taken at that event, ordered as they were taken, while Albums contain photos specifically chosen and ordered for that album.
In typical usage, Events contain all of your photos, and Albums contain only the photos you intend to share.
luke Hartman
on 06 Jan 09Thanks Jeremy…that distinction is quite helpful
Nick
on 06 Jan 09I think we’ve reached the point where physical metaphors are starting to drop off in favor of more accurate virtual ones. iPhoto had to start off with the idea of “albums” because that was really the only thing the average person ever did with their real photos.
Events, Faces, Places are all virtual methods of organization, but they line up exactly with what people did anyway with photo alums. You’d make an album of your wedding photos, or of the kids growing up, or of that trip you took. Now, you don’t need to organize along those axes because it’s all done for you.
I think it’s important to notice, too, that this kind of organization is not possible with a simple hierarchical filesystem. It requires some intelligence, some software. So we’re reaching the point where at least some of our data is completely organized by our machines, with us only providing hints and labels. This is the ideal of computers! Let them do the things they’re good at: the organizing, the counting, the sorting. Let people to do things that people are good at.
Exciting times, and I’m glad to be young in them!
William
on 07 Jan 09Widow.
Jon
on 07 Jan 09Yes. This “new,” “virtual” organizational style is not a radical departure from tradition. Actually, it restores the true, user-centered photo organization that in the non-digital world is considered real, not virtual.
The most irritating comment I see from photo users is when they dismiss the value of metadata-based organization, insisting on a literal display of their folder structure. They simply haven’t thought through how much they are limiting themselves. A photo can only exist in a single folder at once, and aliases/links are not a sufficiently elegant workaround.
iPhoto (and before it, iTunes) recognize that organization by metadata (in other words, by meaning) is the preferred user front end for a collection of media, while the still-important file system should be the secondary, back-end view of the content.
alsomike
on 07 Jan 09Adobe Photoshop Album had this in 2003.
Cody Austin
on 07 Jan 09I found this article very interesting as I am in the engineering software business. Short and sweet.
Fernando Martins
on 07 Jan 09People designing interfaces often overlook what they to in their lives, and how they do it. They tend to separate their lives from their work, leaving out the contribution their daily experience with so many things could bring in.
I’ve always organized my photos in folders like events, family events, places, special weekends, holidays & vacations etc. I bet many people do so. And I bet some of them have made decisions about naming stuff in photo software – that still has names like “albuns” and “photos”.
Gerard Byrne
on 07 Jan 09The generic comment about naming things runs deepest – good names only come from having a clear and unambiguous understanding of the ‘things’ within the field under discussion. Clarity (and simplicity) are never easy.
Events was a much better organisational structure than ‘rolls’ which rarely made sense. Rolls related so much to the ‘film’ world when a roll was developed and the photos came back in a pack. Rolls became entirely useless when a digital film became the equivalent of 30-100 ‘rolls’ of film in capacity and people would shoot much more (free) photos.
But events themselves are almost ‘free’ because the events are (for most people) identifyable by days.
The value of Faces will be determined by the quality of face detection and recognition – if it gets it right 95%+ of the time it will be invaluable.
Places is less valuable as very few cameras have gps. But if the gps locations could be taken from another device (e.g. iPhone) and married to the photostream based on time that would be a different game entirely.
Keith
on 07 Jan 09It’s a balance though because people are consumers of other products first. So if you get too radical in creating a domain language for your product you better be certain that it warrants the shift!
Jamie Bullock
on 07 Jan 09I think this is another example of intelligent ‘80-20’ design by Apple. They’ve observed that in the majority of cases users classify photos using only a small set of simple rules (Faces, Places, Events), and focused on implementing those rules very well.
It’s this process of limitation and understanding their customer’s needs that makes Apple’s software design so good.
Matt Lincoln Russell
on 07 Jan 09Outstanding post, Ryan.
Greg
on 07 Jan 09Ryan, been lurking at 37 signals, but not commenting. This time I am compelled to say thanks for the fascinating post. This is far outside my usual work experience but the concepts are relevant to all sorts of design and communication. Cool stuff!
@ alsomike (trolls already?) calling BS: Adobe Album had what, exactly, in 2003?
Karen Theisen
on 07 Jan 09Fascinating post and discussion.
I appreciate the importance of domain language and naming domains with thought and consideration. However, I think a distinction should be made here. iPhoto has leveraged existing concepts - events, faces, places - that we call can relate to and understand immediately and intuitively, and they therefore work well. The problem that I have encountered is when entirely new concepts are used in a UI, or metaphors are stretched too far. In these instances, the poor users have nothing to leverage from from their previous knowledge to understand these new domains. For instance, Facebook has this problem over and over again IMHO. The Wall metaphor breaks down for me in several ways. I mean who has their own wall in the real world that people can come up to and stick things on? And I still don’t understand what a Wall to Wall is and I don’t care enough to try to figure it out (FB is supposed to be fun, not work after all) so I just muddle through it. Ditto for Live Feeds. I think for consumer facing apps especially the metaphors/domains used should be so easy to relate to and intuitive that they require no extra work to understand how they function (a la iphoto).
So, I think its imp to consider the domain language within the UI but to be very careful when coming up with new concepts or twisting familiar ones when they just don’t fit. If new concepts or domains are needed then those UIs need to be so well designed that the end user learns and assimilates them without even realizing. Case in point is the Street View on Google Maps and all the iterations that they’ve gone through to make this novel concept easier to use and more intuitive. It’s not easy.
RS
on 08 Jan 09Great points Karen. There is something special happening when the domain language also fits our natural language and expectations.
André Wendt
on 08 Jan 09Please note that that specific domain language is nothing Apple “innovated.” F-Spot, a photo app for Linux and anything running Mono, organizes photos using tags. However, those tags are hierarchical, and that hierarchy has featured People, Places and Events ever since the app first released in 2006. And they might not even have been the first.
Still, I see your point. It always amazes me that friends and family organize their photos in folders by date. How they can find pictures that are important to them is beyond me.
But then, maybe a lot of people shoot pictures for the sake of shooting, not remembering or looking at them. And that’s just sad.
Dave Goessling
on 08 Jan 09Many interesting and inspiring comments here. Thanks especially to Andrew, Jon and Nick. In the world of taxonomy design and “traditional” library science, this type of domain slicing has been common since the “colon classification” work of S.R. Ranganathan in the mid 20th century. see http://en.wikipedia.org/wiki/Colon_classification I use taxonomy more in the faceted indexing (metadata) sense than the more commonly understood (and used in much IA) navigational sense. A robust multi-domain (business domain) taxonomy building exercise always includes a step to “harmonize” the vocabularies of SMEs across multiple business domains – to correlate the what one group means by a term or word and to build a set of equivalencies and relations. This is more than just “keywords”. It can be difficult to map the fuzzy borders of meaning of a term used in common by more than one group of SMEs, but that’s what the relationships are for. And, that is where the business value lies that both IAs and developers strive to achieve. “Traditional” IAs and (apparently) DDD developers do this in the course of ther work, as librarians have done in taxonomy and thesaurus development for years. Perhaps we are gradually working toward a common set of understandings of these concepts, and someday soon a taxonomy mapping them will be built!
This discussion is closed.