More pathological XPages design

Let’s imagine you’re an XPages developer (big stretch, I know.) And let’s say you’re building a page for someone to input data. And one if the things you need to have them input is called “Customer.”

Well, what does that mean? You might think off the bat that it means “who is the Customer involved in this particular business object?” But maybe it just means “is the party involved in this business object a customer or not?”

So the first possibility is: yes or no?

But maybe it really means a reference to some outside party who purchases stuff from your company. So if that’s the case, the question is: should the user be constrained to a set of choices? Or should the Customer be an open-ended decision that’s no more constrained than the Subject line of an email?

There are two distinct decisions to make here: 1) is the data the user can provide constrained to a set of choices; and 2) what is the UI idiom used to present those choices?

The answer to question 1 can be determined by understanding the data model of the application. Is there a fixed list of customers that people can pick from? Is that list driven from a keyword document? A view column? A JDBC call? An XML document? Smoke signals? Whatever the answer, there’s an underlying logic to the data of the application that can provide an answer.

Unfortunately, in today’s XPages world, the developer must also answer question 2: what’s the UI idiom?

This is completely wrong.

What is the very first question you ask, as a developer, when choosing a UI idiom for a selection control? “How many choices are there?” We all ask it first every time. And the second question? “What platform are the users on?”

But there’s two problems here: first, the answer to the first question is not static. In the case of a customer list, that might be 5 choices on the first day, 50 choices the next year, and 5000 choices the next decade. If you picked a combobox for your idiom, your UX is going to suck 12 months from now; second, just because your combobox choice was okay for Chrome users on desktop computers doesn’t mean it’s okay for iOS users on phones. Platforms with reduced resolution and touch-interaction just don’t support the same idioms that keyboard & mouse-driven widescreen laptops do.

Therefore, it’s a bad idea to make this decision at coding-time. Even if you’re a really good visual designer, and even if you did a great job writing the specification for the application, your best decisions are based on information available today. But the information available tomorrow is different. The customer list in 12 months might be 10 times as long. Expense report processing might have been split between sales divisions. Health insurance claims might now be reported with ICD-10 encoding instead of ICD-9. You just can’t anticipate the forward progress of business.

And really, you shouldn’t have to. You shouldn’t have to pick the user experience idiom at design time. The platform should pick it for you, in this case based on the size of the constrained set and the platform of the current user. Whether your interface displays a toggle slider, a radio button, a combobox, a listbox, a dialog picklist, a typeahead or a completely open text box — is a choice that should be determined when we know the context of both the user and the data, not when we are simply trying bind a control to a data model.

What does that mean? Well, it means you COULD write a custom control in XPages with every kind of selector interface available, with a crazy-complicated bunch of loaded= expressions to figure out what type of experience the user has, or you could say “why don’t I just have an input control called ‘selection’ where I can drop in EL to figure out what the idiom is based on the context?” And if you say the latter, then I suspect you’ll want to stay on top of some forthcoming announcements on this blog. šŸ™‚

Posted in Uncategorized
One comment on “More pathological XPages design
  1. There’s a tool in the toolbox that is probably relevant here, but I haven’t dug into
    : renderers. XPage developers can often see UI controls as just that – a control with a specific UI output. But the DataView and FormTable controls have shown us that doesn’t have to be the case. A single “UI control” can change the user interface that results from it depending on the context. Because the control is not HTML or XML, it’s an instantiation point for a Java class that has a method to define what HTML to pump out and what to do with the properties defined by the user. The control is a woman in a red dress, but she’s not a woman, she’s just source code that a moment later can quite legitimately look like an agent, Mr Anderson.

Take the red pill.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: