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.
- Responsible benchmarking
- Understanding hardware still matters in the cloud
- The “network partitions are rare” fallacy
- Messaging and event sourcing
- Further reducing memory allocations and use of string functions in Haywire
- HTTP response caching in Haywire
- Atomic sector writes and misdirected writes
- How memory mapped files, filesystems and cloud storage works
- Hello haywire
- Active Anti-Entropy
- Lightning Memory-Mapped Database
- Write amplification
- Amortizing de-duplication at read time instead of write time
- LevelDB was designed for mobile devices
- AMQP and wire format interopability
- Convergent Replicated Data Types
- Configuration is bad but what about operational flexibility?
- An alternative to Paxos, the RAFT consensus algorithm
- Version tolerance and accidental operation complexity
- Hardware configurations can introduce tight coupling and increase failure foot print
- November 2013
- October 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013
- January 2013
- October 2012
- September 2012
- August 2012
- May 2012
- April 2012
- February 2012
- January 2012
- December 2011
- September 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010