Monthly Archives: June 2011

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.)


Earlier this week, my wife and I finally got to see U2 in concert after purchasing tickets more than two years ago due to a mid-concert accident by Bono in 2010. I recall having a better time at the U2 concert in San Jose (Vertigo tour), but it was a good time nonetheless–could have been due, in part, to enjoying good seats… :-)

Oakland ( coliseum stadium, section 219, row 1, seats 11-12
U2360OAK is show number 94; the attendance number was approaching 63,000 at the time of this photo
U2 performing
U2 performing
U2 performing

This first video–all were taken with my Flip video recorder and uploaded directly to YouTube in HD–is Lenny Kravitz opening his act as the main opening band for U2 with “Come On Get It.”

The second video is Lenny Kravitz performing “Let Love Rule.”

The third video is U2 performing “Elevation.”

The third video is U2 performing “City of Blinding Lights.”

Thoughts on social software

Social is a popular adjective in software these days (along with cloud and mobile); so, I thought I’d capture some of how I view social in light of enterprise software and customer experience.

Footprint in the sand

When I think about “social software” I think about how experiences are impressionable (e.g. customers can leave impressions causing other direct/indirect participants to learn/benefit/dialog/collaborate). To me, “social” means allowing users to leave impressions such that impressions are mined for context and understood in context. Software that embraces this notion of sociability becomes more context-sensitive as a whole much like a piece of UI might present or hide itself depending on context (e.g. user’s role, workflow state, etc.) or a different service is invoked depending on context (e.g. SLA).

To me, “social software” isn’t about simply sprinkling social artifacts into existing systems (e.g. adding tags, ranking, etc.). It’s about ensuring that software incorporates sociability into its equilibrium as presented to customers.

One hears “less is more” and “more is more.” I find that both can be true, and the user will ultimate indicate the truth. In the case of providing more context, a user action to exclude is social to the underlying system, if that system is built to recognize it as such. That is, being exclusive is part of being social; excluding (and including) is a form of engagement. “Social software” must promote engagement–for relationship-based business benefit.

Being social can mean being friendly (i.e. sensitive to past expressions of preference, a form of context, as well current inference of the task at hand in a framing goal). A context-sensitive platform should go beyond just facilitating “one degree of friendliness.” It should anticipate the implications of deeper…collaboration. When a compelling experience and frictionless interaction is delivered to one, it can become a beacon for many subsequent experiences and interactions. So, how can this downstream effect be understood up front? How should context-sensitivity adjust, pivot, etc. to optimally understand this potential (reality)? “Social software” get this at its core.

Social is about collaboration–with purpose. To understand/infer purpose requires being sensitive to context.[1]

My definition of being social is as follows: a software system that allows any user to leave an impression, expecting that the system will recognize it, understand it and subsequently bring it to bear on the resulting experience, across space and time (i.e. same customer and/or different customer(s), immediately and/or in the future). This is just one of the traits we’re building into our enterprise platform at Adobe.

[1] For more on context, you may want to check out what my colleague Ben Watson has started over at