Web Apps vs Web Site


Published on

Published in: Technology, Design
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Web Apps vs Web Site

  1. 1. Web App Vs Web Site Some tricks of the trade Laurent Hasson @ldhasson, lhasson@rim.com Technical Director, BlackBerry Web Platform2012-05-09 Web Apps Vs. Web Sites 1
  2. 2. INTRODUCTION2012-05-09 Web Apps Vs. Web Sites 2
  3. 3. Web App Or Web Site?• Lots of controversies and differing opinions from very smart people on the Web – Should a mobile Web app be more Weby, or more Appy?• My take: users today are conditioned to the App Life Cycle – Download something – Install something – Have an icon on the home screen – The App takes the entire screen real estate – The App is integrated with the device• But users really don’t care how the app was built!!! – So use Web technologies for the job!!2012-05-09 Web Apps Vs. Web Sites 3
  4. 4. Two Dimensions to App ExperienceLife Cycle There are many options to make the journey Contents2012-05-09 Web Apps Vs. Web Sites 4
  5. 5. Two Dimensions to App ExperienceLife Cycle Contents2012-05-09 Web Apps Vs. Web Sites 5
  6. 6. Say no to NIBS - The “Native Is Better” crowd are missing the point of the Web - It’s the scale of the market stupid! - It’s powerful, cross-platform, and an abundant skill set.NIBS - This is not to say that Web is better than Native - That would be silly - But the Web is absolutely competitive - Most types of apps can now be built very nicely using Web technologies - The gap is narrow today, keeps on getting narrower, and fast. - Make no mistake * Native Is Better Syndrome - Native is the competition to Web2012-05-09 Web Apps Vs. Web Sites 6
  7. 7. Web App Design Goals• Single-page app metaphor – DOM manipulation for panels – And if not, mask page loading transitions• Lack of browser chrome – Links, Bookmarks and Back• Browser Events – Targeting multiple platforms means managing touches and clicks equally• Viewport Management – Horizontal bounciness is bad – Zooming can be dangerous2012-05-09 Web Apps Vs. Web Sites 7
  8. 8. VIEWPORT2012-05-09 Web Apps Vs. Web Sites 8
  9. 9. When a pixel is no longer a pixel• The desktop viewport is WYSIWYG – Window dimensions are well known• On mobile, it’s a whole other story – What you see is a viewport on a larger “thing” • Panning is a fact of life for most users • Zooming is a critical part of the browser UX• And pixels are no longer display-relevant – High DPI and other display technologies have changed the meaning of what a pixel is – Better res without breaking the Web2012-05-09 Web Apps Vs. Web Sites 9
  10. 10. CSS Pixels• These are the pixels we deal with everyday – CSS definitions – Inline dimensions in HTML – Media queries• On desktop, a CSS px == 1 device px• On mobile, don’t even try – The device vendor decides what the mapping is – You typically can’t tell programmatically what the ratio is – So deal with those abstract pixels • On BlackBerry, default is 160DPI2012-05-09 Web Apps Vs. Web Sites 10
  11. 11. HUH?2012-05-09 Web Apps Vs. Web Sites 11
  12. 12. How many Pixel?• screen.width/height – Device pixels – Entire screen, pretty useless as it’s really a desktop concept• document.documentElement.clientWidth/clientHeight – CSS pixels: 768px (usable space, minus browser chrome, so height is different) – Useful for media queries• window.innerWidth/innerHeight – CSS Pixels of viewport: Depending on zoom level – DPI-scaled: 350px width (native res scaled to 160dpi for zoom-level of 1)• window.pageXOffset/pageYOffset – CSS Pixels of scrolling2012-05-0912 Web Apps Vs. Web Sites
  13. 13. Viewport and Media Queries<meta name="viewport" content="height=device-height, width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0"> – Makes sure your page doesn’t flow beyond screen dimensions (including margins and borders) – Works as long as your content doesn’t force overflow – Deal in %• @media all and (max-width: 480px) { … } – There are other flexible syntaxes for CSS media queries2012-05-09 Web Apps Vs. Web Sites 13
  14. 14. Orientation: Landscape or Portrait• Make sure you test in both modes• Or lock the orientation – There are configuration flags available through packagers such as Apache Cordova• Upcoming ScreenOrientation API – screen.orientation=“portrait”|”landscape”|…, screen.lockOrientation(“…”), screen.unlockOrientation(), screen.onOrientationChange – Languishing…2012-05-09 Web Apps Vs. Web Sites 14
  15. 15. EVENTS: TOUCHES, CLICKS…2012-05-09 Web Apps Vs. Web Sites 15
  16. 16. World Wide Web == Wild Wild West• Some platforms do touch well• Others simulate clicks – With delays and quirks• Behaviors expected when preventDefault() are not consistent• Plus, you may want to create Web content that also works in a browser – That’s still an important goal if it makes sense to you2012-05-09 Web Apps Vs. Web Sites 16
  17. 17. Your mileage may vary TouchStart If nothing else within 300ms MouseDown TouchMove MouseMove MouseUp TouchEnd MouseClick • Delay is not the same everywhere • The interplay between touch and mouse events vary • The effect of onPreventDetault() vary2012-05-09 Web Apps Vs. Web Sites 17
  18. 18. The Infamous Delay• When the browser gets a touch, it needs to wait to see if there is a move or not – Some of the browser’s own UX for pan/zoom need that – Typically 300ms• In your app, you should take control of that – You typically don’t want zooming gestures – You know what you expect from your users – You don’t want that 300ms delay2012-05-09 Web Apps Vs. Web Sites 18
  19. 19. touch-event-mode: BlackBerry Only <meta name="touch-event- <meta name="touch-event- mode” content="native"> mode" content=”pure-with- mouse-conversion">• WebPage gets TouchEvents only from touch screen. • WebPage gets both Touch events and Mouse events. User touches screen User touches screen Touch Touch onTouch Y XXX? DONE N DONE MouseBrowser UX disabled: DoubleTap zoom, pinch zoom, text selection and context menus2012-05-09 Web Apps Vs. Web Sites 19
  20. 20. Control Your Destiny TouchStart MouseDown TouchMove MouseMove MouseUp TouchEnd MouseClick2012-05-09 Web Apps Vs. Web Sites 20
  21. 21. Yeah, i know, it’s a bit controversial2012-05-09 Web Apps Vs. Web Sites 21
  22. 22. Custom Event Handlingif (Touch) { document.ontouchend = function(event) { Blocks Browser UX behaviors event.preventDefault(); var e = event.target; You may have to walk up the parent while (e && !e.click) nodes to find an actual click() handler. e = e.parentNode; Convert touch coordinates to click if (!e || !e.click) coordinates return; event.clientX = event.changedTouches[0].pageX; event.clientY = event.changedTouches[0].pageY; e.click(event); } Invoke the onClick handler } You may want to do things differently to suit your app requirements, but the core idea is here2012-05-09 Web Apps Vs. Web Sites 22
  23. 23. Other virtual events systems• Maps deviceOrientation events to key events – Simulates up/down/left/right arrows, or WASD or whatever – Most virtual keyboards don’t have arrow keys – Most virtual keyboards wouldn’t make sense in games anyways – Redirects to onKeyUp• Famous frameworks, such as jQueryMobile, do it too, to gain control of, and unify, events.2012-05-09 Web Apps Vs. Web Sites 23
  24. 24. user-select• There is one more browser UX you may want to disable as well – User selection can be very annoying when in an app body { user-select: none; }• Or do that on selected sub-DOMs of your app• In some cases, it makes sense, and you want to reuse the browser mechanisms for that2012-05-09 Web Apps Vs. Web Sites 24
  25. 25. NO BROWSER CHROME2012-05-09 Web Apps Vs. Web Sites 25
  26. 26. Arguably, the Web is about Navigation• You don’t realize how much the Browser’s skin does with your site until you don’t have it anymore• So many sites can still paint you into a corner where you can’t escape without the back button – Even some big sites do it (I won’t name names!)• How about navigation – Many APIs exist now, and are well supported to help you.2012-05-09 Web Apps Vs. Web Sites 26
  27. 27. Bookmarks == saved application states• Why wouldn’t you let your users create in-app bookmarks for content they specially like?• Doing an App now doesn’t mean you have to forget about REST principles and what has made the Web so cool!• You need – The History API – Local storage – Some UI to let your users manage their “bookmarks”2012-05-09 Web Apps Vs. Web Sites 27
  28. 28. And for debugging? location.reload(true)2012-05-09 Web Apps Vs. Web Sites 28
  29. 29. CONCLUSION2012-05-09 Web Apps Vs. Web Sites 29
  30. 30. Web Apps <> Web Sites• If you subscribe to the idea that Web apps must be Appy, then do things a bit differently – Viewport management must be explicit – Manage your own events – Navigation is different due to lack of chrome• But don’t drop what makes the web so cool – Navigation and Bookmarks are powerful features• And debugging is hard, unless you do it on a BlackBerry – Best mobile browser AND built-in full remote WebInspector2012-05-09 Web Apps Vs. Web Sites 30
  31. 31. The End – Thank You2012-05-09 Web Apps Vs. Web Sites 31
  32. 32. ReferencesSlide 2: The Matrix (1999)Slide 5: BlackBerry Loves Apache CordovaSlide 8: Poltergeist (1982)Slide 11: Videodrome (1983)Slide 15: Nightmare On Elm Street (1984)Slide 21: Hellraiser (1987)Slide 25: Tetsuo (1989)Slide 29: Anguish (1987)Slide 31: Masters Of Horror: Family (2006)2012-05-09 Web Apps Vs. Web Sites 32