Tag Archives: UX

User Experience

Quantified Self

Quantified Self logo

Given the domains that I serve professionally as well as my own desire to better understand aspects of my own health, I decided to start “quantifying myself.” For the uninitiated, the Quantified Self movement involves a group of folks who share an interest in self-knowledge through self-tracking.

This post captures my initial experience using UP by Jawbone–first on iOS and then on Android (same bracelet). There are several other devices to consider; however, I chose UP given Jawbone’s BodyMedia acquisition and its platform direction.

Getting Started

Setup is a breeze and once you’re fully configured the UP mobile app cheerily greets your arrival.

You've joined UP!

Like most software types I know, I just “went for it” and didn’t first study the manual. Besides the little paper-based booklet in the box is vastly superseded by the extended user guide available online as a PDF here (English link).

Fortunately the UI is simple and inviting, and it’s worth exploring given its bias toward more gradual disclosure in context (i.e. drill-in for details, etc.).

Main panel navigation UI in iOS Main activities UI in iOS

Goals UI in iOS

If you’re missing out on something useful, the app may provide a timely nudge in the right direction. For example, since I didn’t bother with the manual, I wasn’t aware of the Lifeline view.

Insight toward Lifeline view

Becoming aware of Lifeline also encouraged my curiosity toward the Trends view.

Lifeline view in iOS Trends view in iOS

If you want to know more detail about your movement of sleep that day, just tap the appropriate colored arrow bar (purple for sleep and orange for movement).

Day's movement summary UI on Android Day's sleep summary UI on Android

The consistent use of color in the mobile app helps develop user intuition.

Slight Mobile App Differences–Same Cloud Service

At the time I purchased my UP bracelet, I didn’t have a viable Android device according to Jawbone’s device compatibility page. So, I initially used my iPhone 3GS–really just an iPod Touch, since it’s no longer used as a cell phone. Thankfully I just updated my Android smartphone to a Samsung Galaxy S4; so, I have the UP mobile app on both devices. More importantly I confirmed firsthand that the mobile app talks to a cloud service after syncing with my UP bracelet.

Notice how the Android UX differs subtlety from the iOS UX…

Main UP UI on Android

Main next-level UP UI on Android

Personally, I think that the Android UX could benefit from improved visual association where next-level pop-up panes are concerned (ala Twitter).

Main panel navigation in Twitter mobile app

In general, the Android UI is a bit more spartan than the iOS UI. The iOS UI seems a bit more playful

Sync on the UP app for iOS

For example, compared to the iOS sync experience (above), the Android sync experience narrowly focused on sync and doesn’t report summary information as a result of sync completion.

Sync (uploading) on the UP app for iOS

The Android sync experience also doesn’t feature the rotating sun and clouds animation.

However, both Android and iOS apps do feature sunburst graphics as a way to reinforce achievement.

Sunburst (animated) to reinforce achievement Sunburst to reinforce achievement

User Experience Bugs (or Features?)

There are a few UX quirks with UP that I’ve experienced in my almost-a-month worth of daily use.

First, I encountered some behavior management in the app that didn’t progress as I expected.

Example of behavior management that didn't progress as expected

While I appreciated the insight “card” encouraging me to beat my current average, once I accomplished that objective, UP didn’t refresh itself to recognize my accomplishment. Perhaps it thought that I wasn’t done being active…after 9pm. Regardless, I expected to at least have the app inform me that I actually took it up on its challenge of me. Since it did not, I may be less likely to drill into future insights, and that is unfortunate and avoidable.

The next sub-optimal experience to share involves my first attempt at what UP calls a Power Nap (see this specific alert above).

Evidence of a blown Power Nap

According to the app, it did try to wake me by vibrating the bracelet; however, I must have been tired since I didn’t wake and continued in deep sleep well beyond the time frame I entered in the app. Fortunately, I wasn’t late for anything critical, but, again, the fact that it didn’t effectively wake me as I directed UP may cause me to use that feature less in the future.

The last frustration to share was when I discovered how the activity editor deals with trimming activity duration. It appears to simply compress the data from the prior timeframe into the new timeframe, and this really makes no sense–given my use case.

Basically I realized about 10 minutes after walking our dog that I forgot to press the bracelet to mark the end of my timed activity. (I appreciate that the UP bracelet can automatically determine your transition from sleep to activity, without requiring you to manually transition the bracelet from sleep mode to activity mode.)

Time shifting inflexibilty

UP does allow you to edit your activity; so, I went into my walking data to trim off the time, bringing the end-of-activity marker in toward the last noticeable movement bar (representing a decent number of steps per minute). Upon shortening the duration, I expected to roughly the same number of steps and a marker as described (at 10:58am versus 11:06am); however, the new graph was shown with the same “lack of movement” gap before the new end-of-activity marker (at 10:58am). Distance and Steps were the same; Pace and Calories dropped.

Since UP keeps track of daily data as well as per activity data during each day, I expected UP to simply take whatever steps may have occurred in the truncated portion of the activity to apply them to the day (outside specific activities). I expected UP to reset the end-of-activity marker as I just described; however, for some reason (a bug?) it doesn’t…

More To Explore

I still have yet to leverage every feature in UP as it currently exists. For example, I have yet to use the diet features of UP–they seem to be too manual for me to give it my time.

Logging diet in UP

I need to recruit other UP’ers to my Team. Flying solo currently…

Insight into Team feature

I also need to visit the Apps experience in UP to give things like its integration with IFTTT a try. If I recall, I think that there may be a nice integration with RunKeeper, which I also have in my app arsenal. Just need to turn the integration on and lace up my running shoes…

If you, my reader, use UP or a similar device, I’d love to hear of your experience and how you’re getting the most from self-tracking. Thanks!

Update 6/17/2013: Further reading:

Integration

Integration. This word/concept similar to application, component, data, service and so many other concerns in the software realm: it’s often the case that there are N + M meanings floating around a conversation with N people on the subject. :-)

If you provide a portfolio of products to customers, integration is typically an important aspect of your offering. Do these products play well with each other? Can there inputs and outputs be combined into broader workflow, etc.?

Unfortunately I find that many integrations seems to be merely technical in nature–as if to answer “yes” to “can I technically integrate?” Much like answering “yes” to “do you know the time?” this strikes me as missing the point altogether.

Integrations must be about how should I deliver the right experience to my user. That is, integrations should be experience-driven.

So, what may be some of the signs that indicate a need for focused improvement?

  • Workflows that span across products involve multiple login experiences (interruptions).
  • Users are forced to deal with experiences designed for a persona other than their own.
  • Software concerns are not consistent and therefore are not intuitive (e.g. able to be reused spontaneously in new business contexts).
  • Integration gaps in product must be addressed via professional services, consulting or directly by customers.

Any of this sound familiar?

When I get involved in an integration-related project, I tend to think about the following layered concerns:

This approach involves:

  • an experience-driven focus on key business roles/personas and their workflows – user objective over product feature/function (seamless)
  • data and insight in context for better decisions and actions – mere hand-offs don’t add value (frictionless)
  • social as glue across users (relational) – provide others’ insights in context[1] to facilitate further insight and action

How do you view and tackle integration in your own products?

[1] e.g. http://craigrandall.net/archives/2012/09/queue-and-flow/

The Experience Architecture

In my #AdobeMAX session today, I presented a set of experience architecture principles with my colleague Marcel Boucher as follows:

I’ve gone into greater detail about these principles in a technical white paper that is available from the Adobe Enterprise Developer Center as a PDF download.

During our session, Marcel presented two demonstrations:

  1. The first demonstration featured an overall vision for customer experience in the retail banking domain. If you weren’t able to catch this demo live, you can see it presented here during the FinovateSpring 2011 event.
  2. Marcel’s second demonstration provided more of the how behind the vision in terms of Adobe’s integration across its Web Experience Management (WEM) solution, SiteCatalyst and Test&Target. A video similar to Marcel’s demonstration of this integration is available here.

MAX is always a great event, and the enterprise team at Adobe is looking forward to sharing more with you about Digital Marketing at our upcoming summit in March 2012.

What is a UX Component?

Previously, I offered some thoughts in response to “What is XOA?” To recap, experience-oriented architecture indicates an approach to solution design that is about the customer in, not the underlying systems out. I mentioned the concept of experience components in the Adobe® Digital Enterprise Platform (ADEP) as a concrete expression of XOA for Flex developers, noting that XOA is, in fact, technology agnostic.

Now, let’s talk in more detail about UX Components.

UX Component makeup

Adobe CEM applications use a component model that is oriented toward reuse across a spectrum of applications. At one end of the spectrum we have static applications where individual components are statically linked into an application. At the other end of the spectrum, individual components are placed in a catalog on a server and dynamically injected into an application at runtime. We call these “experience components”–UX Components.

Technically speaking, a UX Component is a combination of MXML and ActionScript classes that is bundled into SWC files that separate concerns and encapsulate each concern behind an interface. Interfaces make the implementation of concerns (i.e. presentation, domain, etc.) replaceable and extensible.

Technical decomposition of a UX Component

The fact that a UX Component is well-composed behind a set of interfaces, allows you to focus on the concrete implementation of familiar coding patterns productively.

For example, let’s assume that the domain model and service integration specified by Adobe for a UX Component is well-suited for your use case, but in order to differentiate your customer experience, you need to implement a custom user interface. By leveraging UX Components in ADEP, you simply focus your attention on implementing a custom view and presentation model that will leverage everything as-is:

UX Component pattern: custom view and presentation model

Another common requirement involves integrating existing systems into new customer experiences. Depending on your use case, you may be satisfied with a UX Component as provided by Adobe. So, you need only focus on implementing a custom façade to ensure that customer interaction with your experience is integrated with your existing infrastructure:

UX Component pattern: custom application façade

Here is an example of a UX Component:

Example UX Component

At the top is a logo component and a navigation bar. The left column has a calendar, and the right column has resources finder and a document viewer. Each of these components are very generic displays of information. For instance, the project calendar is a graphical list of items, actually a tree of items that is rolled up into a Gantt chart. Each of these items has a start date, finish date, phases, a current state shown in color and descriptions.

A UX Component is completely independent of its data source. Simply by injecting a data source at runtime and providing a different skin, a different application experience can be delivered:

Previous UX Component with new look and feel

Here is the same calendar UX component, with a new skin and a new data source. This shows a charcoal theme, and the data is a product development plan rather than a marketing plan. The renderer for each of the items now shows the phases of the project as colors in the bar.

By creating a well thought out UX Component, where concerns are inheritable, skins are replaceable, and services are injectable, ADEP enables you to achieve a high level of reuse while providing both richness and consistency in the experience.

More on ADEP‘s Composite Application Framework (pka Mosaic) and Client Component Framework (pka Gravity) in future posts…

Update 7/6/2011: “What is the Client Component Framework?

What is XOA?

XOA stands for experience-oriented architecture. XOA was first coined by Adobe’s Steven Webster “to very specifically mean applying design thinking to evolving an architecture stack, and more recently, to talk about instrumenting an experience in order that it can be measured and monitored as delivering against intended KPIs.” It is therefore incorrect to reduce XOA down to component development. At its heart, XOA embodies best practices for RIA development, whether in the browser or on the desktop.

In the (just-announced) Adobe® Digital Enterprise Platform, XOA manifests its RIA best practices via layers (concerns) as follows:

  • Presentation – view rendering
  • Domain – client-side computations, abstraction of server calls, etc.
  • Infrastructure – server communication

XOA is an architectural approach and is not bound to a particular technology (e.g. applies to Flex, HTML5, native mobile, etc.). XOA is certainly not meant to be a formal label–just like you wouldn’t expect to see “SOA” in XML, etc.

This layered architecture [1] provides an efficient way of segregating the code related to view rendition, client side computations, perpetual asynchronous communication, etc. Embracing such separation of concerns enables ADEP development projects to be easier to understand and to manage. Moreover, it helps developers with different personas to work in tandem on a component (e.g. the UI developer in concert with a business logic developer).

Example of applying XOA to ADEP-based Flex development: Enterprise Flex components (aka UX (User Experience) Components) are mostly data-driven with data synchronizing from a backend server over Remoting, Data Services, etc. With data coming from server in an asynchronous fashion and component assembling itself by computations, the complexity increases manifold since the component, apart from rendering itself also needs to construct itself. Therefore, it becomes extremely important to separate concerns before the component development turns unmanageable. However, please keep in mind that XOA is about much more than component development as noted above.

For example, a UX Component in ADEP is an enterprise Flex component that embodies XOA principles.

More on UX Components and other aspects of ADEP in future posts…

Update 6/30/2011: “What is a UX Component?

[1] You may recall that I spoke about XOA during my MAX 2010 session, “Realizing great customer experiences with LiveCycle ES3.” (ADEP replaces “LiveCycle ES3.” ADEP is the new brand that incorporates aspects of LiveCycle with aspects of the Day Software aquisition.)