Good morning, and thank you for taking the time to join us f por “building future-friendly experiences”
10:00-10:05 1. Intro to ISITE, Gene, and the topic10:05-10:10 2. "Future Friendly Experiences" defined10:10-10:15 3. Why to: Business benefits of a future-friendly approach10:15-10:20 4. How to: What a responsive design strategy looks like10:20-10:25 5. Mobile web vs native apps10:30-10:35 7. Retrofitting existing websites?10:35-10:55 8. Q&A
First off, a little bit about us: ISITE: digital agency for brands who differentiate on customer experience. What does that mean? Anecdote re: keeping customers happy vs. acquiring new ones
director of mobile solutions, brought on to expand capabilities.Really about shifting focus, broadening to include an updated universe of devices and contextsI also run our Labs initiative. Mission of labs is to surface and explore opportunities to use new technologies in ISITE projects
So, why are we here today, and how did we get here?History of the web has been inextricably linked with the history of computing – browser-based content has grown up around advances in the PC, and all other “internet”-based content has been arguably peripheral mobile is a ground-shift away from the traditional “computer” as the organizing context for internet-based contentinteresting from an evolutionary standpoint that the phone has led this charge, but ultimately, phones are just the beginning as more devices become “smart”, more form factors for internet-based data will become “normal” more commonly-accepted paradigms for interaction with internet-based data means more UX paradigms to understand and master in a way, we’ve been getting a free ride because of technical constraints now that data is “everywhere”, it has started expressing itself everywhere expanded capabilities variety of output formats “device” is getting to be a pretty broad term cars appliances stereos internet-enabled everything in the short term, proprietary rules for data interchange and display win out in the long term, standards will rule, but if the browser wars have taught us anything, it’s going to take a while to get there, and could get ugly
A huge hat tip is due to some genuine web luminaries, including Jason Grigsby, Luke W, Jeremy Keith, Brad Frost, and a bunch of others...for giving a name and a face to a massive trend that’s been growing and taking shape for some time.The story apparently involves a mansion in the Tennessee woods and a space helmet and some other details, but the important output of their session was a manifesto of sorts: Disruption will only accelerate. The quantity and diversity of connected devices—many of which we haven't imagined yet—will explode, as will the quantity and diversity of the people around the world who use them. Our existing standards, workflows, and infrastructure won't hold up. Today's onslaught of devices is already pushing them to the breaking point. They can't withstand what's ahead. Proprietary solutions will dominate at first. Innovation necessarily precedes standardization. Technologists will scramble to these solutions before realizing (yet again) that a standardized platform is needed to maintain sanity. The standards process will be painfully slow. We will struggle with (and eventually agree upon) appropriate standards. During this period, the web will fall even further behind proprietary solutions.In addition to this, they proposed a preliminary set of examples of what they call “future friendly thinking” – we think the name fits, and are happy to live and breathe these philosophies as we go forth and build
So, is that a problem, or an opportunity?Yes.As I said, Guiding thoughts: -- tactics that add up to a sound strategyFFLY's "laser focus" and "customer experience" -- focus experiences rather than trying to shoehorn every experience onto every deviceThis focus on the “Experience” first will come back as we explore methods of designing for a multitude of device targetsFFLY's "orbit around data" -- all "apps" are but interfaces to common data stores, and should be interacted with via standardsThis is really the kernel that will enable downstream interoperability – regardless of which clients data is ultimately targeted towards, its liberation from platform silos is a necessary stepThis is where much of the “apps are dead” argument comes from – “native apps” tend to lock data in single-app silos, relying on a variety of non-standard ways of getting at it. [Scott Jensen article re: evolution of smart devices and content, and the app deck as a “swamp”]FFLY's "universal content" -- consider how content flexes. REALLY consider what's important. Determine the hierarchy of content inclusion/exclusion from device to deviceFFLY's "unknown vessel" and "fleet" -- and the importance of "capability groups" -- touch, screen size, GPS, etc -- and focusing each experience on what its target device set does bestAs we’ll see, grouping by capability and treating each category of devices respectfully is more in line with experience-first thinking
So, it’s clear from these conceptual examples that there’s both a great degree of opportunity associated with the current shifts, and a hell of a lot of work to be done.With value-driven organizations, this always raises the question of cost and benefit, and we wouldn’t be doing our jobs as consultants if we couldn’t elaborate both.On the benefit side, we can outline benefits to business, but they ultimately all are subordinate to customer benefits, which we’ll elaborate shortly: - broader reach – and more to the point, greater reach per dollar spent - lower maintenance overhead – ultimately, experience-focused thinking leads to development of infrastructure that is naturally more resilient and shares more common data. Fewer islands to garden. - with greater adoption of emerging standards comes greater technical longevity - accepting broadened definitions of interface, and working with centralized, standards-based interfaces to data, explodes the realm of the possible, increasing upside potential immeasurably
Of course, all of this is, as I said, subordinate to and derivative of the benefits to the end user, or as we like to call them (a little more warmly), “customers”: Stability to a digital experience across multiple devices – “data everywhere” may be old hat to early adopters, but it’s still revolutionary to most consumers, and with good reason Optimizes our consumption of content, no matter where we are, what we are doing, or what device we are using to access that content Establishes clear hierarchies of information -- which aids visual design and benefits users – by forcing content providers to really think about what content is important in which contexts
[good, but a little limiting]
[ah, that’s better]
Start with "experience" (not "website", "app", "database", etc)
[but beware of assumptions!]Low bandwidth? What about the couch, and wifi?On the go/distracted/short sessions? What about people who gladly read kindle books on their phones?Bottom line is that context is at least as much about the user and their situation than it is about their device of choice. Assuming one because of the other can be dangerous.This, of course, greatly complicates the process of experience design, but we can infer some rules.[experience determines function]
This is a big old can of worms, and at the risk of cratering on definitions, let’s dive in:Different interfaces are naturally predisposed to serve different functionsDifferent types of content are naturally more useful in different contextsSo, at the risk of trying to be fortune tellers, our job is to parse the various lenses of experience that our content and functionality will be accessed through, and sort it in as effective a manner as possibleThis was a lot easier when we were just dealing with a bunch of PC-based web browsers.
So, in different contexts, we can see how different content can be made to behave.We can see assumptions made here about the importance of various content in various contexts as we move up the resolution continuumWeather elevated in mobileSome “deeper” content section links subordinated or hidden
Progressively adding more, particularly in the header and navigation, as screen real estate increases
Until we get to the “full web” experience we’ve become accustomed to
So, this is a fairly linear progression with clean implementation and relatively uncomplicated layout, which makes it a great “pure UX” example – the content and design decisions that had to be made were all relatively straightforwardBut what happens when designs get progressively more intricate, and flexing across resolutions requires more nuance?
If you look closely, you’ll see a very interesting combination of content and design decisions being made across device targets here
Here, moving from web resolution to tablet resolution is largely just a matter of restacking content blocks (which we’ll discuss shortly),But it’s interesting to note what’s preserved and removed as we go one level deeper, to the smartphone level…
Here, the site has chosen to maintain the content anchor in the form of the music player, but has removed the “tickets” option as we get onto mobile devicesThere are a lot of reasons why this decision could have been made, and particularly in the case of the “tickets” link, it’s interesting to think about why:Did the organizerthinkuserswouldn’tbuy tickets from a mobile device? Are tickets not availableyet, and is the linkwithin the desktop site a placeholder?
And content decisions too!
Native vs. Web – it may seem, on the surface, like a complicated and/or arbitrary decision, but there is a relatively simple formula for determining the right pathAnd it doesn’t involve the second derivative of Apple’s stock price, believe it or not.In general, we like to look at any experience that requires “advanced” device capabilities – the most common of these being camera access – as good candidates for native apps. native drawbacks – siloed/"deaf" -- Jenson's "percolating swamp" native advantages -- access to advanced sensors / capabilities -- mobile web gradually catching up as standards are ratified and adopted (GPS, camera, ?) -- single set of rules? iOS yes, Android, less clear -- counterpoint: mobile web's standards as "single set of rules"
Native apps *can* be future-friendly… standards-based input, packaged output via phonegap
Responsive design tends to require green-field building, at least of front-end code.For this reason, “retrofitting” per se is tricky.Particularly given that thinking forward tends to require reconsideration of the customer experience, from the ground up.In general, your site’s content will survive, in some form. But it will live on in a shiny new vessel.
Building Future Friendly Experiences
ISITE Design• Full service digital agency• Founded 1997• Portland OR, Boston MA, Santa Monica, CA• Focused on customer experience• http://isitedesign.com
A little bit about me!• Gene Ehrbar, Director of Mobile Solutions• Founded 1974 ;-)• Naturalized Oregonian• I lead a team of cross-platform mobile solution architects• Cat pictures and bad puns: @pdxgene
Reality So, what’s the check problem? • The web’s been around a good 20 years now; • Client evolution has been relatively slow… until recently; • Currently: explosion of form factors and capabilities; • It’s just the tip of the iceberg…
Hat tip! A bunch of wicked smart people got together… • http://futurefriend.ly
“Future So, what does thatFriendly” even mean? • Embrace unpredictability • Create focused experiences • Interoperate liberally • Rethink everything
Why? Business Benefits • Broader reach and accessibility • Lower maintenance overhead • Longer shelf life • Much greater possibility
Why? Customer Benefits • Allows us to bring stability to a digital experience across multiple devices • Optimizes our consumption of content, no matter where we are, what we are doing, or what device we are using to access that content • Establishes clear hierarchies of information