Posts in Category "Innovation"

Webinar on “Intuitive User Experiences”

On Wednesday 28 April, at 11am PT, I’m co-presenting with Ron Rogowski of Forrester Research on “The Value of Creating Intuitive User Experiences”. This online webinar will focus on the approach to creating user-centric applications, and the business value that emerges from intuitive user-experiences.

During this presentation, I’ll be talking about a project my team have been responsible for delivering over the last year, that is internally code-named “Hendrix”. This has been a tremendous collaboration within Adobe, bringing together our TXI team of technologists and user-experience designers with our IT organization, leveraging our 3D methodology for blending user-centric design thinking with agile software engineering, and in turn, creating an application that allows our agents in our contact centers to more effectively service Adobe customers – to help more customers, first time in less time. Every time.

Project Hendrix is something I am very much looking forward to talking more and more about in the days, weeks and months ahead…the business problem we were tackling (which has resonated with a tremendous number of customers to whom I have shown Project Hendrix in Customer Briefings in San Jose), the 3D approach we took to really understanding user needs, and how meeting user needs could meet business goals, as well as getting deep and dirty with the technical details of how we delivered an Experience Oriented Architecture … a tremendously complex implementation of a beautifully simple user-experience that leverages Adobe technology throughout the technology stack to attenuate the complexity of underlying systems such as our SAP CRM system.

It’s incredibly rewarding to have the project going live to our agents, and to be able to begin to talk about it with designers and developers, customer and community, and with the industry at large.

Sign up for the webinar here.

Deliver: Agile Execution aligned to Innovation

Previously, I spoke about “Discover, Define and Deliver” as the 3 Steps to Innovation upon Adobe technology. When describing this “3D Methodology” to customers, I find it’s easiest to start with that which is most familiar – Deliver – and then work back towards the value of Define and Deliver. When all is done, when the observations and insights have sparked an idea for innovation, and the innovation has been distilled into concrete requirements and designs, the Deliver phase is about bringing it all to life. It’s about breathing life into a design, lifting it from paper concept to production code. Deliver is primarily about writing code, pushing it through Quality Assurance and into production.

Deliver is agile…

Wherever possible, the team at Adobe advocates Agile development – and more specifically we advocate Scrum as our methodology of choice. This is indeed consistent with many of the product engineering teams within Adobe, as we more broadly embrace agile and Scrum within Adobe.

Formerly, I was an advocate of XP (Extreme Programming), but laterally, as more of the industry appears to embrace Scrum, as more of our customers embrace Scrum, and with more training and accreditation around the Scrum process, the differences between XP and Scrum are too trivial to matter. That previous link to Mike Cohn’s article highlights “Scrum doesn’t prescribe any engineering practices; XP does” … that being said, we very much advocate and encourage the practices of XP, whether it be coding standards, pair programming, unit-testing and test-driven development, continuous integration, and our teams are continually pushing the state of the art by contributing to tooling to support them, whether that be FlexUnit, FlexPMD, FlexPMD plug-ins, integration with Hudson, etc.

Prototype and Test == Release Early and Often

Throughout the 3D methodology, we strive to create the right environment for innovation. One particular trait of innovation is the ability to prototype and test; one particular trait of agile is release early and often. I think there’s a relationship between the 2 that is interesting.

Tom Kelley of IDEO talks about prototyping as “the shorthand of innovation”. I’d highly recommend reading that article, itself an excerpt from what we consider to be Adobe Technical Services required reading, “The Art of Innovation”. But within Innovation thinking, the importance of getting a working prototype in the hands of users, as a means of creating the opportunity to observe and feedback into the design, is very much established thinking. The team over at IDEO are tremendous at leveraging prototypes in their product design process; there’s a definite opportunity to embrace this kind of thinking and approach in the software product design process.

Within Adobe Technical Services, we will often prototype INCREDIBLY early in the process — oftentimes before we’ve even really undertaken a concise requirements gathering exercise. Prototypes are often deliverables from our Discovery phase, opportunities to explore hunches and insights, to play what-if with customers, or indeed even ourselves, and to stretch our own thinking about how some of the business needs, user goals and technology opportunities could come together in imaginative ways. We create incredibly high-fidelity prototypes, very quickly, either with Flash, with Flex or increasingly with Flash Catalyst…however, these vision prototypes really only take us on a “happy path” through the application. This kind of vision prototyping differentiates us from many others that we work with, and so I plan on talking about this in much more detail over another series of entries.

However, if you consider the agile process of delivering functionality in discrete time-boxes (what XP calls iterations, and Scrum calls sprints), then you recognize that each sprint affords us an opportunity to spin out a prototype that we can test. It takes courage on the part of the customer and the team, to challenge our own assertions mid-flight and to be prepared to course-correct upon learnings. But agile methods embrace change during development; and so the very engineering methodology that empowers us to prototype and test regularly through the development cycle, similarly empowers us to embrace the learnings straight back into the product design, during the manufacture of the design itself (which is in essence, the Deliver phase).

Deliver doesn’t have to be agile…but it helps…

We don’t always follow agile within Delivery, but ad-hoc is never an acceptable alternative. Oftentimes we will lead the delivery phase of projects with an Adobe team, but more likely we will be working alongside our customer’s development team or our ecosystem of Adobe partners. Agile approaches – stories as currency of requirements, feature-driven development and sprints of functionality prioritized according to business value – have proven to be a tremendous means of achieving technology and business domain knowledge transfer; I’d be interested if you have found the same also?

Summary

So when we get into the Deliver phase, we’re really in the midst of a software engineering lifecycle…there’s ongoing user-experience design for sure, but really the bulk of the experience is locked and loaded, in the backlog and ready for implementation. We definitely find that agile methods are conducive to innovation methods in the product design and manufacture, and so advocate them wherever possible. We definitely find that the engineering methods popularised by XP, and more widely embraced by the agile community, are as relevant to development with Adobe technologies as any other, and whereever possible we are contributing to and pushing the state of the art on the tooling to support agile engineering.

Most of the knowledge that we have to share in the Deliver phase comes from the tools, methods and best-practices particular to the technologies we are using, rather than the process or methodology we are using. Many of my colleagues are sharing this information in their own blogs and articles, and I’ll seek to reference them more in future entries.

However, as we push back into the Define phase, where a user-experience moves from concept to idea and to implementation, where we ensure that user-experience designs are satisfied by business and functional requirements and vice versa, where the real collaboration and magic happens between designers and developers, then I think we have a little more insight to share.

And so that’s where I’ll go next, with a similar overview of the kind of challenges we address in our Define phase. I’d love to hear what challenges you’re facing, how and whether you’ve addressed them, so that you might steer the direction of dialogue. By releasing these thoughts early and often, I have the opportunity to evolve them to meet consumer needs…!

3 Steps to Innovation with Adobe Experience Design and Technology

Through a series of posts, I’d like to share ever increasing detail in how the technical services organization within Adobe – comprising user-experience designers and technologists from technical sales and solutions engineers to consultants – consistently approaches the ideation and implementation of solutions upon Adobe technology. Each solution that we innovate follows 3 steps, which we call our “3D Methodology” – Discover, Define and Deliver. Over a series of entries, I’d like to elaborate on each of these steps, as a prelude to sharing more deeply some of the best-practices that have emerged for us from repeated application of our approach.

When I describe “Discover, Define, Deliver” to customers and partners, I find it easiest to describe it from the back to the front…and so this is how I’ll introduce each phase over the coming days:

Deliver: Agile Execution aligned to Innovation

When all is done, when the observations and insights have sparked an idea for innovation, and the innovation has been distilled into concrete requirements and designs, the Deliver phase is about bringing it all to life. It’s about breathing life into a design, lifting it from paper concept to production code.

I’ll talk more about agile development, the adoption of Scrum, and the traits of innovation methods that I believe align with traits of agile software development methods.

Define: where Requirements inform the Design, and the Design informs the Requirements

The industry has long accepted the fate-sealing that occurs when a project commences development/delivery before requirements have been adequately specified. In the 3D methodology, the Define phase commences when we feel we have gained enough insight and observations about user-needs, technology opportunities and strategic business drivers, to have a solution set of opportunities that can be elaborated with the customer into a set of business requirements.

I’ll talk more about design-led innovation, about how we bring together user-experience design methods with agile software development, and resolve tensions that so many of our customers and partners seem to face when bringing design and development teams together. In other cases, we find that there is tremendous lip-service paid to the design process … it’s something we feel strongly about, and dialogue we look forward to entering into in this forum.

Discover: gaining the Insights for Innovation

If Define and Deliver answer the question “how do we build things right’, then Discover answers the question “how do we build the right thing”. In our discovery process, we very much embrace innovation techniques and user-centered design methods that uncover the critical insights that ignite the spark and uncover the soul of an application. In the discovery phase, it is our goal to construct a portfolio of ideas to inform the very requirements that we collect with our customer to gather. These insights come from observation of the very individuals for whom our solutions will be in service.

I very much look forward to sharing our thinking and approach, the tools that we use, the assets that we create, the workshops that we facilitate and the philosophies that guide us in truly stepping back and challenging not just the solution, but the problem itself.

The 3D Playbook

We’ve captured this methodology as a series of individual plays in our “3D Playbook”, a social platform for capturing best-practices in how to set up for success. Should a project wish to, each phase of discover, define and deliver can be followed “by the book”, giving project teams clear guidance on the sequence of workshops, activities and deliverables. Alternatively, a project can be less prescriptive, but embrace the best-practices and philosophies that the plays are there to support, cognizant of the consequences of the plays that are being passed over.

I very much look forward to dipping into our playbook, and sharing with you our approach, the tools we use, the techniques we apply, and the lessons and learnings that we try to pass from one team to another at each stage in the innovation lifecycle.

Summary

We fundamentally believe that solutions delivered upon Adobe technology can establish the state of the art, can set the bar, where the technology is a medium and a means to an end, rather than simply the end itself. If Adobe technology is necessary but not sufficient, then sufficiency comes from the introduction of Innovation, and Innovation is Design-led.

Innovation doesn’t happen “by the numbers”. However, the environments that must be created, the individuals that must be engaged, and the insights that must be gained, can be sequenced and repeated. The practices can be repeated, and the best of these practices can become best-practices. Discover can yield insights for innovation, Define can bring the design and engineering disciplines seamlessly together and Delivery can assure a consistent execution with engineering best-practice.

I’m very much looking forward to sharing in this thinking, and entering into broader dialogue with our customers, partners and community about where we can share more, and what we can learn from the successful implementations that you are each responsible for delivering.

What else can we share ? What do you have to share with us ? Where do we begin ?

Welcome to TXI

It’s somewhat of a habit, to post a blog entry with a leading apology for how long I’ve posted a blog entry…over a year in this case. However, it has been a tremendously interesting year at Adobe, building a team called “TXI” (Technology and Experience Innovation) of Technologists and User Experience Designers to deliver on a common belief that the most innovative and effective applications of Adobe technology, are the fusion of great user-experience design and great technology implementations.

You’ll know many of my team already, from the work they have already shared with the community — whether it’s technologists like Alistair McLeod, Peter Martin, Paul Barnes-Hoggett, Yaniv de Ridder, Francois Le Droff, or user-experience designers like George Neill, Jerome Doran, Kalle Korman, James Mellers or Dusty Brown. Along with their numerous other peers spread in our team from Romania to California, this team is responsible for really driving the state of the art in “what’s possible” with Adobe technology and design. In many instances, it’s in the solutions that we deliver for Adobe’s most strategic customers, in other instances it’s working with our partners and system integrators to help drive that thinking into their solutions, and in other instances still that team faces inwards, creating the applications and experiences that allow Adobe to better serve our ecosystem.

Along the way, we’re continually evolving how we think about bringing designers and developers together. We create tools, we derive techniques, we adapt software development methodologies like SCRUM to user-centered design techniques. We find ourselves deriving recurring patterns, whether these be software patterns, technology best-practices, or user-experience patterns that can improve interactions from one problem domain to the next. And it all culminates in the work the team delivers, and is proud of delivering.

I am missing an opportunity sharing our thoughts as we go, and collecting your thoughts along the way. And this is a tremendous vehicle for doing so.

There’s 4 things I care most about when I think about creating best imaginable experiences:

I care about Adobe technology; I truly believe that the phenomenal work of our product teams gives us the fabrics, the materials, the tools and the techniques to carve the most aesthetic, most effective and simple experiences, as abstractions to the most complex, robust and scalable enterprise solutions. And the more our technology platform matures, the more the world shifts to software that works the way people work, not the way systems work, the more experience matters, then the more I get excited about the opportunities we see not just to create effective veneers upon complex enterprise systems, but the more I see incredible integrations between our platform technologies and run-times, our creative products in the enterprise, our video and media products. Enterprise workflows, creative workflows, the seamless blend from virtual to just-in-time manufacturing, the production, protection and monetization of interactive media content, all present an incredible array of technologies from which to craft and carve solutions.

I care about Technology. More than just Adobe technology, but trends, directions, innovations and opportunities. Innovation is so often a product of cross-pollenation; taking ideas from one ecosystem and germinating them in another. Tracking trends and innovations in the wider technology ecosystem is the manner by which we ensure that we have the most advanced bricks and mortars to bring experiences to life; and as the materials we work with evolve, that in turns informs the experiences we are able to deliver. Design informs technology, but technology can also inform design.

And I care about Design. More than anything else. Technology is in service of the user, the customer, the citizen … it is necessary but not sufficient. Adobe has an incredible community of designers and creative professionals, and an incredible community of developers and engineers. The consumerization of IT, the trends in the industry from system centric to people centric applications, all bring mass market realization to the importance of Design in the software development process. This is something we are incredibly passionate about…we believe that design and development is a handshake, not a handover, and our people, our skills, our tools, our processes and our methodologies have evolved to bring these disciplines together (but not to create “devigners”, an inmate in disguise who still pulls strings in the day to day running of the asylum).

And all of this ? Adobe products, Technology trends and Design thinking ? To me, they are in service of Innovation. For that is what drives us, that is what keeps this team ticking, that is why customers engage us, why partners listen to us, and why in turn we enjoy immersing ourselves in our customers business, walking in their customers shoes, and understanding our partners opportunities. By bringing together our technology and design, we have an incredible opportunity as an industry to Innovate.

How can that not be exciting ?

So being the things that we care about as a team, these are the things we care about sharing. And in return, we hope to learn as much from you in return.

Where do we start ?

Natural Language Mashups with Ubiquity

So you fire up your browser, you type "Book a flight to Chicago next Monday to Thursday, no red-eyes, the cheapest. Then, email my friends the itinerary and add it to my calendar". Your browser responds with:

This is the aim of the Ubiquity project at Mozilla, which aims to parse natural language queries to create on-the-fly mashups. In the words of the Mozilla team, it’s about "connecting the Web with language in an attempt to find new user interfaces that could make it possible for everyone to do common Web tasks more quickly and easily." This is a tremendously exciting idea.

In Web 2.0, the idea of a "mashup" is very static…though we can create services that are themselves compositions of micro-services available over the web, our final service is somewhat static, in the sense that our mashup is specific to the intent of the developer that created the mashup.

Projects like Yahoo! Pipes have tried to make it easier to create mashups more "on the fly", by creating a way of graphically orchestrating disparate web-service calls.  This is a very similar approach to the "enterprise orchestrations" that can be created with LiveCycle Process Management ES which allows us to graphically orchestrate pre-supplied and custom services into enterprise business processes.

However, as much as Yahoo Pipes may make it easier to create a mashup, the resulting service, despite being a composition of several disparate services, is still static, in the sense that it is only fit for its single intended purpose ("Fetch me the New York Times business stories from the RSS feed, and show me Flickr images alongside each story, with links to Forbes.com profiles for any companies or people mentioned in the story.")

What I love about the vision behind Ubiquity, is that it aspires to offer the most simple, easy and effective of user-experiences – a natural language query or imperative – while "behind the glass" have the most complex of dynamic orchestrations from a catalogue of known or discoverable web-services. Much like Tivo, or purchasing music while sat in your sofa with your wireless iPod, this has all the opportunities of seeming like the easiest transaction to offer, truly hiding the end-user from the smarts, the intelligence and the complexity required in silicon and code to make it happen.

Get this project working effectively, put speech to text on the natural language query, and this gets even more exciting…

Check out the project at http://labs.mozilla.com/2008/08/introducing-ubiquity/

AC@MAX on "Architectural Best Practices for Flex and LiveCycle ES Applications"

Since MAX 2004 in New Orleans, I’ve presented to one extent or another around the theme of architectural best-practices for delivering enterprise applications upon Adobe technologies.  This year is no different, and I’m very much looking forward to presenting with one of my colleagues from our Chicago Office, Tunde Turner, on our collective experiences within Adobe Consulting in delivering Enterprise Rich Internet Applications that leverage Flex and LiveCycle ES.

In previous years, I’d like to think that we illuminated many ideas around software architecture as it would apply to Rich Internet Applications, through presenting and contributing around the Cairngorm Framework for Rich Internet Applications. What I aspire to achieve in Tunde and I’s talk, is to help Rich Internet Application developers take the complexity and scale of their applications to new levels, by understanding the class of recurring problems where Flex, LiveCycle Data Services and LiveCycle ES play strongly, and the patterns and practices that recur in architecting these solutions.

A theme I introduced at MAX last year, during both the Chicago and Barcelona keynotes, was the idea that combining Flex and LiveCycle allowed us to "create innovative experiences on both sides of the glass".  I’ve continued to use that metaphor in helping customers understand the value that Adobe technology can bring, and indeed this is baked into the way Adobe Consulting help customers conceive of innovative solutions, and it’s baked into our go-to-marketing message (you can hear more about that message in the video at the foot of this page linked here ). 

Tunde and I aim to re-introduce this concept of creating innovative solutions "on the glass" and "behind the glass", to show some stunning examples of this metaphor applied, and to use this as the highest-level of abstraction for discussion around microarchitectures for Enterprise Rich Internet Applications.

On the Glass

On the glass, we’ll definitely talk about architectural best-practices for Flex and AIR development; we’ll take a brief tour of Cairngorm, explore some of the emerging ideas around Cairngorm and how a Cairngorm application can logically extend it’s reach towards an enterprise back-end with LiveCycle Data Services and LiveCycle ES.

On the glass, we’ll also look at some little appreciated features of LiveCycle ES – the Workspace and FormGuide APIs that allow us to create Rich Internet Applications for review and approval patterns, and for data capture patterns of user-experience.

Behind the Glass – Data Oriented Architectures and Microarchitecture Pattern Catalogues

Where things get really interesting however, is when we start to reach behind the glass.  A key consideration which I urge development teams to consider, is whether an application is a service oriented architecture or a data oriented archtiecture.  I will explain this consideration in detail – as to me this is a compelling reason to understand the best-practices between Blaze DS and LiveCycle DS that are often, naively, and incorrectly, reduced to "do you require data push".  Tunde and I will then spend some time exploring the Service Oriented Architecture view of LiveCycle ES, and the manner in which we can invoke services within the LiveCycle ES container, and what that actually means.

For Rich Internet Application developers, we’ll present a service-oriented view of LiveCycle ES, and help you to understand the different services that are available that I’m confident you’ll have spent far too much time in Java in the past trying to implement simplified versions of yourself.  We’ll show the rapid-development model offered by LiveCycle ES, and then identify patterns of applications that consistently leverage the same solution components and services of LiveCycle ES.

Microarchitecture Patterns

I’m confident that the idea of "microarchitecture patterns" will be the most significant contribution from this presentation; and that it will offer the same "Eureka" moment that Cairngorm offered many RIA developers.

Think about this – in Cairngorm, we identified a recurring application problem ("a Rich Internet Application sitting upon a service oriented architecture") for which we identified a network/collaboration of design patterns that became the Cairngorm microarchitecture. 

As our applications reach even deeper into an enterprise, and we concern ourselves not just with the architecture, patterns and practices "on the glass", but the architecture, patterns and practices "behind the glass", then there are recurring patterns of application:

  • RIA that results in a document being processed through an organisation and generating some final paper output, eg Applying for a Credit Card and getting your welcome pack and confirmation letter in the post
  • RIA dashboard that tracks an approval process, eg Loan or Mortgage Approval
  • RIA dashboard for real-time high-volume data, eg Trading Platform, Instrumentation Dashboard
  • RIA that captures information that needs to be secured and archived, eg Clinical Trial Management, Filing of Crime Reports
  • RIA application that configures electronic documents that are then pushed through a high-volume printing process, eg Electronic Statements, eBanking

As we consider the different, yet recurring, suites of services that these application types might consume, as we consider the different ways in which we engage through custom RIA development, through Form Guides and Workspace component suites in Flex, leveraging AIR and PDF for offline data capture or as the tool for moving information through an organisation, we are in effect identfying a series of microarchitectures that are larger networks of patterns than Cairngorm, microarchitectures that span both sides of the glass.

In essence – if Cairngorm was one microarchitecture for RIA upon a generic Service Oriented Architecture, we have yet to expose you to our microarchitectures for RIA upon Data Oriented Architectures, and RIA upon service and data-oriented architectures that focus on document-centric, form-centric, workflow-centric applications where people engage in business processes, where the digital and paper worlds collide, and where a significant number of enterprise problems exist.

Tunde and I look forward to broadening your vocabulary of microarchitectures to consider these different classes of Enterprise RIA!

Beyond Microarchitecture Patterns to Solution Accelerators

There’s a natural next step here; there comes a point where if you’re continually applying a particular microarchitecture that spans both sides of the glass, that the recurrence isn’t jus technical recurrence, but recurrence in the business requirements, from customer to customer, from enagement to engagement.  This next, higher, level of abstraction is what we call a solution accelerator – and I’ll be talking about solution accelerators in a separate talk at MAX with another colleague from Ottawa, Danny Saikaly.

So my question before we finish (ahem, start) the slides….are there recurring patterns of Enterprise RIA that you are developing, that span both the client and the server-side, that require consistency of approach from engagement to engagement on both sides of the glass ?

Innovative Mashups: Meatware + Hardware + Software

There’s a tremendous article on the BBC showcasing an upcoming television program, that encapsulates so much of what fascinates me right now as mashups don’t just focus on bringing together different online data sources, but take real-world information, whether that be people or things, and bring that information into software applications.  What’s even more interesting, is how this in itself creates an "architecture of participation", a suite of data that can be visualised over time, and from which insights can be gleaned that themselves may lead to innovations.

"Britain from Above" will be first broadcast in the UK on Sunday 10th August, at 2100 on BBC One, and features some stunning visualisations of data captured and overlaid on Britain itself.  In this short video clip on BBC iPlayer (I’m not sure if this will be geo-locked to the UK or not) you can see some tremendous examples:

  • Watch the shipping channels through the straits of Dover; satellite imagery overlaid with all of the day’s shipping as a computer visualisation
  • Watch every flight in and out of the UK, flying through stricly controlled air corridors, and observe where and when the most "stacking" of flights occurs waiting to come into land

I think the examples that I find most intriguing however, are the GPS tracking of London taxi-drivers; the drivers leverage the main thoroughfares, but as congestion begins to peak, you can observe the myriad of rat-runs and short-cuts that emerge through the backstreets of London.  Many SatNav companies are now starting to track this data to offer different recommended routes from A to B according to time of day and historic data.  What’s fascinated me for some time however, is how cars themselves become packets of data on real highways, communicating their recent journey segments, weighted by the collective opinion of other cars who have also passed the same routes, so that the network of cars themselves communicate route congestion much like ants communicate as they pass each other in lines, or other redundant networks are able to intelligently record, replay and re-route to avoid congestion.

I first encountered this idea of smart networks a loooong time ago when writing my University dissertation on "The Enabling Technologies of the Trunkl Network" (a dissertation that discussed some technology called ADSL that might become popular  in the last-mile of the copper telephone network amongst other things) amongst a myriad of British Telecom research papers around "Intelligent Networks" and intelligent switching and routing of traffic for video and audio.

The final example in the above clip is of the way "London wakes up" by visualising the patterns of telephone calls that take place in the UK.

Increasingly as I meet with customers around strategies and visions for the future, there’s ever more desire to create architectures that can bring real-world information into online applications, whether that be for improved visualisation to support real-time decision making, or physical information that can be combined seamlessly with rich and interactive applications. 

When we talk about Rich Internet Applications, we consider not only visually-rich or interaction-rich, but the richness of data.  When we think about creating architectures of participation where the wisdom is not just gathered from the crowd, but from the accelerometers, the GPS transceivers, and the myriad of other sensors that attach hardware to meatware to software.  An example I often use that really embodies the idea of hardware, connected to humans, that leverages a software architecture through which a data and visualisation and interaction rich experience can be delivered, is the NikePlus collaboration with Apple and iPods.

In your experiences, are there other applications where "meatware + hardware + software" is a recipe for innovative visualisations, data platforms, or overall digital experiences ?

 

AC@MAX2008 on "Television on AIR – Creating Custom Media Player Experiences"

Adobe Media Player

Increasingly, our user-experience and technology teams at Adobe Consulting have been engaging in projects that not only leverage Flex, AIR and LiveCycle ES to create enterprise/business Rich Internet Applications, but in projects that leverage technologies like Flex and AIR "on the glass" with "behind the glass" technologies such as Flash Media Server and Flash Media Rights Management Server, in order that we can create innovative broadcast experiences that will be experienced by millions of eyeballs at a time.

Xavi Beumala (Adobe Consulting, London) and John Bennett (Adobe Consulting, Boston) have both been engaged in a number of these exciting projects over the last several months, and between them will be responsible along with their colleagues for the technical delivery of products that I’m confident many of us will be consumers of in the months ahead.

In the first instance, creating a custom media player is about creating an online experience that is more compelling than experiencing the content on a television. John and Xavi will talk about how some of these innovative features can be implemented on the Flex and AIR platforms – whether that be building social communities over the content itself, or more innovative ways of engaging with more innovative online content.

However, fundamental to a great broadcast experience is everything focussed around delivering the highest-quality of viewing experience.  With the H.264 capabilities of the Flash Player, there is ever increasing desire to deliver the highest-definition of quality, which in itself creates recurring technical challenges that must be considered and addressed.  Whether it’s considering encoding and codec tradeoffs, picture size optimisations, bitrate and bandwidth requirements or architectures for content delivery networks,or whether it’s understanding the workflows that allow the secure delivery of rights-managed video, there are a myriad of technology and application decisions that need to be made that can have impact on the overall viewing experience.

Drawing upon real-world experiences of implementing several television experiences online, I’m looking forward to the best-practices and deep technical-tips that I know Xavi and John will have to share.

Session Details:

Television on AIR: Creating Custom Media Player Experiences

Join Adobe Consulting for a discussion on projects in which broadcasters and media organizations needed applications to stream protected video to consumers desktops. Learn how to create these experiences using dynamic media technologies. Hear Adobe Consulting best practices for Flash, Flex, Adobe AIR, Adobe Media Player, Flash Media Server, and Flash Media Rights Management Server.

Speakers: Xavi Beumala Segura, John Bennett
Audience: Creative Designer, Architect, Application Developer
Skill: Intermediate
Products: Flex, Flash Player, Flash Media Server, AIR
When:
Monday, November 17, 11:30 am – 12:30 pm

AC@MAX2008 on "Lazy Innovation"

Success is a Journey, not a Destination.  So stop running.

 

In the days ahead, I’d like to summarise each of the presentations that the Adobe Consulting team are giving.  I’ll start today with one that I’m most looking forward to from our User Experience practice, titled "Lazy Innovation". George Neill and Jerome Doran are experience architects within our User Experience practice, in Edinburgh and San Francisco respectively.  The title of the presentation arose from George’s observations during what we call "User Experience Discovery".  In "User Experience Discovery", we engage in many UX practices including ethnographic research and user-interviews, where we seek to better understand the end-users of our application as a means of informing the design of the user-experience itself.  Before our technical practice concern themselves with "building things right", our user-experience practice concern themselves with the more fundamental question – "are we building the right thing ?".

George provocatively contests that a human-train often considered a bad behavior – laziness – is actually an inherent human behavior that should be recognised as a virtue that can identify opportunities for innovation in user-experience design.  It is his belief that the "search for laziness" and the ability to learn how to better observe laziness can create short-cuts to finding the opportunities for innovation that exist every time we are given the opportunity to create more innovative user-experiences.

In their respective roles, George and Jerome have touched most if not all of the rich internet applications developed within the Adobe Consulting stable over the last several years, and so in this presentation they’ll be using their own work and the work of our team to show where identifying and incorporating the inventiveness of the lazy users results in simpler, easier and more effective applications.

Over the next few weeks, I’m going to interview our MAX speakers around their chosen topics of presentation, so if you have any thoughts on this idea of "innovation through lazy design" then please leave them in the comments, and I’ll ask the guys on your behalf.

I can’t wait to attend this presentation, which I know is going to be as fun and entertaining as it will be informative and inspirational; it’s a really exciting theme through which to weave a showcase of user-experience from our team.

Session Details

Lazy Innovation: Strategy for the Design of Innovative User Experiences

When engaging with applications, users essentially want to complete their tasks with a minimum of difficulty and friction. In this entertaining presentation, the Adobe Consulting User Experience team will explore this "doctrine of laziness" as a means of identifying opportunities for innovative user experiences.

Speakers: George Neill, Jerome Doran
Audience: Web Designer, Creative Designer, Application Developer
Skill: General Audience
Products: Flex, AIR
When:
Monday, November 17, 11:30 am – 12:30 pm