Disclaimer and License

Opinions expressed here by Tim Tripcony are his own and not representative of his employer.

Creative Commons License
Tip of the Iceberg is licensed under a Creative Commons Attribution 3.0 Unported License.
Based on a work at timtripcony.com.

Unless otherwise explicitly specified, all code samples and downloads are copyright Tim Tripcony and licensed under Apache License 2.0.

Search

« an easy way to give Domino Designer a ridiculous performance boost | Main| imagine »

Beyond Documents, part 2: a futuristic example

Category design
The aim of this series is to explore why it's instinctive for those of us in the Domino world to conceptualize everything in terms of "documents", as well as to ask what potential benefits might be open to us if we were to move beyond using the notion of a document as our fundamental unit of abstract thought.

In part 1 of this series, I asked why our first instinct as Domino developers is to base our entire conception of our applications on the notion of a collection of documents, and presented my theory on why that's currently the case. I also hinted that there's an alternative to maintaining that conception.

Why would we ever bind XPage components to anything other than a "document"? Let's examine a notion that (currently) is so futuristic as to be a bit ridiculous in the hopes that it will elucidate a few implications. In subsequent posts, we can take a look at how the same principle can be applied even today to make our applications easier and more pleasant to design, use, and support.

Imagine a world in which advances in gene therapy allow a person's eye or hair color to be changed without, respectively, contact lenses or dye. Rather, technology is developed -- and later commercialized -- that actually changes the color at a genetic level. Customers can decide, for example, that they want green hair and purple eyes.

You have been hired to develop an app that will allow customers to schedule the surgery in which these genetic changes will be applied. Should be easy, right? It's just a "form" with a few "fields". One can even envision what the UI might look like: you'd probably want a date picker for them to specify their preference for the day of their appointment, a checkbox group to indicate whether they want to change their eye color, hair color or both, and then radio buttons or combo boxes to allow them to choose from a constrained list of available color names for each of the modifiable characteristics. Simple. Each of these components is bound to an item on a document: specifically, the record that represents their request for an appointment for surgery.

But the document is not your customer's goal. Your customer's goal is to have green hair and purple eyes. Your customer doesn't ultimately care whether a document is created. They want to change something about their own appearance. So, while our instinct for such a simple "form" is to make the entire user interface look like a paper form, wouldn't it be much more engaging for the customer if part of the UI was a picture of them?

Imagine your app integrates with the camera on the customer's device: they take a picture of how they currently look, and photo analysis determines where their hair and eyes are, allowing you to define click targets. Clicking on the specific portion of themselves that they want to alter pops up a tooltip dialog or interface equivalent that includes a color palette. As the customer hovers over any color swatch in the palette, their photo is immediately updated to provide a preview of how they would actually look if they chose that particular color for that particular attribute. Clicking their favorite updates the component's value.

Is it within reason to assume that customers would be more excited by this type of UI -- and, as a result, more likely to go through with purchasing their desired modifications -- than they might be if the UI were just a grid of fields? I admit, I would find it a bit disturbing if this technology ever emerged, but I'm assuming this analogy makes a vivid point about why thinking beyond documents to the reason documents exist can alter our conception of an ideal user interface.

Next let's extend this theoretical technology even further. Inspired by the programmable tattoo technology that already exists, your employer invents a way for your customers to genetically alter themselves at will. Now that customers no longer have to schedule a surgery -- they simply choose a new eye color and their eye color immediately changes -- what changes do you need to make to your app?

Despite your fancy UI in the initial version, maybe your components were still bound directly to "fields" on a "document". Assuming this is an XPage app, and your document data source is named customer, you might have EL expressions in your source that look something akin to the following:

#{customer.leftEyeColor}
#{customer.rightEyeColor}


The customer isn't thinking of their interaction with the app as a document, they're thinking explicitly in terms of their own physical appearance... but your data model is still thinking of your customer -- a human being, with certain named attributes whose properties can now be programmatically altered -- as a document. But what if it didn't?

What if, instead, your entire data model was focused on your customer? What might that "look" like?

Assuming, again, that this is an XPage app, you would probably define a Java class. Ideally, it would be a bean; it doesn't necessarily have to be a managed bean, but it should adhere to bean conventions. If this class has properties like leftEyeColor and rightEyeColor, and the class instance -- whether defined as a managed bean, a data context, an object data source, or exposed by other means -- is accessible via a variable named customer, your EL expressions should instead be:

#{customer.leftEyeColor}
#{customer.rightEyeColor}


Oh wait... they already are. Okay, never mind.

So what needs to change in your Java class? In the original version of your app, the class presumably has methods like load() and save(), which (respectively) retrieve and store information about the customer. That information is stored on documents in a Domino database. In the new version, the information is stored on a microchip implanted in the customer. The team who designed that chip -- specifically, the portion that communicates with your company's servers over 4G (or whatever is the newest wireless communication protocol at the time) to download firmware updates and such -- has provided you with documentation for the REST API that allows you to send a signal directly to the chip to tell it to immediately change the customer's eye color. So what needs to change? load() and save(). Instead of reading and writing Domino documents, those methods are now parsing and sending JSON, which is trivial in Java. Everything else in the class can stay exactly as it is.

And what needs to change in your XPage? Not a darn thing... well, okay, with one exception: you can remove the date picker for scheduling the change, 'cause this is real-time, baby.

As your customer, I can pull out my phone, tap on a picture of my face, tap on a color, and then look in the mirror and giggle as my left eye turns bright purple. Then, just to really freak people out, repeat the process and turn my right eye orange.

When you originally designed this app, the requirements didn't say anything about supporting this new feature because it hadn't been invented yet, but the moment it had, you made fairly minor changes to two methods of one Java class, and deleted one now-deprecated visual component from an XPage.

This was the most extreme example I could even think of to illustrate how changing your entire conception of applications from documents to the reasons documents exist isn't simply "better" in some nebulous philosophical sense; rather, it allows your application to evolve to do things you never anticipated when you first wrote the app... without having to rewrite the entire app.