How we are following an object-oriented approach to structuring information

Modelling the real world

I have described in a previous post how object-oriented user interface concepts have successfully persisted for decades. What makes these ideas so persistent is their link to real-world objects.

To make sure we get that connection right in our systems, we need to model the real world. More accurately, we need to model people’s understanding of the real world.

This is subject domain modelling. It is a key step in any robust information architecture project.

The subject domain model represents people’s understanding of the real-world objects and concepts, and the relationships between them, that exist within an area of focus.

For the Scottish Government, the scope is potentially vast. So our early draft models focused on the mechanics of government at a high level — how government works, and the outputs it needs to produce.

Developing the content model

From the subject domain model, we have produced a first draft content model. This articulates how the objects in a system can be represented as content types.

Each of these content types will have their own structures (including metadata and other attributes), and relationships with other content types. The content model should be informed from a user-centred point of view.

This content model will ultimately inform the navigation approaches we need to adopt to better meet users’ needs. The connections between content types will become the primary way people navigate through our information systems, because these connections reflect people’s understanding of the world as articulated through the content model.

Implementing the technical solution

One benefit of building a content model in this object-oriented way is that, because of the prevalence of object-oriented programming, developers will typically work in this way anyway. In defining a solution, they will need to map out relationships between different objects in the system.

By defining those relationships as part of a human-centred approach, we can ensure that these decisions are well-informed, and help avoid erroneous assumptions getting baked into the technical solution.

In summary, we start by building a subject domain model, which is a representation of real-world concepts.

We then need work out how to get to a technical solution, which will involve a relational database.

The content model is therefore the bridge we need to get us from the subject domain model to the technical solution. By developing the content model through human-centred approaches, we can also ensure it is informed by users’ mental models. This all helps us better meet users’ needs.

Object-oriented user experience and orca

Object-oriented approaches are robust, have existed for decades, and have underpinned some highly successful advances in user experience. Despite this, object-oriented theory hasn’t always been the most fashionable, or even very well known, among some user-centred design professionals.

But object-oriented user experience is making a comeback. In the past decade or so, the concepts have been newly popularised by the user experience consultant Sophia Prater. She has done some incredible work to bring these ideas up-to-date, adding new techniques, and making participation in the process more accessible to people from a wide range of disciplines.

This makes for an incredibly rigorous, robust, human-centred approach to developing information architecture and system requirements in a way that will better meet the needs of both the organisation and our end users.

Orca process

While object-oriented user experience is not new, Sophia Prater has synthesised her innovations into a new method called orca. Orca is an acronym made up of the four key elements of an object-oriented system model:

• Objects — the objects themselves, which inform the various content types that make up the system.
• Relationships — the connections between the objects, which underpin the main navigation routes through the system.
• Calls to action — things users can do with the objects; the verbs that people perform on the nouns.
• Attributes — the detailed elements that define the objects’ own structure; the template fields and metadata that are used to uniquely identify each instance of an object.

Each of these aspects is developed through three phases:

• Discovery
• Requirements
• Prioritisation

Through this iterative process, we develop a system model which in turn can become a content model.

This model can then go through sketching, prototyping and testing, which informs the “representation”, or the user interface implementations we will deliver.

All of this informs the requirements of the system we want to implement.

How we’ll cope

There is a lot of work ahead for us to achieve the full potential of structured content. But my message is: we’ll cope.

Cope stands for “create once, publish everywhere”. The idea is that, by getting our content structures right, we can enable the reuse of content on multiple channels, instead of wastefully rewriting similar content repeatedly.

The same content can be used on a webpage, an app, a text message, a digital display, in print documents and letters. Our information structures can help make sure the content can be optimised for each of these outputs.

Moreover, this structure helps make our content more machine-readable. This will help us be better prepared for unanticipated future technologies.

In other words, by structuring our content, we will set it free from the constraints of thinking about it as a flat webpage. Structured content will help us bring it straight to users where they need it — at the right place, at the right time, in the right way.

Organisations that have invested in these approaches have found the benefits lasting for decades. Content strategist Karen McGrane, in her talk Adapting Ourselves to Adaptive Content, outlined further examples of large organisations turning to structured content, then reaping the benefits in ways they didn’t even anticipate.

There is some hard work ahead to get our content structures right, and to maintain them on an ongoing basis. But the opportunities are vast.

Structured information could be the key to making content management more efficient overall, and enabling us to better meet users’ needs in far richer ways than we can at the moment.

---

In another post, I describe the benefits we expect to see from following this approach.