Online Resource

Online Resource

Online Resource

Hayden Library - QH438.7.C656 2017

Hayden Library - QH431.B6324 2018

Hayden Library - QH506.B57 2020

Hayden Library - QH331.S437 2018

Online Resource

Hayden Library - QH447.G4666 2018

Online Resource

Hayden Library - QH588.S83 K45 2019

Online Resource

Online Resource

Online Resource

Online Resource

Hayden Library - QH450.S85 2019

Online Resource

Online Resource

Online Resource

Hayden Library - QH305.2.G3 S74 2019

Online Resource

Hayden Library - QH205.2.M47 2019

Online Resource

Online Resource

Dewey Library - QH331.E85 2018

Dewey Library - QH331.F35 2019

Online Resource

Online Resource

Dewey Library - QH507.L47 2019

Online Resource

Dewey Library - QH332.B25 2019

Online Resource

Online Resource

Dewey Library - QH501.D38 2019

Online Resource

Dewey Library - QH438.4.S73 B53 2019

Online Resource

Online Resource

Online Resource

Dewey Library - QH588.S83 S7456 2019

Hayden Library - QH450.B34 2018

Dewey Library - QH309.G676 2019

Dewey Library - QH305.C29 2019

Across several presentations at Google Conversions in Dublin, several speakers shared insights and best practices for conversion rate optimization. Here's a few highlights:

Confirmation Bias - Michael Aagaard

• In the 18th century, tobacco smoke was considered very good for your heart and lungs. In particular tobacco enemas were quite popular so much that they were placed along the banks of the river Thames to help drowning victims. This is an example of confirmation bias at work.
• Confirmation biases is our tendency to accept evidence we agree with at face value and dismiss information we don't agree with unless the evidence is overwhelming. Confirmation biases limits our ability to seek out and uncover the truth.
• Torturing data: if you torture any data long enough it will confess to anything. High levels of correlation between things don't imply causation. We have to be careful to not see what we want in data.
• Stopping A/B tests when they show the impact we want is an example of confirmation bias. Instead, let them run for an appropriate amount of time. Over time, tests are likely to show much less effects.
• How to overcome confirmation bias: accept the fact that you could be wrong, seek out a different perspective. Find people who talk to customers/users. They have a bias toward end users.
• Don't test your ideas, do detective work to find out what customers need and how they talk about it. Then your A/B test is simply the final test at the end to see if you did your detective work well.

CRO - Lina Hansson

• Celebrate the discovery of weak spots. Don't take it as failure but instead be happy when you find something that can be improved.
• The biggest missed opportunity in conversion rate optimization is usability testing. Move away from opinions and instead use user testing to identify issues.
• A common pain point across retail sites is find-ability: both search and browse. When we move to mobile, many sites remove their top categories list in order to fit on smaller screens. This creates discoverability issues. One of the first things retail sites should test is adding categories visibly on their home page.
• Value propositions for companies are usually cut for mobile. Instead of removing them, redesign them to make them work on mobile.
• People can be classified into four behavior types. Methodical people read completely and analyze before making decisions. Humanistic people react strongly to the opinions of others. Competitive people move quickly and expect things to work. Spontaneous people are emotional and fast-paced. You can design experiences that are appropriate for each of these behavior types.
• The companies that solve checkout on mobile are the ones that will win.

Meaningful Data - Simo Ahava

• It's quite simple to get a service like Google Analytics set up but how do we use these tools to really understand what we're doing. How can data become meaningful?
• Tactics (tool expertise) without a strategy (business expertise) are just party tricks and a strategy without tactics is just talk. What brings the two together is agility.
• Tools must be customized for your organization's needs. We are not trying to optimize metrics but our businesses. Default metrics and reports need to be adjusted to work with your specific needs.

Landing Pages - Anna Potanin

• Designers want to do their best and create unique interfaces but making things for the Web often requires understanding and using conventions. Only apply a unique visual design after you have followed best practices.
• 3 things all retail sites should have on their landing and home pages: call to action, value propositions, and visuals.
• The more prominent you make your search bar, the more searches you get. Why do you want to do this? Conversion rates are usually much higher for people who search

For the past six years, I've presented a walkthrough of the latest mobile data and design insights and solutions I've been exploring at Google's Conversions event in Dublin. This year's video recording is now live.

This year's presentation is a data-informed big picture view of our mobile planet, how to design products for it, and why covering on-boarding, performance, touch gestures, and more.

All Annual Sessions:

• Conversions@Google 2018 session on our Mobile Planet
• Conversions@Google 2017 (November) session on Mobile in The Future
• Conversions@Google 2017 (April) session on Mobile in The Future
• Conversions@Google 2016 session on Obvious Always Wins
• Conversions@Google 2015 session on Screen Time
• Conversions@Google 2014 session on Mobile Design Now
• Conversions@Google 2013 session on One Design for a Multi-Device Web

Big thanks to the Conversions@Google team for making these sessions available to all.

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.

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.

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.

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.

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