SlideShare a Scribd company logo

Web, Mobile, App and Back!

•
•
Gabriel Walt
Gabriel Walt

This document discusses strategies for delivering content across different devices and platforms. It covers responsive design which adapts the layout based on the device and adaptive design which provides optimized experiences for different devices. The document also discusses using PhoneGap to build cross-platform mobile apps and leveraging content synchronization to keep mobile apps updated.

1 of 31
Download to read offline
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. fluid grid) •  Same content served to all browsers and devices •  Single URL for all devices •  Mobile first Adaptive •  Server Side (in our case) •  Defined 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 experienceContent 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 & Workflows Less Reuse –  Reuse is harder –  More maintenance –  Less agility
Web VS Native Maximal Reuse –  Of Code & Skills –  Of Content & Data –  Of Processes & Workflows 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 specific Web App
Web, Mobile, App and Back!
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 & Workflows 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 –  Through AppStores (and URLs) –  Pushed through AppStore –  Fast
Mobile Content Synchronization
Exports Content from the repository as a ZIP file •  Client Technology Agnostic: –  Requires HTTP client –  Requires ZIP library •  Optimized for low bandwidth consumption –  Only diff is transferred –  Content is packaged in one compressed file •  Can synchronize any kind of content: –  HTML, CSS, JS –  XML, JSON, etc. –  Binaries, like images, PDFs, etc. –  Static files or Dynamically rendered files 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 Thing… 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

More Related Content

Web, Mobile, App and Back!

  • 1. Web, Mobile, App and Back! CQCON 2013, Basel Gabriel Walt Product Manager Web Experience Management @GabrielWalt gwalt@adobe.com
  • 2. Web, Mobile, App and Back!
  • 3. 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!
  • 4. 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
  • 5. Responsive •  Client Side •  Continuous adaptation of the layout to the browser (e.g. fluid grid) •  Same content served to all browsers and devices •  Single URL for all devices •  Mobile first Adaptive •  Server Side (in our case) •  Defined 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
  • 6. 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
  • 7. 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
  • 8. Different Use-Cases – Adaptive   Adaptive Structure Same content, optimized layout Adaptive Content Same layout, optimized content Content Structure Content Structure Adaptive Site Partially different experienceContent Structure
  • 9. 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
  • 10. 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
  • 11. Live  Copy   Master Content Mobile Content Content   Adaptive Site Architecture Phone Site Tablet Site Desktop Site HTML  Rendi1ons  
  • 12. 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  
  • 13. Apps
  • 14. 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 & Workflows Less Reuse –  Reuse is harder –  More maintenance –  Less agility
  • 15. Web VS Native Maximal Reuse –  Of Code & Skills –  Of Content & Data –  Of Processes & Workflows 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
  • 16. 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 specific Web App
  • 18. PhoneGap Obj C Java NDK J2ME C# C++ C++ C/C++ Na1ve  
  • 20. PhoneGap PhoneGap  is  a  Wrapper   +  PhoneGap   Build  
  • 21. PhoneGap +  PhoneGap  has  a  vibrant   Community   PhoneGap  is  a  Bridge  
  • 22. Web VS Native Maximal Reuse –  Of Code & Skills –  Of Content & Data –  Of Processes & Workflows 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 –  Through AppStores (and URLs) –  Pushed through AppStore –  Fast
  • 24. Exports Content from the repository as a ZIP file •  Client Technology Agnostic: –  Requires HTTP client –  Requires ZIP library •  Optimized for low bandwidth consumption –  Only diff is transferred –  Content is packaged in one compressed file •  Can synchronize any kind of content: –  HTML, CSS, JS –  XML, JSON, etc. –  Binaries, like images, PDFs, etc. –  Static files or Dynamically rendered files Content Synchronization
  • 25. ContentSync + PhoneGap ContentSync   PhoneGap  Build   PhoneGap  App   ContentSync   Diff  Update   Under  Progress   PhoneGap  ContentSync  Diff  Update  Integra1on   CQ5  
  • 26. •  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
  • 27. ✓ 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!
  • 28. Ques1ons?   Gabriel Walt Product Manager Web Experience Management @GabrielWalt gwalt@adobe.com
  • 29. One More Thing… Gabriel Walt Product Manager Web Experience Management @GabrielWalt gwalt@adobe.com
  • 30. New  CQ  Components   è  1nyurl.com/cqcomponent   Improve: •  Extensibility •  Reusability •  Separation of concerns •  Help structuring real projects
  • 31. Thanks!   Gabriel Walt Product Manager Web Experience Management @GabrielWalt gwalt@adobe.com