Internet News

Conversions: PWAs, Payment Experiences and More

LukeW - Mon, 11/05/2018 - 2:00pm

In her PWAs, Payment Experiences and More presentation at Google Conversions 2018 in Dublin Ireland, Jenny Gove talked through the new capabilities available on the Web to build fast and engaging products. Here's my notes from her talk:

  • The Web was built for desktop devices, not mobile. Native apps, in contrast, were built from the ground up for mobile. So it's no surprise that Web sites are still catching up in terms of experience. While there are great mobile Web experiences, most have a lot of work to do.
  • To help incentivize people to improve mobile Web experiences, Google added the "mobile-friendly" label to search results. When 85% of results in mobile search met this criteria, the label was removed.
  • Progressive Web apps bring richer experiences to the Web through a set of technologies that enable fast, installable, reliable, and engaging. They're the next step in making great Web experiences.
  • Speed is critical for mobile Web sites but it takes a mobile Web page a median time of 9.3 seconds to load on 3G. Pinterest reduced their time for interactive from 23 seconds to 5.6 seconds with their PWA. This resulted in a 60% increase in engagement and a 2-3% improvement over their native app.
  • You can improve speed with technical changes and design (to manage perception). Lighthouse is a tool from Google that shows time to meaningful paint and other relevant metrics for improving technical performance. You can manage user perception of speed using skeletong screens and gradual loading of content.
  • PWAs allow you to add mobile Web pages to your phone's home screens. On Android these apps show up in app switchers and setting screens.
  • Service workers in PWAs enable reliable experiences when there is no network or slow and intermittent network connections. Even in developed markets, slow network conditions often exist. Service workers are now available in all major Web browsers.
  • PWAs make use of Web technologies at the right time and place like app permissions, push notifications, payment request APIs, and better form interactions (autocomplete, input types, etc.)
  • 42% of top sites in Europe don't show the appropriate keyboard for specific input types. 27% of the top site in Europe didn't identify which form fields are optional.
  • Google Search uses a PWA to enable offline queries and send results when people are back online using notifications. With a PWA they were able to use 50% fewer external JavaScript requests.
  • In the Starbucks PWA, daily & monthly active users have nearly doubled (compared ot the previous Web experience) and orders placed in the PWA are growing by more than 12% week over week.
  • While mobile has really driven PWA requirements, desktop devices also benefit from PWA app switching and integration. Service workers, push notifications, and other new Web technologies work on desktop as well.
  • It's possible to run PWAs on the desktop in app windows which can be themed. These apps need to use responsive design to adapt from small sized windows to full-sized screens.
  • What's next for PWAs? Support for Windows, macOS and Linux, Keyboard Shortcuts, Badging the launch icon, and Link capturing.
  • Watch the full video of Jenny's: PWAs, Payment Experiences and More talk

An Event Apart: Designing Progressive Web Apps

LukeW - Mon, 08/27/2018 - 2:00pm

In his The Case for Progressive Web Apps presentation at An Event Apart in Chicago, Jason Grigsby walked through the process of building Progressive Web Apps for your Web experiences and how to go about it. Here's my notes from his talk:

  • Progressive Web Apps (PWAs) are getting a lot of attention and positive stories about their impact are coming out. PWA Stats tracks many of these case studies. These sorts of examples are getting noticed by CEOs who demand teams build PWAs today.
  • A PWA is a set of technologies designed to make faster, more capable Web sites. They load fast, are available online, are secure, can be accessed from your home screen, have push notifications, and more.
  • But how can we define Progressive Web Apps? PWAs are Web sites enhanced by three things: https, service worker, and a manifest file.
  • HTTPS is increasingly required for browsers and APIs. Eventually Chrome will highlight sites that are not on https as "insecure".
  • Service Workers allow Web sites to declare how network requests and the cache are handled. This ability to cache things allows us to build sites that are much faster. With service workers we can deliver near instant and offline experiences.
  • A Web manifest is a JSON file that delivers some attributes about a Web site. Browsers use these files to make decisions on what to do with your site (like add to home page).
  • Are PWAs any different than well-built Web sites? Not really, but the term helps get people excited and build toward best practices on the Web.
  • PWAs are often trojan horses for performance. They help enforce fast experiences.
Feels Like a Native App
  • Does your organization have a Web site? Do you make money off your Web site? If so, you probably need a Progressive Web Site.
  • Not every customer will have your native app installed. A better Web experience will help you reach people who don't. For many people this will be their first experience with your company, so you should make it as good as possible.
  • Getting people to install and keep using native apps is difficult. App stores can also change their policies and interfaces which could negatively impact your native app.
  • The Web can do much more than we think, the Web has APIs to access location, do fast payments using fingerprint identification, push notifications, and more.
  • What should we use to design PWAs? Native app styles or Web styles? How much does your design match the platform? You can set up PWAs to use different system fonts for iOS and Android, should you? For now, we should define our own design and be consistent across different OSs.
  • What impact does going "chrome-less" have on our PWAs? You loose back buttons, menu controls, system controls. Browsers provide us with a lot of useful features and adding them back is difficult. Especially navigation via the back button is complex. So in most cases, you should avoid going full screen.
  • While not every person will add your PWA to their home screen, every person will "install" your PWA via the service worker.
  • An app shell model allows you put your common UI (header, footer, nav, etc.) into the app cache. This makes the first loading experience feel a lot faster. Should you app shell or not? If you have architected as a single page app, this is possible but otherwise might not be worth the effort.
  • Animating transitions can help with way-finding and polish on the Web. This gives Web sites even more personality.
Installation and Discovery
  • Using a Web manifest file, allows you specify a number of declarations for your app. In addition to name, icon, and even theme colors.
  • Once you have a PWA built and a manifest file, browsers will being prompting people to install your Web site. Some Browsers have subtle "add" actions. Other use more explicit banner prompts. "Add to home screen" banners are only displayed when they make sense (certain level of use).
  • Developers can request these banners to come up when appropriate. You'll want to trigger these where people are mostly likely to install. (like checkout)
  • Microsoft is putting (explicitly and implicitly) PWAs within their app store. Search results may also start highlighting PWAs.
  • You can use Trusted Web Activity or PhoneGap to wrap native shells around your PWA to put them into Android and iOS app stores.
Offline Mode
  • Your Web site would benefit from offline support. Service Workers enable you to cache assets on your device to load PWAs quickly and to decide what should be available offline.
  • You can develop offline pages and/or cache pages people viewed before.
  • If you do cache pages, make it clear what data hasn't been updated because it is not available offline.
  • You can give people control over what gets cached and what doesn't. So they can decide what they want available for offline viewing.
  • If you enable offline interactions, be explicit what interactivity is available and what isn't.
Push Notifications
  • Push notifications can help you increase engagement. You can send notifications via a Web browser using PWAs.
  • Personal push notifications work best but are difficult to do right. Generic notifications won't be as effective.
  • Don't immediately ask people for push notification permissions. Find the right time and place to ask people to turn them on. Make sure you give people control, if you'd don't they can kill them using browser controls.
  • In the next version of Chrome, Google will make push notification dialogs blocking (can't be dismissed) so people have to decide if they want notifications on or off. This also requires you to ask for permissions at the right time.
Beyond Progressive Web Apps
  • Auto-login with credential management APIs allows you to sign into a site using stored credentials. This streamlines the login process.
  • Apple Pay on the Web converged with the Web Payment API so there's one way to use stored payment info on the Web.
  • These next gen capabilities are not part of PWAs but make sense within PWAs.
How to Implement PWAs
  • Building PWAs is a progressive process, it can be a series of incremental updates that all make sense on their own. As a result, you can have an iterative roadmap.
  • Benchmark and measure your improvements so you can use that data to get buy-in for further projects.
  • Assess your current Web site's technology. If things aren't reasonably fast to begin with, you need to address that first. If your site is not usable on mobile, start there first.
  • Begin by building a baseline PWA (manifest, https, etc.) and then add front-end additions and larger initiatives like payment request and credential api later.
  • Every step on the path toward a PWAS make sense on their own. You should encrypt your Web sites. You should make your Web site fast. These are all just steps along the way.

An Event Apart: Data Basics

LukeW - Mon, 08/27/2018 - 2:00pm

In her Data Basics presentation at An Event Apart in Chicago, Laura Martini walked through common issues teams face when working with data and how to get around/work with them. Here's my notes from her talk:

  • Today there's lots of data available to teams for making decisions but it can hard to know what to use and how.
  • Data tools have gotten much better and more useful. Don't underestimate yourself, you can use these tools to learn.
  • Google Analytics: The old way of looking at data is based on sessions are composed of page views and clicks with timestamps. The new way is looking at users with events. Events can be much more granular and cover more of people's behaviors than page views and clicks.
  • Different data can be stored in different systems so it can be hard to get a complete picture of what is happening across platforms and experiences. Journey maps are one way to understand traffic between apps.
  • You can do things with data that don't scale. Some visualizations can give you a sense of what is happening without being completely precise. Example: a quantified journey map can show you where to focus.
  • Individual users can also be good data sources. Zooming in allows you to learn things you can't in aggregate. Tools like Fullstory replays exactly what people did on your Website. These kinds of human-centric sessions can be more engaging/convincing than aggregate measures.
  • Data freshness changes how people use it in their workflows. Having real-time data or predictive tools allows you to monitor and adapt as insights come in.
  • How do you know what questions to ask of your data? HEART framework: happiness, engagement, adoptions, retention, and task success. Start with your goals, decide what is an indicator of success of your goals, then instrument that.
  • To decide which part of the customer journey to measure, start by laying it all out.
  • There's a number of good go-to solutions for answering questions like: funnel analysis (shows you possible improvements) or focus on user groups and split them into a test & control (allows you to test predictions).
  • The Sample Size Calculator gives you a way to determine what size audience you need for your tests.
  • Quantitative data is a good tool for understanding what is happening but it won't tell you why. For that, you often need to turn to qualitative data (talking to people). You can ask people with in-context small surveys and similar techniques.
  • Often the hardest part of using data is getting people on the same page and caring about the metrics. Try turning data insights into a shared activity, bet on results. Make it fun.
  • Dashboards surface data people care about but you need to come together as a team to decide what is important. Having user-centric metrics in your dashboards shows you care about user behavior.
  • Data can be used for good and bad. Proceed with caution when using data and be mindful where and how you collect it.

An Event Apart: Content Performance Quotient

LukeW - Sun, 08/26/2018 - 2:00pm

In his Beyond Engagement: the Content Performance Quotient presentation at An Event Apart in Chicago, Jeffrey Zeldman introduced a new metric for tracking how well Web sites are performing. Here's my notes from his talk:

  • The number one stakeholder request for Web sites is engagement: we need people using our services more. But is it the right metric for all these situations?
  • For some apps, engagement is clearly the right thing to measure. Think Instagram, long-form articles, or gaming sites. For others, more time spent might be a sign of customer frustration.
  • Most of the Web sites we work on are like customer service desks where we want to give people what they need and get them on their way. For these experiences, speed of usefulness should matter more than engagement.
  • Content Performance Quotient (Design CPQ) is a measure of how quickly we can get the right content to solve the customer's problem. The CPQ is a goal to iterate against and aim for the shortest distance between problem & solution. It tracks your value to the customer by measuring the speed of usefulness.
  • Pretty garbage: when a Web site looks good but doesn't help anyone. Garbage in a delightfully responsive grid is still garbage. A lot of a Web designer's job is bridging the gap between what clients say they need and what their customers actually need.
  • Marlboro's advertising company (in the 50s) rethought TV commercials by removing all the copy and focusing on conveying emotions. They went from commercials typically full of text to just ten words focused on their message.
  • Mobile is a great forcing function to re-evaluate our content. Because you can't fit everything on a small screen, you need to make decisions about what matters most.
  • Slash your architecture and shrink your content. Ask: "why do we need this?" Compare all your content to the goals you've established. Design should be intentional. Have purpose-driven design and purpose-driven content. If your design isn't going somewhere, it is going nowhere.
  • We can't always have meetings where everybody wins. We need to argue for the customer and that means not everyone in our meetings will get what they want. Purpose needs to drive our collaborations not individual agendas, which usually leak into our Web site designs.
  • It’s easy to give every stakeholder what they want. We've enabled this through Content Management Systems (CMS) that allow everyone to publish to the site. Don't take the easy way out. It’s harder to do the right thing. Harder for us, but better for the customer & bottom line.
  • Understanding the customer journey allows us to put the right content in the right place. Start with the most important interaction and build out from there. Focus on key interactions and build out from there. Sometimes the right place for your content isn't your Website -for video it could be YouTube or Vimeo.
  • Customers come to our sites with a purpose. Anything that gets in the way of that is a distraction. Constantly iterate on content to remove the cruft and surface what's needed. You can start with a content inventory to audit what is in your site, but most of this content is probably out of date and irrelevant. So being in a state of constant iteration works better.
  • When you want people to go deeper and engage, to slow down... scannability, which is good for transactions, can be bad for thoughtful content. Instead slow people down with bigger type, better typographic hierarchy, more whitespace.
  • Which sites should be slow? If the site is delivering content for the good of the general public, the presentation should enable slow, careful reading. If it’s designed to promote our business or help a customer get an answer to her question, it must be designed for speed of relevancy.

An Event Apart: Full-Featured Art Direction

LukeW - Sun, 08/26/2018 - 2:00pm

In her Full-Featured Art Direction for the Web presentation at An Event Apart in Chicago, Mina Markham shared her approach to building Web pages that work across a variety of browsers, devices and locales. Here's my notes from her talk:

  • Full-featured art direction is progressively enhanced, localized for a particular user, yet inclusive of all visitors and locations.
  • Start with the most basic minimal viable experience for the user and move up from there. Semantic markup is your best baseline. Annotate a Web site design with HTML structure: H1, H2, H3, etc. From there, gradually add CSS to style the minimal viable experience. If everything else fails, this is what the user will see. It may be the bare minimum but it works.
  • Feature queries in CSS are supported in most browsers other than IE 11. We can use these to set styles based on what browsers support. For instance, modular font scaling allows you to update overall sizing of text in a layout. Feature Query checker allows you to see what things look like when a CSS query is not present.
  • Localization is not just text translation. Other elements in the UI, like images, may need to be adjusted as well. You can use attributes like :lang() pseudoclass to include language specific design elements in your layout.
  • Inclusive art direction ensures people can make use of our Web sites on various devices and in various locations. Don't remove default behaviors in Web browsers. Instead adjust these to better integrate with your site's design.

Wed, 12/31/1969 - 2:00pm
Syndicate content
©2003 - Present Akamai Design & Development.