Breakout Session: Using App Maker to build apps quickly

App Maker Key tenants:

1. Speed to develop apps 
2. Integrated with other google products (and non-google products)
3. Components built with compliancy as a requirement

In business there exists a number of enterprise apps (e.g. Quickbooks for financials, Salesforce for CRM, etc.) which end up leaving operational gaps because all these products don't integrate seamlessly -- and really, they're not intended to do that.  Historically, these gaps have been filled with products like SharePoint, Excel Spreadsheets, etc.  App Maker is here to make that space and those gaps easier to fill without compliance issues.  

Google really kind of stumbled into this product by solving it's own problems where they had gaps. Here's a few examples:

• Google had a Google HR gap.  They realized that across all their different HR folks they were not operating consistently (some used spreadsheets to track candidates and some didn't, processes were not consistent, etc.).  Communications to candidates wasn't great either -- the experience as a customer (in this case, candidate) was never consistent.  The used App Maker to role out an application to integrate with sourcing tools (monster.com, dice.com, etc.), handle communications, manage tracking, and enforce consistent processes.    
• Another example, education reimbursement system.  Google employees are allowed to take courses and get reimbursed.  Google App Maker built an app to manage the budgets, approvals, etc.  

Now Google internally utilizes over 400 apps that were made using App Maker. Many of these built by people who didn't come from a CS background (which is awesome, lowers barriers to entry and can go from a need to a solution very quickly).

At some point in the hundreds they had an 'aha' moment and realized they had a good business case for an external-facing customer product.

Building an app from scratch - project tracker (link to the video for this from YouTube):

So all of this works with these underlying components:

Offered on G Suite for business (Sweeeeet!  Guess I won't be switching to Office 365 at least in the immediate future...).  Integration with as many google services as possible.  So, what are customers doing so far?

Ocado - online retailer in UK.  They had an internal process for managing training requests.  This could be something easily done with App Maker.  In about 30 hours of Engineering Time they had version 1 that was already making their world better.  

Quora - struggling to manage internal perk schedules.  They were using spreadsheets.  They used App Maker to build out a tool to do this in real-time using a dynamic data model.

So where are we going with App Maker?  This is the historical roll-out schedule:

App Maker is really good for Data Entry, Reporting, and Workflow (multi-stage process, includes several parts of the company, and is usual serial).  A lot of people are using it as a standalone bootstrapped Helpdesk tool.  What are the signals for good candidates for App Maker?:

• Large spreadsheets - good candidates for App Maker.  Large spreadsheets normally mean that several people own data in the spreadsheet.  Creating an app to manage who owns what and at what point they access or enter the data (via roles in the app) streamlines the process.  Can build pretty powerful edit checks directly into the forms (limits errors in data entry)
• Bulk Operations - onboarding new employees and including them in meetings, etc.
• Existing extensive scripting in the company (NOTE: didn't have a great example of a use-case for this one)

What's next?  Google wants it to be open platform (create a community, etc.), increase ease of use, and create shared apps.  The Codelabs are a really powerful way to get people trained quickly, go to the website and in only a few hours you can become an expert in developing apps using the product:

Breakout Session: Notifications and UX Design in Android O

So the UX team started with research by going on a UXpedition.  They went to NYC for 3 weeks - talked to users, observed them, interviewed them, etc.  A few major insights:

• Biggest use case is to keep notifications that users don't care about from happening
• Notifications from people (either generated by a message, email, etc.) are more important than those that are just from apps
• Lot of noise from apps and not an intuitive way to either a) manage settings for them and b) group/organize the actual notifications

So to address these issues Channels (a way for apps to group notifications and set up settings for each channel) was developed in Android O.  This groups similar notifications from an app into a 'Channel'.  You can access settings for these directly from the notification shade by long-pressing the notification.  This also allows for all apps to have some consistency with how they manage settings for notifications.  I believe it's on the app developer to decide what the channels are and which notification types each channel includes.  Here's how the settings use-case is handled without Channels (current implementation in Android N) and with Channels (new in Android O):

Android O extends the base functionality that was rolled out in N.  Here are the research insights:

Visual hierarchy of the notifications and why they're set up this way:

Here's the breakout of each category and why and comparison to Android N:

Major Ongoing category:

People to People - missed the first slide that has the details about what these are:

General - no behavior or visual changes.  In O though a lot of these general are now being set as BTW.

By the Way (BTW):

Here's the comparison of an example of the same apps/notifications for each category (N is on the left, O is on the right):

Snoozing feature - people need to remember things they need to do.  Today we can only dismiss (or leave it in shade but now it has a risk of being lost).  If you partial swipe you get two icons, one of them is the gear (settings) which already exists in O and the other is a clock to snooze.  You can adjust by tapping the downward arrow.

Day 3: Pheebs' Relatives and Getting There

Got a picture with Dorothy (Phoebe's great aunt) and Bob (her son) this morning.  They've been awesome hosts and we've been pretty bad guests -- I don't think we've spent more than 20 min with them because we're up at 7am to get to the conference and they're in bed well before we get home.  We did get a few pics with them this morning though -- they leave today for the weekend and are kind enough to let us stay while they're out -- but not before I locked us out of the house (closed the kitchen door behind us without checking it was locked when we took the pictures outside).  Luckily Bob was able to break back in.

Caught a ride with a brasileiro from brazilia this morning.  I think I threw him off so much by speaking portuguese to him that he canceled our ride 100 ft. in -- I didn't realize this until 5 minutes later when I got a notification on my phone to rate him while I was still in the car.  I asked him about it and he said it was his fault and he'd take us the rest of the way for no charge.  I said no way and ended up tipping him the amount of the ride in addition to what was charged for the short $100 ft ride.  I did say it would cost him a picture though:

Day 2: After Hours

We spent some time in the Experiments tent after the last breakout session (which focused on Design Sprints and was probably the most relevant session to what I actually do today as a project manager).  The Experiments tent had 5 or 6 apps/games that utilize Machine Learning and/or VR to include the following:

• VR ping pong game where you move a paddle with your head and try to hit the ping pong ball (think of Wii tennis but moving your head instead of a controller)
• Drawing game where the computer would list objects and you have to draw that object to get a point (pretty accurate).  I played Pheebs twice and went 1-1; rubber match will be at some point on our last day (today).  
• A drag and draw app where you can draw a line/squiggle and it will find an image in Gmaps or Earth and align to that squiggle and then one where you can draw continuously and it will build a tapestry of images by connecting them in a quilt-like fashion
• An app where you can take a picture of an object and the phone will work the name of that object into the lyrics of a song it's currently singing
• A learning app where you can train a switch based on an image (thumbs up to turn on light, thumbs down to turn off) then you can initiate the switch by making that gesture

We also went to the concert with was opened by Holy Ghost (two DJs) and then headlined by LCD Soundsystem.  Was actually a pretty good concert.  Got even better after the 4th beer I had from Tristan working the beer stations again.  Here are some images/video:

Breakout Session: V8 and future of web performance with JavaScript

V8 is the engine that runs Javascript in Chrome.  Important to make sure the engine matches the language as the language changes.  Specifically, V8 is a JIT (Just-in-time) compiler.  In general, the more optimization an engine performs, the faster the machine code it generates, but the longer the initial delay.  In general more optimizations an engine performs the more memory the engine consumes.  Tradeoffs in the engine - fast startup vs. peak performance and low memory vs. max optimization:


For example, web page has one line of code (e.g. foo(42);) an interpreter can perform that very quickly. Here's the example:

But if we know the function is going to be run 10,000 times you would want to take the capital cost of optimization up front and increase peak performance.

What if this is being run by a low-memory device (phone)?  Then we might want something like this:

Takeaway - code requires many different optimal translations depending on context (e.g. phone, server, IoT device, etc.).

With this in mind V8 has been looking at a completely new execution pipeline.  Here's the history:

TurboFan is an optimizing compiler.

Ignition is an interpreter and has a small memory footprint but faster startup.  It's integrated with TurboFan so that if a page is loaded many times it can pass it to TurboFan.  This allows for a lot of different configurations.

It's optimized for Node.js - this is server side language that imbeds the V8 engine.