google / ioweb2015 Goto Github PK

For example, in _masthead.scss we've hardcoded a 2x image.

Another alternative is to use SVG!

As mentioned in #47, the code in shed-offline-analytics.js is self-contained and generic enough to be useful outside of this project. It should be refactored and released as a standalone "plugin" library for shed.

This depends on the tasks in #46 and #48.

For us to be able to auto-populate the Extended map on the Website from the Extended Form organizers fill out we need to be able to pull the location data from their event.

Create a one-off page that allows users to type their event location, displays a map pin to verify the location is where they think it is, and opens the reg form with populated variables.

Example pre-populated form:
https://docs.google.com/a/google.com/forms/d/1rjMnxYvyGAmi3O4gfvYgqhEoolDSkeVdJY2w9MtVlmE/viewform?entry.23917865=country&entry.652280183=street&entry.502610227=123&entry.272782401=postcode&entry.789012978=city&entry.971996821=APAC%20(Asia%20Pacific)&entry.1458261258=lat&entry.1058533728=lng

(the entry.971996821 value needs to match one of the 3 options in the form)

Flow:

1. use the Places API to auto-complete the users event location (similar to this demo)
2. use the Maps Gecoding API to get the lat/lng from the full address.
3. show a map pin for them to visually verify the location.
4. Open the pre-popluated form like so: example

Form results: https://docs.google.com/spreadsheets/d/10b77CzFk_7SQ_BiWSkMf4bz2bawnE-doJS04YInsCIk/edit#gid=0

• POC integration with SW
• other stuff...

• polymerize

Using paper-dropdown

Context: in an event of data change the backend pushes a message to a Service Worker. For a push event to succeed, the SW has to show a UI notification to the user.

We have these categories of user groups:

1. Authenticated / anonymous.
2. Opted in for receiving push notifications.
3. Starred sessions (talks): none or at least one.
4. Combinations of the above.

Anonymous users cannot star sessions: we need a user ID to attach a starred session to.
Some users might have logged in but never starred a single session.

In an event of a data change, these users will be sent a push notification:

1. change is related to a session of a user's interest (starred session).
2. any user (both authenticated and anonymous) which has no starred sessions but opted in for push notifications.

We could make anonymous users received push notifications by simply storing their registration ID obtained from pushManager.register() as long as registrationId is constant (scoped to the visitor).

Updates

• Need global on/off switch for notifications. Backend needs an endpoint for toggling this setting.
• Frontend needs to show toast when the schedule is updated. This is for the case when users have the page open and should be informed there are updates. Alternatively, we can keep the frontend up to date in realtime with firebase if we go that route.

Brain dump:

• If Chrome doesn't get notifications, we can't do them.
• Notifications will work for Chrome mobile/desktop
• Chrome notifications are planned for Chrome 42 (stable on April 14).
• if the site is open, we can do web notifications for all browsers.
• if the site is not open, we can only do notifications from sw (chrome only)

It looks like shed is packaged as an npm module, but I don't think it's published. (Unless I'm missing it somewhere.)

We should work with @wibblymat to figure out whether we can start pulling it in via package.json instead of manually copying the source into the project (which was done in #26).

Noting what needs to change. I've done some of this in #92

• Need a template variable for pages to set the masthead bg color. This is done through a class:
  <header class="masthead bg-medium-grey" layout vertical> (e.g. "bg-medium-grey" in this example).
• nav bar selection updates on new page navigation. #navbar paper-tabs.selected needs to reflect the current page. Ideally, this would be data-bound to the url route <paper-tabs selected="{{route}}" valueattr="route"><paper-tab route="home"><paper-tab..>,
• similarly, drawer panel nav updates to selected route.
• the id of body: <body id="page-PAGENAME">, where PAGENAME is 'about', 'home', 'offsite', 'onsite',...etc.
• <title>
• <meta> tags that need to change

https://www.npmjs.com/package/gulp-jscs

#47 adds in a local copy of a library that wraps IndexedDB, written by a Googler, Joshua Bell, and published at https://gist.github.com/inexorabletash/c8069c042b734519680c

I need to contact him and clarify whether he considers this code ready to be used, and if so, whether he has plans for officially releasing it somewhere other than in that gist, so that it could be pulled in as an official dependency.

There are a few other libraries wrapping IndexedDB we could use if necessary, but his is particularly small and straightforward, and works well for our needs at this time.

We need server side templating so pages can reuse shared template includes

Some combination of pageres for generating screenshots of pages for various viewport sizes and an image diff tool (blink-diff, maybe?) to determine whether anything has changed from our current set of "golden" images could help prevent us from deploying changes that inadvertently affect site layout.

(There's also the automated-screenshot-diff package, but I don't think that gives us the responsive screenshot aspect, which is important.)

• - paper-tab nav click
• - in page card takeover based on paul's POC

window.DEV = true is currently hardcoded in index.html and used in some logging and GA-related logic.

Also, the use of a boolean for detecting environment doesn't allow for different logic in dev vs. staging vs. prod, so something like window.ENVIRONMENT might be more useful. (I could imagine needing to tweak the GA cookie parameters for the staging environment.)

@crhym3 do you think setting this via a server-side template would make sense? Alternatively, we could set it via templating in the gulp build process.

- [ ] - set a reminder - #158

• - "How it works" section copy - @monicabagagem can you get us that?
• - #306

Copy: https://docs.google.com/document/d/1R3cG1SkdBJn3JoDjyTEAHTSbbe2Px5ht8iOdiXreR6k/edit#

We need to link to the appropriate sharing option and not host any JS or use their JS APIs.
Something like:

shareGplus: function(e) {
  e.preventDefault();
  this.openPage_('https://plus.google.com/share?url=' +
                 encodeURIComponent(location.href) +
                 '&hl=' + encodeURIComponent(document.documentElement.lang));
},

shareFB: function(e) {
  e.preventDefault();
  this.openPage_('https://www.facebook.com/sharer.php?u=' +
                 encodeURIComponent(location.href) +
                 '&t=' + encodeURIComponent(document.title));

},

shareTwitter: function(e) {
  e.preventDefault();
  this.openPage_('https://twitter.com/share?text=' +
                 encodeURIComponent('Google I/O 2015 - blah blah') + '&url=' +
                 encodeURIComponent(location.href));
},

Hi all,

We're trying to keep the experiment as separate as possible from the site, in terms of dependencies and commands to execute. The ultimate goal would be a Polymer component that could be link'd to from any Web Components site to turn their site into the experiment as well. This approach gives us a nice separation of responsibilities and makes sure our end presents a nice standard API without requiring much work on the app side.

So, I'm thinking we create a top-level folder for experiment and move the app-related build tooling and dependencies fully into app.

Finally, we can create either some simple shell scripts, Makefile or whatever to trigger actions in both folders. Something like:

make dev

or

make build

Thoughts?

• utm_source=web_app_manifest- app manifest
• utm_source=schema_org_event

others?

The ServiceWorkerGlobalScope.skipWaiting() method allows the latest service worker to forcibly activate, regardless of whether there are other open tabs with pages controlled by older versions of the service worker.

It's not yet implemented in Chrome (last I checked), but once it is, we should make use of it. It should allow us to ditch that "Please force-refresh..." toast message.

We also want to measure the events:

polymer-ready
HTMLImportsReady
template-bound

These numbers should also be logged to GA. Window load and DOMContentLoaded are logged to GA under user timings. We have some of this from 🎅

• 2014 link to keynote and sessions - https://www.google.com/events/io/io14videos
• recap video
• past photos carousel

This isn't a high priority, but a potential optimization would be to disable AJAX-y navigations and use real browser navigations if we detect that 'serviceWorker' in navigator && navigator.serviceWorker.controller == null.

This indicates that the SW hasn't yet taken control of the page, most likely because it's the first time the user has visited. The SW won't start handling network requests until the next navigation to a page that's under the SW's scope (either a reload of the current page, or navigation to a new page), and that might be delayed much longer than it normally would due to AJAX-y navigations.

Meta-bug to track adding in web-compontent-tester-based tests to all custom Polymer elements in this project. The Unit Testing Polymer Elements guide provides best-practices.

I will start with countdown-timer.

https://ci.cloudware.io/github.com/GoogleChrome/ioweb2015/ajaxdrawer/3775558a55fccccb01fda5b0bdd0cbc8eca55345

This is after the merge with the bower resolution fixes.

Hi all,

I'm working on creating a new branch for the experiment integration, but it appears that I only have read-only access to this repo. Can @tdreyno and I have write access so that we can push the new branch?

Thanks!
-A

We need a page loader to fetch content/redirect user to correct subpage as needed. The plan would be:

1. Every page has a URL, e.g. /, /schedule/, /attend-on-site/ with appropriate section filled out and placeholders for other subpages.
2. If you visit that URL you get all the HTML, JS and CSS needed for the page.
3. If the page is loaded over AJAX we create a DOM fragment and querySelector out the bits we need
4. We use a barebones container into which we inject the bits we want, then transition.

The alternative approach would be to render a shell page and fetch partials (instead of full pages) in case of ajax request.

The benefits for full-pages approach is SEO, simplicity (on the server side at least), cacheability for SW, and we can have discrete URLs (so in case of JS error we have a meaningful experience). There's very little bloat overall, because none of the assets (images, CSS, JS) returned in the HTML will be fetched until they are injected into the page, which most of them won't be.

Thep lan is to go with the full-page load direction, and only if we discover it adds to complexity or is causing a perf issue we strip back to partials.

• - handle viewport resizing - #453
• - cycle through 10 city names - #111
• - On page load, one of the locations is selected. The names cycle through the names until it hits the correct city name, then stops.#135
• - GA events for glob interactions - #678
• - "view 2014 events" on /offsite page using auto complete input- #677
• - pins using /io2015/api/extended endpoint #680
• - deep link from homepage
• - fade in globes
• - pin need popup info #700
• - offsite globe should load somewhere where there is light -#707

Create a gulp task for measuring some basic performance metrics (e.g. time until the document is ready for each known page) and flag deviances from a baseline.

This is similar to what we could do with psi, but we can't use psi against our local dev builds. (This article about using ngrok probably isn't relevant, since I can't image we'll be able to set up the secure tunnel part.)

See #32

As part of #94, we're changing the way ajaxified pages are dynamically injected on the page.

To adapt to this change, the server needs to render the shell of the page (the reusable markup shared across all pages) as it is today. However, to server-side rendering on the initial page load, the server needs to now populate placeholder <template>s with a the correct partial .html file.

For example, when loading about.html, the server would render the index.html template and also populate the 2 template placeholders with the pieces of template/about_partial.html:

<template id="template-content-placeholder" ref="">
  innerHTML of about_partial.html's <template id="template-onsite-content">
</template>

It would also fill <template id=“template-about-masthead”>.

Upon user navigation, ajax injection takes over an the ref of each template is updated to the new page. Whatever the server rendered in template(s) on initial page load is no longer used :)

This setup will also allow us to remove one request on page load. We won't need to populate the templates on the client, the server will take care of it. SEO and speed friendly!

We currently have placeholder pages (about.html, schedule.html, onsite.html) that also need to be removed in favor of the server rendering the correct page.

@devnook

• - page design
• - recap video - #147
• - download guide #141
• - view 2014 events.
• - "Watch the 2014 I/O Extended recap video" @monicabagagem what video is this?

"It has a 35% black scrim over the whole video with at 80% opacity 72px play button with the cta below it. The cta is Roboto Medium 16pt with box-shadow: .5px .5px 1px rgba(0, 0, 0, 0.25)
"

For homepage, query @googledevs and +GoogleDevelopers for latest few posts with hash tag #io15. We should eventually setup a server-side cron for this.

The links should be clickable in tweets and the username links to the tweet, just link twitter does.

We should hide the section until there are at least 3 tweets. That'll be easy with <template repeat=""> and <template if="{{}}">.

From @devnook: "Drawer panel nav is outside of the main template is="autobinding", which makes it impossible to bind to the current route."

https://github.com/google/iosched/tree/master/art

The registration page uses it and has a diff bg color.

Service workers gives us the flexibility of precaching whatever resources we'd like (both local and cross-origin) during the install phase.

The temptation is to be aggressive and precache everything we might possibly need for all aspects of the site, but that does come at the cost of bandwidth consumption during the install phase of the service worker's lifecycle. This will be incurred across all clients every time we increment the service worker's cache versioning, so it's not even a one-time thing.

The code introduced in in #56 is one approach towards generating a list of resources to precache. As a starting point, the code in that PR is quite aggressive and pulls in almost everything. It needs to be refined when we agree upon a strategy.

Possibly swap in paper-item

There are various placeholder values for the date and venue added in #6 that need to be updated.

This because it's not in the DOM when this code runs: https://github.com/GoogleChrome/ioweb2015/blob/master/app/elements/countdown-timer/countdown-timer-renderer.js#L27

Since it's in an auto-binding template atm.