Thursday, April 28, 2016

[my note: conference] Google Developers Summit 2016



Subject
Google Developers Summit 2016
Place
Nine Tree Convention Gwanghwamun, Seoul Korea
Time
April 28, 2016 (Thu) 13:20~18:00
Speaker
Host
Google
Focus
mobile web and app; web (progressive Web, next Web, push Notification)


  1. Intro to Progressive Web Apps (Robert Nyman, Google)
    1. Lesson
      1. RAIL: instant loading and smooth navigation
      2. SLICE: build an app not requiring installation
        1. Secure: be intentional when asking for user permissions
        2. Linkable: provide a direct link per paragraphs
        3. Indexable: make sure my contents can be found via search engines
        4. Composable: how you combine things
        5. Ephemeral: don’t require too much steps
      3. Why needing a native app?
        1. Performance, offline access, periodic background processing, notifications, sensors (GPS, Bluetooth), OS-specific features
      4. Progressive web app (or PWA)
        1. Reliable: fast loading, works on flaky networks
        2. Fast: smooth animation, scrolling, and nav
        3. Engaging and integrated: full screen with no URL bar, sending notifications even when page closed
      5. Required
        1. Service Worker
        2. Web app manifest
        3. App shell caching
      6. Recommended features
        1. Push notifications
        2. Advanced offline support
      7. PWA should work across all browsers (e.g., Chrome, Firefox, Opera)
      8. Add https to your web site for security (e.g., SSL for free, Cloudflare, bit.ly/ssl-labs)
      9. Usecase
        1. Flipkart
          1. 3x time spent on site
          2. 40% visitors return week over week
          3. Smooth experience on even 2G & flaky networks


    1. Personal Takeaway
      1. Use HTTPS
      2. The term Service Worker


  1. What’s new in Android N (Chansuk Yang, Google)
    1. Lesson
      1. Android Beta Program: google.com/android/beta (c.f., don’t run this program on a regular phone but run on a test phone)
      2. N for Developers:
        1. Multi-window: split view, PIP, free-fall?
        2. battery optimization:doze in N-release (no network access, jobs/syncs deferred); Doze Optimization (e.g., foreground service for music streaming service)
        3. datasaver, background optimization
      3. N Developer Checklist
        1. Check Multi window
        2. CONNECTIVITY_CHANGE, NEW_PICTURE NEW_VIDEO
        3. Doze
        4. Datasaver mode
        5. Notification template
        6. Supporting various screen size and orientation
        7. Background tasks such as service/broadcast receiver needing to be used only when needed
        8. Repetitive task-> battery optimize
        9. Be careful in allowing permissions
      4. References: d.android.com/preview; developer.android.com/preview/samples


    1. Personal Takeaway
      1. Go through checklist to prepare for N


  1. Instant and Offline Apps with Service Worker (도창욱, GDE)
    1. Lesson
      1. Benefit
        1. Goals
          1. Compression
            1. Use minification & gzip: e.g., min.js; min.css
            2. WebP: smaller than JPG
              1. Use <picture> tag and prioritize image formats
          2. Round trips (wasteful time)
          3. Be interactive: script async defer
          4. Defer iframes
          5. Http2: connection share
          6. Offline:
      2. Service Worker (a JavaScript module)
        1. Only support https
        2. Useful for 404 error page


    1. Personal Takeaway
      1. SW has instant loading benefit!


  1. Making it Installable (문현경Jimmy Moon, GDE)
    1. Lesson
      1. Installable web apps in 2 simple steps
        1. Create a manifest (a json file)
          1. E.g., {“name”: “The Airhorner”...}
        2. Link it to your page
          1. E.g., link=
      2. Flow
        1. User clicks “Add to home screen”
        2. Confirmation prompt shown
        3. ...
      3. Splash screen
      4. Requirement for prompt to install: offer an offline experience (i.e., Service Worker, HTTPS), hae a manifest (define what to launch and how to launch it), user …


    1. Personal Takeaway
      1. Term splash screen
      2. Prompt to install


  1. Deeper Engagement with Push Notification (고재도, GDE)
    1. Lesson:
      1. Ask yourself: is it important to interrupt users by sending notifications?
      2. Anatomy of notification
        1. Timely
        2. Precise
        3. Relevant
        4. Work offline
      3. Notification example: e.g., flight delayed, credit card last purchase amount,  your self driving car has arrived, thanks for installing me
        1. Subscribing users
      4. C.f., Propel


    1. Personal Takeaway:
      1. Anatomy of notification: Timely, Precise, Relevant, Work offline


  1. Putting the Progressive in Progressive Web Apps (Sam Thorogood, Google)
    1. Lesson
      1. Definition of Progressive Enhancement
        1. What: works in every browser
        2. How: incremental use of APIs
        3. Why : diverse users (different device)
      2. Imperative HTML
      3. Push:
        1. Notification: info
        2. User engagement: user re-engagement for helping them buy products or consume contents
        3. Ask questions:
          1. What do you know about them- email, phone #, twitter, facebook
          2. Why are you engaging with them- informative or actionable
          3. Do you need to be timely
          4. Are you already engaging with them?
        4. Transport idioms
          1. Native
            1. Send timely and engaging notifications, no user login required
          2. Email
            1. Send HTML email with actional buttons
            2. context/platform might be different- provide login hint (help users just to enter password instead of ID and password)
          3. SMS
        5. Leverage the browser: e.g., <input autocomplete=>
      4. Install:
        1. The modern way: e.g., <link rel=”manifest” href=”/manifest.json” />
        2. Best practice: “Add to Home Screen” hint
        3. Browser tab or standalone?: content (browser tab) vs. utility (standalone)
      5. Offline:
        1. Offline capable: if a site can be cached, then you should operate well
        2. Network as a feature:
          1. assume your site is always offline, unless proven otherwise
          2. Every load, image fetch starts with the assu…
      6. User perception
        1. Loading wheel image: iOS image (people blame the OS) vs. Facebook loading image (blame the app)


    1. Personal Takeaway
      1. Due to user perception, use iOS loading image ^^;


  1. The Future of the Web (Paul Kinlan, Google)
    1. Lesson
      1. Friction was removed over time
      2. Distribution is the hardest problem in software
      3. Engagement has been achilles’ hill on web
      4. Placement of PWA: Mobile Web -> Progressive Web Apps -> App
      5. The future of the web is not about APIs
        1. Multi-device exp: one code for all
        2. Faster exp: load instantly via Service Worker
        3. HTTPS everywhere: use Service Worker
        4. Engaging and reduced friction: optimize UX of push notifications (e.g., Facebook’s push notification)
      6. Be fast everywhere (site load instantly)
        1. Amp
        2. RAIL
      7. Move to HTTPS
        1. Camera
        2. Auto-fill
        3. Push
        4. Geo-location is disabled now
        5. Full-screen will be disabled
      8. Be engaging
        1. E.g., Flipkart- conversion increase, return increase
      9. Service worker is the glue that binds the future of the Web
        1. Entire sites now have an app-like lifecycle.
      10. ES2015: Promises, ...
      11. Stream: fetch-> process-> render
      12. Background Sync: defer network request until online, great for ensuring transactions happen
      13. Credential Management- store credentials for re-use, get saved credentials (across devices)
      14. Media Stream Recorder-
      15. Web Bluetooth
      16. Physical Web: user opt-in

    1. Personal Takeaway
      1. Vysor: controllable window of your Android on your desktop

Friday, November 6, 2015

[personal UX/UI review] the power of "Reply" button on review page (e.g. Chrome Web Store)


<case: Chrome Web Store's product detail page>

positive: the existence of "Reply" button on review page

reason: because of the button, the review page can be used as a terrific communication channel: 1. allowing users to answer questions of another user, which reduces communication cost of the app creator 2. working like a CS (customer service) channel, providing the app creator an opportunity to directly respond to eliminate frustrations of users, which may help reduce "bounce rate" of the app use 3. displaying interactions among users so that each thread can be more open and transparent

Kindle – Read Books, eBooks, Magazines, Newspapers & Textbooks on the App Store - Google Chrome 2015-11-06 12.30.18.png
<case: iTunes App Store's product detail page>