Apps create boundaries and isolated user experiences.
It’s been awhile since I blogged about Continuous Client with my last experiment. I’ve had a lot of thoughts since then about application boundaries and how this impacts users.
Computing is very app centric especially today with the emergence of App Store’s on mobile devices and desktop computers. We’ve streamlined selling applications directly to the end user and removed as many barriers as possible to get at the users money.
When do we start creating and selling user experiences?
We as developers are creating more and more boundaries and isolated experiences that end users have to deal with. Our operating system and applications are not aware of the users workflow and old solutions like Copy/Paste still exist to aide the user to cross boundaries but this is not intuitive or a good experience.
Most often we find integration API’s like Android intents, Windows Phone and Windows 8 contracts or iOS URL schemes and document types. Microsoft OLE is another abstraction that was created for integration purposes. These solutions help integrate and hop boundaries instead of apps gaining understanding.
Users who are not tech savvy stumble with these boundaries. The boundaries we create between one app and another, and between apps and the operating system cause users confusion.
Every time my mom wants to send me something via email I get a phone call with a question like:
“I saved something I wrote and want to email it to you. How do I get it from Word to an email again?”
Users struggle with boundaries between applications because that’s where the user experience ends and understanding the system begins.
It is a broken user experience whenever a user has to hop fences of boundaries. Web search for “how to email a file” and you’ll find 713 million results. Here’s an example of one for Microsoft Outlook help that I don’t think would help my father.
How much money does it cost the industry to support broken user experiences created by these boundaries?
Applications and operating systems need to become aware of a users workflow and take part in it rather than expecting the user to navigating around boundaries and understand the system underneath.
Let’s take a look at a users workflow of creating an image in Photoshop, using the image in a document and sending the document to someone via an email.
Can you spot the boundaries?
If we think of these actions as events, it represents a timeline of the workflow. The events I have paired in matching colours (purple and orange) have potential correlation. This gives the application an opportunity to gain awareness of the users workflow instead of directing the user to a boundary. The boundary between applications starts to fade away.
If applications participate in the timeline both as producers and consumers they have the ability to make seamless experiences that help the user in what they are trying to accomplish as a whole and not just within the application.
Since our workflow is a timeline why doesn’t any of our software have an understanding of a timeline? There seems to be a fundamental mismatch with how we do work and how software is written to allow us to do work.
If we flip this vertically we can see the timeline and see how it may look represented as an event stream.
Having our workflow represented as a stream in the form of a timeline allows applications to have greater awareness than they have using other boundary bridging solutions like integration API’s.
This is not a suggested solution, I mention this to get people thinking.
The concept of a timeline gives applications awareness of our workflow. Applications become Continuous Clients and participate in a continuous user experience. User interactions could be captured by storing events and timestamps in the events (I didn’t include them for simplicity in the image above) gives these applications the awareness of temporal cohesion of interactions that could span multiple applications and potentially the operating system.
Actions with high temporal cohesion in a workflow are steps in a workflow grouped together during the same task and execute closely together in time.
Bringing Continuous Client and Transmedia together
I’ve been talking about and experimenting with Continuous Client now for a couple years and I’m still trying to evolve a lot of ideas. We are starting to see Continuous Client like features here and there but there is still a long way to go yet.
There’s another community that has been working on this problem much longer than the developer community. This community is the Transmedia story tellers.
Transmedia was named by Marsha Kinder in 1991. She went on to say:
Transmedia intertextuality works to position consumers as powerful players while disavowing commercial manipulation.
Transmedia is described from Wikipedia as (emphasis mine):
Transmedia storytelling (also known as multiplatform storytelling) is the technique of telling a single story or story experience across multiple platforms and formats using current digital technologies, not to be confused with traditional cross-platform media franchises, sequels or adaptations.
From a production standpoint, it involves creating content that engages an audience using various techniques to permeate their daily lives.In order to achieve this engagement, a transmedia production will develop stories across multiple forms of media in order to deliver unique pieces of content over multiple channels. Importantly, these pieces of content are not only linked together (overtly or subtly), but are in narrative synchronization with each other.
We are starting to see increased transmedia story telling in the movie, television and gaming industries but there is a big need to also have this in the operating systems and applications we use. The people working on transmedia today are breaking down boundaries and making continuous user experiences.
What Transmedia and Continuous Client have in common is the goal to remove the boundaries the user faces and deliver a continuous experience that transcends mediums and devices. In computer software this could be taken to an even smaller level and remove application and operating system boundaries.
The way we interact with our computer is a story. A user emailing pictures to a family member on the other side of the world is a story.
If you want someone to fall in love with your product, try to focus on the possible stories and blur the boundaries. Don’t let the boundaries get in their way. Your users will love you for it.