• Like
Web App vs Web Site
Upcoming SlideShare
Loading in...5
×

Web App vs Web Site

  • 269 views
Uploaded on

 

More in: Technology , Design
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
269
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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. INTRODUCTION2012-05-09 Web Apps Vs. Web Sites 2
  • 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. Two Dimensions to App ExperienceLife Cycle There are many options to make the journey Contents2012-05-09 Web Apps Vs. Web Sites 4
  • 5. Two Dimensions to App ExperienceLife Cycle Contents2012-05-09 Web Apps Vs. Web Sites 5
  • 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. 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. VIEWPORT2012-05-09 Web Apps Vs. Web Sites 8
  • 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. 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. HUH?2012-05-09 Web Apps Vs. Web Sites 11
  • 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. 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. 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. EVENTS: TOUCHES, CLICKS…2012-05-09 Web Apps Vs. Web Sites 15
  • 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. 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. 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. 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. Control Your Destiny TouchStart MouseDown TouchMove MouseMove MouseUp TouchEnd MouseClick2012-05-09 Web Apps Vs. Web Sites 20
  • 21. Yeah, i know, it’s a bit controversial2012-05-09 Web Apps Vs. Web Sites 21
  • 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. 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. 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. NO BROWSER CHROME2012-05-09 Web Apps Vs. Web Sites 25
  • 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. 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. And for debugging? location.reload(true)2012-05-09 Web Apps Vs. Web Sites 28
  • 29. CONCLUSION2012-05-09 Web Apps Vs. Web Sites 29
  • 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. The End – Thank You2012-05-09 Web Apps Vs. Web Sites 31
  • 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