Web, Mobile, App and Back!

2,436 views
2,253 views

Published on

Talk hold at the CQCON 2013, Basel (http://www.cqcon.eu/)

Published in: Technology
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,436
On SlideShare
0
From Embeds
0
Number of Embeds
40
Actions
Shares
0
Downloads
78
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

Web, Mobile, App and Back!

  1. 1. Web, Mobile, App and Back!CQCON 2013, BaselGabriel WaltProduct ManagerWeb Experience Management@GabrielWaltgwalt@adobe.com
  2. 2. Web, Mobile, App and Back!
  3. 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 wayWeb, Mobile, App and Back!
  4. 4. ADAPTIVERESPONSIVEClient adapts thelayout to thebrowser/deviceSERVERSIDEADAPTIVEServer adapts therendition to thebrowser/deviceSet of strategies toadapt the experienceto browsers/devicesAdaptive Strategy
  5. 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 firstAdaptive•  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 redirectionAdaptive VS Responsive
  6. 6. Different Use-Cases  Responsive SiteSame content for all browsersLayout is adapted by the browserè Maximal ReuseAdaptive SitePartially different experienceè Partial ReuseSeparate SiteDisconnected experienceè No Reusee.g. Desktop e.g. Mobile
  7. 7. Different Use-Cases  ContentStructureContentStructureContentStructureResponsive SiteSame content for all browsersLayout is adapted by the browserè Maximal ReuseAdaptive SitePartially different experienceè Partial ReuseSeparate SiteDisconnected experienceè No Reuse
  8. 8. Different Use-Cases – Adaptive  Adaptive StructureSame content, optimized layoutAdaptive ContentSame layout, optimized contentContentStructureContentStructureAdaptive SitePartially different experienceContentStructure
  9. 9. Key Features•  Mobile Simulator•  LiveCopy – to keep content in sync•  BrowserMap – to redirect the visitorKey Features•  Responsive Simulator•  Adaptive Image ComponentResponsive SiteAdaptive SiteSeparate SiteAdaptive StructureAdaptive ContentDifferent Use-Cases
  10. 10. Separate Content Tree / Separate RenditionWhen the CONTENT needs adaptations:è Separate Content Tree (typically kept in sync using LiveCopy)When the RENDITION needs adaptations:è Separate Selectororè Separate Content TreeAdaptive ContentAdaptive StructureContentStructureContentStructure
  11. 11. Live  Copy  Master ContentMobile ContentContent  Adaptive Site ArchitecturePhone SiteTablet SiteDesktop SiteHTML  Rendi1ons  
  12. 12. Live  Copy  Phone SiteTablet SiteDesktop Site/site/news.html  Master Content/content/site/news  Mobile ContentWeb  Path   Repository  Path  Adaptive Site Architecture/site-­‐mobile/news.tablet.html  /site-­‐mobile/news.phone.html  /content/site-­‐mobile/news  
  13. 13. Apps
  14. 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 wayAppsWeb VS NativeSite App Site AppMaximal Reuse–  Of Code & Skills–  Of Content & Data–  Of Processes & WorkflowsLess Reuse–  Reuse is harder–  More maintenance–  Less agility
  15. 15. Web VS NativeMaximal Reuse–  Of Code & Skills–  Of Content & Data–  Of Processes & WorkflowsLess 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–  FasterOther Differences  –  Cross Platform–  Limited to the browser–  Distributed by URL–  Instant Updates–  FastSite App Site App
  16. 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 APIse.g. Browser or PhoneGap specificWeb App
  17. 17. PhoneGapObj C JavaNDKJ2ME C# C++ C++ C/C++Na1ve  
  18. 18. PhoneGapFully  Cross-­‐Pla>orm  WebApp  
  19. 19. PhoneGapPhoneGap  is  a  Wrapper  +  PhoneGap  Build  
  20. 20. PhoneGap+  PhoneGap  has  a  vibrant  Community  PhoneGap  is  a  Bridge  
  21. 21. Web VS NativeMaximal Reuse–  Of Code & Skills–  Of Content & Data–  Of Processes & WorkflowsLess 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–  FasterOther Differences  –  Cross Platform–  Device & Browser APIs–  Through AppStores (and URLs)–  Pushed through AppStore–  Fast
  22. 22. Mobile Content Synchronization
  23. 23. 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 filesContent Synchronization
  24. 24. ContentSync + PhoneGapContentSync  PhoneGap  Build  PhoneGap  App  ContentSync  Diff  Update  Under  Progress  PhoneGap  ContentSync  Diff  Update  Integra1on  CQ5  
  25. 25. •  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
  26. 26. ✓ 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 wayWeb, Mobile, App and Back!
  27. 27. Ques1ons?  Gabriel WaltProduct ManagerWeb Experience Management@GabrielWaltgwalt@adobe.com
  28. 28. One More Thing…Gabriel WaltProduct ManagerWeb Experience Management@GabrielWaltgwalt@adobe.com
  29. 29. New  CQ  Components  è  1nyurl.com/cqcomponent  Improve:•  Extensibility•  Reusability•  Separation of concerns•  Help structuring real projects
  30. 30. Thanks!  Gabriel WaltProduct ManagerWeb Experience Management@GabrielWaltgwalt@adobe.com

×