Web, Mobile, App and Back! CQCON 2013, Basel

Gabriel Walt Product Manager Web Experience Management @GabrielWalt gwalt@adobe.com

Web, Mobile, App and Back!

What is it about? –  Making the content available for the mobile visitors –  Delivering an adapted experience (limitations & possibilities) –  Recognize the same users identically (personalization & targeting) –  Measure the same things the same way

Web, Mobile, App and Back!

ADAPTIVE

RESPONSIVE Client adapts the layout to the browser/device

SERVER SIDE

ADAPTIVE

Server adapts the rendition to the browser/device

Set of strategies to adapt the experience to browsers/devices

Adaptive Strategy

Responsive •  Client Side •  Continuous adaptation of the layout to the browser (e.g. !uid grid)

•  Same content served to all browsers and devices •  Single URL for all devices •  Mobile "rst Adaptive •  Server Side (in our case)

•  De"ned set of optimized experiences (e.g. desktop, tablet, touch phones, legacy)

•  Different renditions generated by server for the given set of devices •  Different URLs (because CQ is RESTful)

•  Need redirection

Adaptive VS Responsive

Different Use-Cases  

Responsive Site Same content for all browsers Layout is adapted by the browser è Maximal Reuse

Adaptive Site Partially different experience è Partial Reuse

Separate Site Disconnected experience è No Reuse

e.g. Desktop e.g. Mobile

Different Use-Cases  

Content

Structure

Content

Structure

Content

Structure

Responsive Site Same content for all browsers Layout is adapted by the browser è Maximal Reuse

Adaptive Site Partially different experience è Partial Reuse

Separate Site Disconnected experience è No Reuse

Different Use-Cases – Adaptive  

Adaptive Structure Same content, optimized layout

Adaptive Content Same layout, optimized content

Content

Structure

Content

Structure

Adaptive Site Partially different experience Content

Structure

Key Features •  Mobile Simulator •  LiveCopy – to keep content in sync •  BrowserMap – to redirect the visitor

Key Features •  Responsive Simulator •  Adaptive Image Component

Responsive Site

Adaptive Site

Separate Site

Adaptive Structure

Adaptive Content

Different Use-Cases

Separate Content Tree / Separate Rendition

When the CONTENT needs adaptations: è Separate Content Tree (typically kept in sync using LiveCopy)

When the RENDITION needs adaptations: è Separate Selector or è Separate Content Tree

Adaptive Content

Adaptive Structure

Content

Structure

Content

Structure

Live  Copy  

Master Content

Mobile Content

Content  

Adaptive Site Architecture

Phone Site

Tablet Site

Desktop Site

HTML  Rendi1ons  

Live  Copy  Phone Site

Tablet Site

Desktop Site /site/news.html  

Master Content /content/site/news  

Mobile Content

Web  Path   Repository  Path  

Adaptive Site Architecture

/site-­‐mobile/news.tablet.html  

/site-­‐mobile/news.phone.html  

/content/site-­‐mobile/news  

Apps

Let’s keep the focus –  Making the content available for the mobile visitors –  Delivering an adapted experience (limitations & possibilities) –  Recognize the user (personalization & targeting) –  Measure the same things the same way

Apps

Web VS Native

Site App Site App

Maximal Reuse –  Of Code & Skills –  Of Content & Data –  Of Processes & Work!ows

Less Reuse –  Reuse is harder –  More maintenance –  Less agility

Web VS Native

Maximal Reuse –  Of Code & Skills –  Of Content & Data –  Of Processes & Work!ows

Less Reuse –  Reuse is harder –  More maintenance –  Less agility

–  Needs to be compiled for each OS –  Can access device APIs –  Distributed through AppStores –  Pushed through AppStores –  Faster

Other Differences  –  Cross Platform –  Limited to the browser –  Distributed by URL –  Instant Updates –  Fast

Site App Site App

First, Some Guidelines –  Architect for performance

•  Single Page Architecture •  Cache everything •  Don’t wait for data to display the UI •  Don’t generate UI on the server

–  Provide structure to your application •  Use Feature Detection •  Use a MV* architecture •  Use Frontend Templates

–  Abstract Non-Standard APIs e.g. Browser or PhoneGap speci"c

Web App

PhoneGap

Obj C Java NDK

J2ME C# C++ C++ C/C++

Na1ve  

PhoneGap

Fully  Cross-­‐Pla>orm  

WebApp  

PhoneGap

PhoneGap  is  a  Wrapper  

+  PhoneGap  

Build  

PhoneGap

+  PhoneGap  has  a  vibrant  

Community  

PhoneGap  is  a  Bridge  

Web VS Native

Maximal Reuse –  Of Code & Skills –  Of Content & Data –  Of Processes & Work!ows

Less Reuse –  Reuse is harder –  More maintenance –  Less agility

–  Needs to be compiled for each OS –  Can access device APIs –  Distributed through AppStores –  Pushed through AppStores –  Faster

Other Differences  –  Cross Platform –  Device & Browser APIs –  $rough AppStores (and URLs)

–  Pushed through AppStore –  Fast

Mobile Content Synchronization

Exports Content from the repository as a ZIP "le •  Client Technology Agnostic:

–  Requires HTTP client –  Requires ZIP library

•  Optimized for low bandwidth consumption –  Only diff is transferred –  Content is packaged in one compressed "le

•  Can synchronize any kind of content: –  HTML, CSS, JS –  XML, JSON, etc. –  Binaries, like images, PDFs, etc. –  Static "les or Dynamically rendered "les

Content Synchronization

ContentSync + PhoneGap

ContentSync  

PhoneGap  Build  

PhoneGap  App  

ContentSync  Diff  Update  

Under  Progress  

PhoneGap  ContentSync  Diff  Update  Integra1on  

CQ5  

•  Not  suited  for  Content  Synchroniza1on  –  Heavy  files  (e.g.  very  large  images)  

–  Huge  amounts  of  content    –  Content  with  high  frequency  of  change  (e.g.  forum  posts)  

–  User  specific  data  •  Strategies  for  handling  that  

–  Load  user  content  asynchronously  (e.g.  at  app  launch,  through  a  user  web  service)  –  Load  heavy  content  asynchronously  (e.g.  first  1me  user  requests  it)  

–  Load  frequently  changing  content  in  a  web  view,  or  beTer  asynchronously  too  

Content Synchronization

✓ Making the content available for the mobile visitors ✓ Delivering an adapted experience (limitations & possibilities) ✓ Recognize the same users identically (personalization & targeting) ✓ Measure the same things the same way

Web, Mobile, App and Back!

Ques1ons?  

Gabriel Walt Product Manager Web Experience Management @GabrielWalt gwalt@adobe.com

One More $ing…

Gabriel Walt Product Manager Web Experience Management @GabrielWalt gwalt@adobe.com

New  CQ  Components  è  1nyurl.com/cqcomponent  

Improve: •  Extensibility •  Reusability •  Separation of concerns •  Help structuring real projects

Thanks!  

Gabriel Walt Product Manager Web Experience Management @GabrielWalt gwalt@adobe.com