You are here

Feed aggregator

How companies can get started with AI

O'Reilly Radar - Mon, 2018/07/30 - 04:00

The program for our Artificial Intelligence Conference in London is structured to help companies that are still very much in the early stages of AI adoption.

Judging by the list of countries putting out policy papers on AI and automation technologies, there is very strong interest in AI across the globe. In order to asses the current state of readiness across regions, we recently conducted a survey (full report forthcoming) of the state of adoption of machine learning tools and technologies (a lot of what is being currently described as AI is really ML). The survey yielded 11,400+ respondents, including 2,000 respondents from Europe:

As we assembled the program for our inaugural Artificial Intelligence Conference in London this October, we recognized that many companies and organizations around the world are still very much in the early stages of adoption. Anyone wanting to get started on AI technologies will have to wade through an array of methods and technologies, many of which are still very much on the leading edge. The good news is that some companies at the forefront are beginning to share best practices, tools, and lessons learned as they deploy AI technologies. In this short post, I’ll use key portions of our AI conference in London to describe how companies may want to get started in AI.

AI in the Enterprise: Best practices

Has machine learning impacted how companies organize and build teams? We found that as companies gain more experience with machine learning, they are more likely to start hiring and attracting specialists, including data scientists, research scientists, and machine learning engineers.

But there are many more decisions companies need to make on the path to embracing AI. Organizations must work through a series of assessments in order to successfully deploy AI and automation technologies:

  • What are the key technologies (hardware and software) and what are their limitations?
  • How much data does one need to use these technologies? Where can I get data to augment my existing data sets?
  • How does one organize and hire for AI?
  • What types of problems or tasks lend themselves to automation? What are some initial use cases one can consider?
  • How do you maintain momentum and build upon the lessons learned from previous projects?

We put together training programs, tutorials, and sessions designed to help attendees understand how to move forward with best practices, tools, and technologies used at many leading companies.

Early applications of AI technologies

As I noted earlier, much of the current excitement around AI pertains to recent progress in machine learning—specifically deep learning and reinforcement learning. Both of these class of methods impact existing products and data types (text, temporal, and structured data) and also enable companies to unlock new data sources (including audio, video, and images). Progress in automating enterprise workflows will depend on foundational technologies (hardware and software) and breakthroughs in areas like computer vision, natural language understanding and generation, and speech technologies. We are beginning to see many interesting enterprise applications of both deep learning and reinforcement learning, particularly in computer vision and text, but also in areas where many enterprises already had analytic solutions in place (recommenders and forecasting tools).

Implementing AI

AI applications rely on machine learning models, as well as hardware and software infrastructure for model training, deployment, and management. Machine learning itself requires robust end-to-end data pipelines spanning data ingestion, data preparation, and data management. Depending on the nature of the application, a knowledge base or graph, components for reasoning and planning, simulation platforms, and user interfaces might also come into play. For our upcoming AI conference in London, we assembled sessions on many of core components in an AI technology stack. We have content ranging from tutorials on how to use specific libraries and technologies to how to launch data markets and networks to sessions on best practices for building and architecting AI applications.

Case studies

Among the many the challenges faced by organizations is identifying good use cases for AI and automation technologies. One of our main goals for this conference series is to foster a community of professionals interested in building and using AI applications. To that end, we put together a series of sessions where companies describe how they put AI technologies to work within their organizations. We are also planning a series of attendee networking events at the conference. Here’s a sampling of sessions from a few domains:

Ethics, privacy, security

As I noted in a recent post, there is growing awareness among major stakeholders about the importance of data privacy, ethics, and security. In our recent ML adoption survey, we found that respondents are starting to engage and they are beginning to take into account factors such as bias, transparency, and privacy in their machine learning systems. Fairness and transparency, and privacy-preserving analytics have become areas of active academic research, but it’s important to emphasize that tools and best practices are just beginning to emerge. These concerns cut across geographic regions and industries, but with the launch of GDPR, Europe stands out for taking a leadership position in data privacy. AI policy papers from several European countries also emphasize the need for fairness and transparency in machine learning and AI. With all these considerations in mind, for our inaugural Artificial Intelligence Conference in London we have assembled an outstanding series of presentations on the practical aspects of incorporating ethics, privacy, and security into AI systems.

Continue reading How companies can get started with AI.

Categories: Technology

Four short links: 30 July 2018

O'Reilly Radar - Mon, 2018/07/30 - 01:00

Lightbulb Moments, Crowd Simulations, Secrets and Accountability, and Whole Genome Sequencing

  1. Phoebus Cartel (Wikipedia) -- a fascinating piece of history I never knew about: lightbulb manufacturers banding together to shorten lifetimes and raise profits. Reminds me of Adam Smith's great line: "People of the same trade seldom meet together, even for merriment and diversion, but the conversation ends in a conspiracy against the public, or in some contrivance to raise prices."
  2. The Wisdom And/Or Madness of Crowds -- nifty little interactive that gives you a deeper understanding of network theory. I am a huge believer in simulations as teaching mechanism.
  3. Practical Accountability of Secret Processes -- aimed at the court system we illustrate how accountability and secrecy are simultaneously achievable when modern cryptography is brought to bear. Our system improves configurability while preserving secrecy, offering new tradeoffs potentially more palatable to the risk-averse court system.
  4. Dante Labs Whole Genome Sequencing -- get every base pair in your DNA sequenced for USD500, and own the data (unlike 23andme and similar services, which only test some known single-basepair markers, and then own and resell your data). Making sense of the data left as an exercise to the reader.

Continue reading Four short links: 30 July 2018.

Categories: Technology

How information architecture facilitates information finding

O'Reilly Radar - Fri, 2018/07/27 - 03:30

Strategies for assisting users in their journey to find information.

Continue reading How information architecture facilitates information finding.

Categories: Technology

Four short links: 27 July 2018

O'Reilly Radar - Fri, 2018/07/27 - 03:00

Security Keys, Speech Recognition, Kubernetes Security, and Strategic Competition

  1. Security Keys Neutralized Employee Phishing -- Google has not had any of its 85,000+ employees successfully phished on their work-related accounts since early 2017, when it began requiring all employees to use physical Security Keys in place of passwords and one-time codes.
  2. The Accent Gap (WaPo) -- We tested Amazon's Alexa and Google's Home to see how people with accents are getting left behind in the smart-speaker revolution. Ok, so first up: everyone has an accent, it's just that software has been preferentially trained on some of them. But also: I know teachers who use Android's voice recognition to help students acquire a mainstream accent, a useful skill for them to have. This isn't all bad.
  3. Kubernetes Security Best Practices -- my goal in this article is to cover some common security mistakes I have observed and offer some general best practices around securing Kubernetes clusters and workloads.
  4. Strategic Competition in an Age of AI -- Software often diffuses much more easily than hardware, both because of the commercial incentives that can drive software creation and because the talent pool necessary to create new software can exist even in countries that are not generally major military producers, such as advanced economies in Asia. The key elements of national power in AI are therefore related to the question of whether it makes sense to think about AI as software or hardware.

Continue reading Four short links: 27 July 2018.

Categories: Technology

9 critical tools for designing a product

O'Reilly Radar - Thu, 2018/07/26 - 03:30

Product design is not a linear process. It’s a set of tools.

Designing for Validation

In this chapter:

  • Learn why you should design a test before you design a product.

  • Get nine tools that are critical for designing your product.

  • Understand which of those tools you can safely skip depending on what you’re building and for whom.

I should warn you, if you’re already a professional designer of any sort, you may find some of the following tedious or infuriating. That’s OK. This isn’t meant to teach professional designers to be even better at their jobs. This is meant to teach other people how to do enough design to validate or invalidate their initial hypotheses. It’s also meant to teach designers how to design in Lean environments and validate their work.

Design is a rich and complicated field that people study for their whole lives with varying degrees of success. Even worse, there are dozens of different disciplines within design—for example, figuring out how a complicated product should work is different from designing a beautiful brochure, which is different from designing a physical object. These are all called design. Probably because we are designers and not linguists.

Figure 1-1. Why designers shouldn’t be allowed to name things

But, at its heart, design is about solving problems. Once you’ve defined your problem well and determined what you want your outcome to be, Lean UX encourages you to do as little work as possible to get to your desired outcome, just in case your desired outcome isn’t exactly perfect. That means doing only the amount of design you need to validate your hypothesis.

Sometimes doing very little design is even harder than doing a lot of design. Because the trick is knowing what sort of design is the most important right this second and what is just a waste of time.

If you’ve done your research, you should understand your problem, your market, and your product concept pretty thoroughly. You hopefully have a problem you want to solve and an idea of a feature or product that might solve it. Now you need to build something.

Maybe this should be obvious, but there are all sorts of different kinds of things that you need to build over the course of a product’s life span. A lot of advice just focuses on the very first time you build something—the initial product.

But the vast majority of design decisions happen after you’ve built a product. You are constantly iterating and changing your initial product. Or, at least, you should be.

Here are some of the things you will have to do in the course of building and rebuilding your product. All of these require some amount of design:

  • Fix a bug.

  • Deal with an error state.

  • Make a small change in a user flow.

  • Create an entirely new feature.

  • Do a complete visual redesign.

  • Tweak an existing visual design.

  • Reorganize the product.

  • Build a whole new product.

  • Redesign for another platform.

Just to make things even more confusing, there is a whole lot of gray area between some of these. For example, some bug fixes are typos, others fundamentally change the process a user goes through, and some may not have any obvious user impact at all.

But all these different types of changes have one very important thing in common: In Lean UX, you should be designing just enough to validate your hypothesis. And no more.

There is a process for doing this in a Lean way, and I’m going to describe it here. As I describe it, you’re going to be thinking to yourself, “This seems like a huge amount of work!”

And the thing is, it is a lot of work. Lean design is not lazy design. It’s not about skipping steps or doing a shoddy job or not thinking through the user experience. In fact, Lean UX has a huge amount in common with traditional User-Centered Design and also with Agile Design, neither of which are particularly easy.

I started this section by writing a step-by-step guide for designing a product, but I kept wanting to write, “The next step is X except for when it isn’t.” That’s when I realized that this sort of design is not a linear process. It’s a set of tools.

Sometimes, in the course of building a product or a feature, you’ll use all these tools. Sometimes you’ll skip one or two steps. That’s OK. The key is to understand the tools well enough to know when it’s safe to skip one.

Tool 1: Truly Understand the Problem

The first tool in any sort of design is truly understanding the problem you want to solve. In this way, Lean UX is no different from any other sort of design theory. Sadly, it’s pretty different from the way a lot of people practice design.

The vast majority of time I talk to entrepreneurs, they present me with solutions rather than problems. They say things like, “I want to add comments to my product,” not “My users don’t have any way to communicate with one another, and that’s affecting their engagement with my product.”

By rephrasing the problem from your user’s point of view, you help yourself understand exactly what you are trying to do before you figure out how to do it.

I’m not going to rehash how you might understand the problem you’re trying to solve. If you’re confused by this, go back and read not available through Designing for Validation. I’ll give you a hint: It involves listening, observation, and other sorts of research.

One note to make here is that often research won’t be confined to just users. We’ve been talking a lot about listening to your users, and that is clearly the most important thing you can be doing. But this is the point where you also need to listen to stakeholders within your company.

If you’re part of a small startup, luckily this will be quick. Make sure that you have involved the people in your organization most likely to understand the problem you’re trying to solve. These people could be practically anybody in the organization—customer service folks, engineers, and salespeople are obvious choices if they exist.

Just remember that there are people within your organization who may understand the problem better than you do, and make sure that you’re incorporating their knowledge into the design process. They’re not creating the final designs or telling you exactly what people need. They’re weighing in with their thoughts about business needs, and their input should be weighed against the input from the customers.

Let’s imagine that you already have a product with some people who are using it. However, as with many startups, you are getting signals that your product is confusing. For example, many people visit your product or download your app and then never use it again. That’s a good sign that you’re not solving the problem people thought you’d be solving for them. Your first step is to start by understanding the problem better.

For example, you need to figure out your user base:

  • What sort of people are using your product?

  • How familiar with technology are they?

  • Are you mainly trying to help new users or existing users?

  • Are they paying you or using your product for free?

You need to understand the context in which they’ll be using your product:

  • Are they looking for quick help on the go or are they at a desk and ready to commit time to learning about your product?

  • Do they need help from an expert, or will help from other users work?

  • Are they likely to have problems in the middle of something critical and time sensitive?

You need to learn more about your user needs:

  • Are they using your product for fun? For work? To make themselves more productive?

You may already know the answer to a lot of these questions, but don’t assume the same is true of any problem you’re trying to solve for your users. Figure out the types of users, context, and needs for any specific problem you’re trying to solve. You’ll use all of this information in all of the following steps.

When Is It Safe to Skip This?

It is never, ever safe to skip this. If you don’t understand the problem, you can’t solve it.

Tool 2: Design the Test First

If I had to pick one thing that really sets Lean UX design apart from all other sorts of design, it would be this. Lean UX always has a measurable goal, and you should always figure out how to measure that goal before you start designing. If you don’t, how will you know that your design worked? Here’s a real-life example. Once upon a time, I worked at IMVU. For those of you who don’t know, IMVU allows its users to create 3D avatars and chat with other people from around the world. Users customize their avatars with all sorts of virtual goods, like clothes, pets, and virtual environments.

As with all companies, we occasionally had to decide what to work on next. We decided that our first priority was to increase a specific metric—activation. We wanted more folks who tried the product once to come back again.

So our goal for the project was to increase the activation number.

We needed to figure out how we would know if the project was a success. We decided that our project would be a success when we saw a statistically significant increase in the percentage of new users coming back within a certain amount of time.

To fully understand whether the problem was fixed by our new design, we’d release any changes we made in an A/B test that would show the old version to half the new users and the new version to the other half. We’d measure the percentage of folks coming back from both cohorts over a period of several weeks and see what happened.

Now we knew our problem, and we had a verifiable way to know that we’d either solved the problem or made progress toward solving the problem.

I’m not going to go into all the different ways that we tried to make progress on that specific metric. I’ll have more on those sorts of changes later. Suffice it to say that some things moved the needle and others didn’t. More importantly, it wasn’t always the biggest changes that had the biggest impact. The point was, whatever changes we made, we had an objective way of determining whether or not the design was a success.

There are other sorts of tests you might do rather than a strict A/B test, and I’ll cover those later in the book.

Interestingly, desired outcomes aren’t always obvious and A/B tests aren’t always possible. In our example of helping people who are having problems, looking at the number of problems people are solving isn’t really a good metric. I mean, you could easily increase the number of problems people are solving by increasing the number of problems they’re having, and that is not a metric you want any higher.

A better metric in this case might be something like the number of support calls you get from users who see the new feature or the number of questions you get about specific problems users were having.

The trick is that all success metrics must be measurable and directly related to your business goals. Again, I’ll talk more about how to pick a good test goal later in the book. Think of it as an annoying little trick to force you to keep reading.

When Is It Safe to Skip This?

You really shouldn’t skip this either, although I’ve found that this particular exercise can take as little as a few minutes. Before you start to design or build anything, you should know very clearly what it is intended to do and how to know whether it is working.

Tool 3: Write Some Stories

A lot of times when we think of stories, we think of the very specific Agile engineering stories that we write and track. These are not the sort of stories you’re going to write.

You need to write down design stories. Think of these as a way to break down your problem into manageable steps. Also, think of these as a way to evaluate the design once it’s finished.

A good story for our user help experiment might be something like, “Users who are having trouble making changes to their accounts can quickly figure out how to solve that problem.”

Don’t forget to write admin stories, too! You might include something like, “Customer service reps can more quickly add new content to help users when new problems arise.”

You’ll notice I didn’t suggest things like, “Customers can ask questions of other users and get immediate responses.” That may be a solution that you explore, but being too explicit about how you’re going to solve your problem can lock you into a specific idea too soon and prevent you from discovering better ones.

When Is It Safe to Skip This?

Writing down stories is always a good idea. With that said, you’re welcome to skip writing stories for very trivial things like quick bug fixes; small changes to messaging; or visual design changes, like testing a new button color, that are better represented by showing the actual design.

On the other hand, the very simplest stories should take no more than a few minutes to write, so consider doing it anyway, just as practice. Sometimes, in the process of writing design stories, you’ll find that you’re missing a crucial part of the design.

For example, I was talking with a startup that was changing its home page rather dramatically. The team thought it was a very simple visual design change. However, once they started writing their stories, they realized that one part of the design involved testing different images on the home page. They also realized that they wanted to allow their marketing team to continue to test different images going forward, which meant that they needed an admin interface to allow that to happen. By writing the design stories, they thought through things like how changes would be made going forward—things they would otherwise have missed.

Tool 4: Talk About Possible Solutions with the Team

Depending on the type of person you are, this is either the most fun or the most tortuous part of the design process. I’m not going to go into detail about the best way to discuss things with your team, but make sure that it’s a very small, targeted group of people who have a strong grasp of the problem you’re trying to solve.

If you’ve properly used Tool 1 in this chapter, you’re already ahead of the game. You’ve talked to these stakeholders already when you were in the process of truly understanding the problem.

The important thing here is that, just because you know the exact problem you’re trying to solve, doesn’t mean there’s a single, obvious way to fix it. For example, a pretty typical problem for products is that new users have no idea how to get started.

There are dozens of ways to fix this. You could do a tutorial, a video, a webinar, a walk-through, inline callouts, tooltips, or contextual help messages, for example. Hell, if you have very few users who are each paying a huge amount of money, you could go to each customer’s house personally and teach him how to use it.

This is the time to get all those different options on the table for further evaluation.

As I’m sure you’ve been told, this is not the time to shoot down people’s ideas. In our help example, you don’t want to ignore the person in the corner saying things like, “What if Ryan Gosling were to answer all of our support questions?” even if you feel it’s not the most cost-efficient method of helping users.

Perhaps the most important thing to consider about brainstorming is that it should be a very, very, very short process. People who love this part of the job will try to suck you into four-hour “strategy” meetings that are really thinly veiled brainstorming meetings.

Don’t do it. If you’re just brainstorming, and not starting arguments over every stupid idea (and let’s face it, some ideas are really stupid, no matter what they tell you in brainstorming school), you will run out of ideas very quickly.

Start the session by clearly stating the user problem and the reason you are choosing to solve it. Explain how you will measure the success of the experiment. Then have everybody write down their ideas in a sentence or two. Go around the room, have people read their ideas, write them on the whiteboard, and don’t let people discuss beyond clarifying certain specifics about the idea.

Depending on the types of ideas that people are presenting, you may want to start grouping ideas in a way that makes sense to you. Feel free to group by things like which metric will be affected, ease of implementation, or customer problem that you’re solving. Those can all be helpful in deciding what’s most important to do next.

Try to do this in under 15 minutes. Seriously. If it takes much longer than that, you’re including too many people or talking about too many things.

Figure 1-2. This part should not take more than 15 minutes

Feel free to ask people at the end whether they feel strongly about a particular solution they’d like to try, but whatever you do, don’t take a vote. This is an opportunity to get some new ideas, not some stupid experiment in democratic government.

When Is It Safe to Skip This?

I just said you can do this in 15 minutes. Why would you skip it? The truth is, by continually checking in with your team and the stakeholders, you’re going to save yourself time in the long run, because they will catch mistakes and problems that you might miss.

Tool 5: Make a Decision

Welcome to the hardest part of the design process. You need to pick something to try. If you can’t make hard decisions and then stick to them for at least as long as it takes to prove whether you were right or wrong, you are going to need to change careers, because this is a necessary skill.

But don’t fret. I’m not going to send you into the wilderness empty-handed. I’m going to remind you of a very important calculation called ROI—return on investment.

Every possible solution has an expected cost and an expected return. Of course, your expectations of both things are probably completely wrong, but you have to do this anyway, because you will get better and better at making expected ROI calculations as you do more of them. Don’t get me wrong. You’ll still probably suck at them, but you’ll suck less, and it’s a useful exercise.

A good way to do this is to create a simple graph with x- and y-axes. Label one “Expected Return” and one “Expected Cost.” Then put all your different features on the graph. While you won’t be able to truly estimate the exact cost of every different feature, it’s pretty easy to estimate which ones are going to take far more time or engineering effort.

Oh, in case you’re thinking to yourself that you don’t really know how to estimate engineering effort, this might be a good time to mention that you should have someone from engineering involved in this effort. Same goes for any of the other people in your company who might be affected by your changes. That can be marketing, customer service, sales, or anyone else who needs to weigh in on unexpected costs or benefits of particular features.

Again, none of those people are going to vote on the right decision to be made. What they will do is provide enough information about the real expected costs and benefits of each feature so you can make the decision.

An important thing to keep in mind during this process is that, depending on the size and complexity of your company, this process may have to be quite iterative. Engineering may not have enough information at this point to commit to a solid estimate. Marketing may be able to give only a rough estimate of what sort of support they’ll need for the new feature. Sales may have things they need added to make the feature really effective for them.

That’s OK. You don’t need to know absolutely everything about the feature at this point. You just need to get everybody thinking about the decision as early as possible so that, as problems do arise, you’ll have more people on your team to catch them and fix them.

When Is It Safe to Skip This?

Never. Never ever ever ever ever. You must make a decision. There is nothing I see more often at failing startups than a fundamental inability to make a damn decision. If you have done your research and involved your team, you are ready to make a decision, even if you don’t know it’s the right one.

Don’t worry. You’re going to validate whether this is the right idea or not. But first you have to pick a direction to go in.

Tool 6: (In)Validate the Approach

OK, this section should have been titled “(In)Validate the Approach When Possible and Financially Worthwhile,” but it looked weird.

The reason this is here is because the next few tools can take some time. While understanding the problem and getting your team on board are not really negotiable parts of the design process, everything that follows this can be avoided with one easy trick: Invalidate your idea.

“What’s that?” you say. “Why would I want to invalidate my idea?” The simple answer is because if you can prove that you’re about to make a huge mistake, it’s very possible for you to avoid making it. And, yes, even if you’ve used all the tools provided to you so far in the chapter, you could still be making a huge mistake.

Here’s an example. Imagine you’re working on an e-commerce company that sells gadgets. Now imagine you’ve spent a lot of time talking to your users, and you realize that one of the biggest reasons people don’t buy gadgets is they feel like they already have too many they don’t use. Furthermore, imagine that another common reason people don’t buy new gadgets is price.

You and your team might reasonably come to the conclusion that a good solution to both of these problems would be to allow people to resell their own gadgets in order to get new ones. This would be a perfectly reasonable hypothesis about a way to fix a known problem.

What you want to do next is figure out if the hypothesis is wrong. Too often, the solution to a problem seems so obvious to us, but it simply fails to catch on with users. Think of how much time you would waste implementing an entire system allowing users to sell their own gadgets on your site if none of them actually wanted to sell any.

I talk in the next chapter about Feature Stubs, and that’s what you might want to do here. Design the smallest possible thing that you can that might invalidate your hypothesis. In this example, that might be a Sell Your Gadget button in an obvious place in your product that counts the number of times people click it and gives a nice message saying the feature isn’t fully implemented yet. If nobody ever clicks the button, it’s a great signal that you don’t want to build the full version of the feature, at least until you understand the problem or the market better.

The reason this is so important is that every failed feature you don’t build saves you money and time so that you can build more features that are more likely to succeed.

When Is It Safe to Skip This?

There are some features or changes that simply take more time to validate than they do to build. Before you implement a fake feature or come up with some other ingenious test to see if you’re going in the right direction, ask yourself how long the feature will take to build and how long it will take to test in this manner. If it’s almost as fast to just build it and test it in production, then feel free to do that.

Tool 7: Sketch a Few Approaches

I’m a big fan of starting to sketch at this point in the design process. You’ll note we’re on Tool 7 here.

Unfortunately, this is where a lot of folks start the design process. The thing is, once you start sketching, you can have a tendency to focus on the details—where a button goes, what pieces of the interface belong together, how much text will be necessary.

That’s OK to do on Tool 7. You’re ready for it now. You probably already have a picture of what you want to design in your head.

Every designer I’ve talked to has a different preferred way of “sketching.” I’m going to give you mine, but you may end up liking a different method. That’s fine. The most important things about sketching are that it’s quick and that it’s disposable. This is your chance to try out a few different versions of your new feature or product.

Because you’re going to want to create several different versions of your idea quickly, and because you’re going to want to iterate quickly on your ideas, I suggest you use a sketching tool like Balsamiq or OmniGraffle. There are about a dozen others. Those are the two I use. They are easy to learn, and they produce things at a high enough fidelity to get your point across.

Figure 1-3. Same sketch, different fidelities

Your goal with sketching is to start to work out things like what elements belong on a screen and what pieces belong together. For example, if you’re creating a product page to sell something, you’re almost certainly going to want a picture of the thing you’re selling, a buy button, and a price. Those things should probably be pretty close together. Other than that, though, you have a lot of directions you could go.

Because sketching is so quick, it’s a great time to do things like work out the flows of basic tasks. Often people forget that what they are sketching is almost certainly not a static thing. It has actions and states. Buttons can be pressed. Forms can be filled in, sometimes incorrectly. When you’re sketching, it’s a good time to get through as many of the different states as possible to make sure that they can all be handled.

Whenever you sketch an interactive element, make sure you’re adding a screen or a note about what happens when somebody interacts with that element. If you add a drop-down list, think through what might be in that drop-down list.

Too often I see “sketches” that are so vague as to be completely useless. While these are technically sketches, they are not particularly useful in helping you to work out how a user will interact with your product. And that’s really the point of sketching.

Figure 1-4. Not particularly helpful

Once you have several versions of your sketches produced, it’s time to make a few more decisions. The most important decision is which ones to move forward with, since it’s very rarely a good idea to move forward with three or four completely different designs, unless you have a lot of bored engineers and an entire testing system already set up to A/B test all the versions against one another.

For most of us with limited resources, it’s generally best to pick one or two sketches that we think are most likely to fix the problems we observed in the initial research. The best way to do this is to get your sketches in front of actual users again.

Figure 1-5. Including text and calls-to-action makes this sketch useful

Your goal for testing your sketches with users isn’t to try to understand the usability of the design, it’s to understand, overall, whether potential users get what the product is and can find the starting point for all of their most important tasks.

Let’s look at an example. Imagine that you’ve created a few sketches of a new e-commerce product page. You know that the most important things for people to do on this page are to buy the product or to share the product with friends. Show the sketches to some strangers, preferably on a computer. Ask the following questions:

  • What do you think this screen is for?

  • How would you buy something?

  • Imagine that you think it would be perfect for a friend. How would you share it with that friend?

Don’t forget to mix up the order in which you show people the sketches, so everybody doesn’t see the same sketch first.

If, after you’ve done this four or five times, nobody is having any trouble understanding any of the sketches, then feel free to pick your favorite and move on. If, on the other hand, everybody is having trouble with all the sketches, pay close attention to where people are looking and try a few new sketches. Repeat.

When Is It Safe to Skip This?

When you’re making a change that is easier to communicate or test in another way, you don’t need to create a sketch. For example, if you’re making a simple visual design change, it might be faster or more efficient to show the change in Photoshop or even in HTML and CSS.

In other cases, you may be making major changes to your product that you know will require fully interactive prototypes, and you may want to begin your design process with one of those.

Don’t sketch for the sake of sketching. Sketch because it helps you to develop and communicate your design ideas quickly. And if it’s not going to do that, then you’re welcome to skip it.

Tool 8: Create Interactive Prototypes

I’m a huge fan of interactive prototypes, but there’s often some confusion about what those are. Let’s be clear: When I say interactive prototypes, I don’t mean something created in PowerPoint that somebody could kind of click through. I mean a full-scale, working prototype that allows users to explore and feel like they’re accomplishing tasks.

Unsurprisingly, it’s a little hard to illustrate what I mean in a book, but interactive wireframes have things like widgets that respond to users and animations that work and forms that users can fill in. They are interactive enough for users to make mistakes and recover from them. They are realistic enough that users often think they’re just an ugly, boring, nonvisually designed version of the real product.

Here’s the problem with interactive prototypes: They take a long time to build. I mean, they don’t take as long to build as a real product, because often they have a rudimentary visual design and no backend to speak of. For example, you might have an interactive prototype that lets a user feel like he was purchasing a product but didn’t actually process a payment or ship him anything.

In general, they are wonderful for figuring out what’s confusing or hard to use about your product before you write a lot of code. They also serve as a fantastic tool for communicating to engineers exactly what you want them to build.

For example, imagine that you are building that checkout flow. Maybe you want parts of the interface to be shown only after a user performs a specific task. Instead of writing a document that explains in detail everything that you want to have happen, you simply include it in the prototype. Or maybe you want a particular animation to happen when a user presses a button. You can show exactly the style, speed, and behavior of the animation in your prototype.

So, now that you know all the wonderful reasons you’d want to build an interactive prototype, you have to decide whether it’s worth spending the time to do so. There are a few criteria you should use to make this decision.

First, is it a complex interaction? Any time you have a sequence of steps where a user needs to make a number of choices, it’s probably worth it to do a prototype. Multiple steps mean multiple chances for users to get lost or to get something wrong, and the more complex or potentially confusing an interaction, the more important it is to prototype it.

Second, will it take awhile to build and, more importantly, will it take awhile to fix if you get it wrong? One of the biggest reasons people give for not making prototypes is that they simply don’t have the time, but if it’s a big, complicated interaction that can take a few days to build, it can also take days to fix if there’s something particularly confusing about it. On the other hand, if an engineer can build the entire working feature in about the same time it would take me to build an entire prototype, I’ll generally err on the side of just building and testing it in production.

Third, how often do you make changes to your product? If you’re serious about being Lean, hopefully you practice continuous deployment, so you can ship a fix immediately rather than waiting for weeks for a new version of the product, but not everybody’s work environment is like that. If you’re building something that simply can’t be changed on the fly, like a physical product or a heavily regulated piece of software, then interactive prototypes are crucial for finding as many problems as possible before you ship.

The last question to ask yourself before you build the interactive prototype is whether it will help you, as the designer or product owner, figure out important things about the design. More often than you’d think, the answer to this question will be a resounding yes.

You see, if you’re designing something interactive, you need to design it to be...well...interactive. Too often, designers design screens in something like Photoshop or Illustrator, as if screens were the end product. But screens aren’t the end product. Screens are snapshots of particular states that a user might encounter in your product.

For example, a single screen in a checkout flow could have all sorts of states. It could have multiple types of errors, or a user could back out of the checkout flow and come back to it, or she could abandon the checkout flow altogether, or she could click through to read more about the terms of service. By creating an interactive prototype, the designer is forced to think through every single interaction on the screen and the different states that could be caused by different types of input.

Which brings us to a very important question: How should you create your interactive prototypes? Well, here again I tend to differ from other designers. I make my interactive prototypes in HTML, JavaScript, and CSS. Knowing enough programming to create prototypes means that I have a lot of flexibility in what I can design. I’m not limited by the capabilities of prototyping tools.

But, by all means, if you’re an absolute whiz with some other type of tool, like Axure or Flash, that really allows you to create a fully interactive experience, use that.

When Is It Safe to Skip This?

If you’re designing something very simple, quick, and not highly interactive, by all means, skip the interactive prototype. I will always skip the prototypes on things like landing pages with a single call-to-action; messaging changes; and small, new features with very little interactivity.

Deciding whether or not to make an interactive prototype is essentially an ROI question. If an engineer can build and release a feature for testing in less time than it would take to build a prototype, often it makes no sense to bother with one. However, if you stand to lose significant time, revenue, or customers by releasing a major change without truly understanding the usability of the feature, building and testing an interactive prototype can be a lifesaver.

Tool 9: Test and Iterate

OK, now we’re on the last tool. Pretty exciting! You’re almost done! Oh, except for the part where you have to test and go back and do everything all over again.

If you truly think that the very first thing you design will be completely perfect and not require any changes, you are either delusional or you are a better designer than anybody I’ve ever met. No, I take that back. You’re totally delusional.

One of the major differences between Lean and other methodologies is the extreme importance of iteration. You see, if you really do crank out an absolutely perfect design the first time around, you are spending way too much time up front.

Build things, prototype things, and get things in front of users as quickly as possible to find out what they like and what they hate and what they find horribly confusing. Then fix the problems and add things you think they’ll like and keep doing that until you’ve got a feature that people are excited about.

I know that nine tools seems like a lot to use over and over, but you’ll find that they go very quickly once you realize that you don’t have to get everything absolutely perfect the first time.

When Is It Safe to Skip This?

I can’t believe you even asked this question. I’m ashamed of you.

Promise me that you will never skip testing or iteration. I mean it.

Loosely Related Rant: Give the Users What They Really Want

In the past, I’ve tried to teach startups how to do their own user research and design. I’ve noticed that I teach a lot of the same things over and over again, since there are a few things about research that seem to be especially difficult for new folks.

One of the most common problems, and possibly the toughest one to overcome, is the tendency to accept solutions from users without understanding the underlying problem.

In other words, a user says, “I want X feature,” and instead of learning why she wants that feature, entrepreneurs and product owners tend to write down, “Users want X feature” and then move on.

This is a huge issue with novices performing research. When you do this, you are letting your users design your product for you, and this is bad because, in general, users are terrible at design.

Ooh! An Example!

I participated in some user research for a company with an expensive set of products and services. Users coming to the company’s website were looking for information so they could properly evaluate which set of products and services was right for them. Typically, users ended up buying a custom package of products and services.

One thing we heard from several users was that they really wanted more case studies. Case studies, they said, were extremely helpful.

Now, if you’re conducting user research, and a customer tells you that he wants case studies, this might sound like a great idea.

Unfortunately, the user has just presented you with a solution, not a problem. The reason that this is important is that, based on what the actual underlying problem is, there might be several better solutions available to you.

When we followed up on users’ requests for case studies with the question, “Why do you want to see case studies?” we got three different answers. Interestingly, the users asking for case studies were trying to solve entirely different problems. But were case studies really the best solution for all three problems?

These were the responses along with some analysis.

“I want to know what other companies similar to mine are doing so that I have a good idea of what I should buy.”

The first user’s “problem” was that he didn’t know how to pick the optimal collection of products for his company. This is a choice problem. It’s like when you’re trying to buy a new home theater system, and you have to make a bunch of interrelated decisions about very expensive items that you probably don’t know much about.

While case studies can certainly be helpful in these instances, it’s often more effective to solve choice problems with some sort of recommendation engine or a selection of preset packages.

Both of these quickly help the user understand what the right selection is for him rather than just give him a long explanation of how somebody else found a good solution that might or might not be applicable to the user.

“I want to know what sorts of benefits other companies got from the purchase so I can tell whether it’s worth buying.”

The second user’s “problem” was that he wanted to make sure he was getting a good value for his money. This is a metrics problem. It’s like when you’re trying to figure out if it’s worth it to buy the more expensive stereo system. You need to understand exactly what you’re getting for your money with each system and then balance the benefits versus the cost.

This problem might have been solved by a price matrix showing exactly what benefits were offered for different products. Alternatively, it would be faster and more effective to display only the pertinent part of the case studies on the product description page—for example, “Customers saw an average of 35% increase in revenue six months after installing this product.”

By boiling this down to only the parts of the case study that are important to the user, it gives you more flexibility to show this information—statistics, metrics, etc.—in more prominent and pertinent places on the site. This actually increases the impact of these numbers and improves the chance that people will see them.

“I want to see what other sorts of companies you work with so that I can decide whether you have a reputable company.”

The third user’s “problem” was that he hadn’t ever heard of the company selling the products. Since they were expensive products, he wanted the reassurance that companies he had heard of were already clients. This is a social proof problem. It’s like when you’re trying to pick somebody to put a new roof on your house, so you ask your friends for recommendations.

His actual problem could have been solved a lot quicker with a carousel of short client testimonials. Why go to all the trouble of writing up several big case studies when all the user cares about is seeing a Google logo in your client list?

Why this matters

This shouldn’t come as a surprise to any of you, but users ask for things they’re familiar with, not necessarily what would be best for them. If a user has seen something like case studies before, then when he thinks about the value he got from case studies, he’s going to ask for more of the same. He’s not necessarily going to just ask for the part of the case study that was most pertinent to him.

The problem with this is that many people who might also find certain parts of case studies compelling won’t bother to read them because case studies can be quite long or because the user doesn’t think that the particular case study applies to him.

Obviously, this is applicable to a lot more than case studies. For example, I recently saw a very similar situation from buyers and sellers in a social marketplace asking for a “reputation system” when what they really wanted was some sort of reassurance that they wouldn’t get ripped off. I could name a dozen other examples.

The takeaway is that, when somebody asks you for a feature, you need to follow up with questions about why she wants the feature, even when you think you already know the answer!

Once you know what the problems really are, you can go about solving them in the most efficient, effective way, rather than the way the user just happened to think of during the conversation.

Instead of just building what the user asks for, build something that solves the user’s real problem. As an added bonus, you might end up building a smaller, easier feature than the one the user asked for.

Go Do This Now!
  • Write some stories: Try breaking down a current feature into a complete set of user stories.

  • Do some sketching: Try taking the user stories and creating three rough sketches of how one of the screens might look. If that goes well, THEN sketch all the screens for the feature.

  • Learn what your users really want: Try looking at a feature that’s commonly requested by users and figuring out what problem they’re trying to solve.

Continue reading 9 critical tools for designing a product.

Categories: Technology

Four short links: 26 July 2018

O'Reilly Radar - Thu, 2018/07/26 - 03:25

Events Defense, Reading List, Go Cloud, and Operating Systems Book

  1. When The Nazis Show Up -- an organizer's perspective on what happens at a conference when the white supremacists show up. A lesson for all of us event organizers. As he says, [U]sing your rules and norms against you is an alt-right go-to. [...] And, honestly, most conferences don't model for these kinds of threats. They model for "drunk dude groping the presenter" and "racist greybeard drops n-bombs."
  2. YC's Summer Reading List -- my favorite session to host at unconferences is "What Are You Reading?", and here's one from the YC folks. Refreshingly short on the "meditate yourself rich with keto mindfulness training!" business/self-help schlock.
  3. Go Cloud -- the promise is to write vendor-neutral cloud apps in Go. We have identified common services used by cloud applications and have created generic APIs to work across cloud providers. Today, Go Cloud is launching with blob storage, MySQL database access, runtime configuration, and an HTTP server configured with request logging, tracing, and health checking. Go Cloud offers support for Google Cloud Platform (GCP) and Amazon Web Services (AWS). We plan to work with cloud industry partners and the Go community to add support for additional cloud providers very soon.
  4. Operating Systems: Three Easy Pieces -- a free online operating systems book! The book is centered around three conceptual pieces that are fundamental to operating systems: virtualization, concurrency, and persistence. In understanding the conceptual, you will also learn the practical, including how an operating system does things like schedule the CPU, manage memory, and store files persistently. Lots of fun stuff!

Continue reading Four short links: 26 July 2018.

Categories: Technology

Four short links: 25 July 2018

O'Reilly Radar - Wed, 2018/07/25 - 03:00

Quantum Computing, A/B Tests, Rockstar Programming Language, and Git Solutions

  1. Strawberry Fields -- a full-stack Python library for designing, simulating, and optimizing continuous variable (CV) quantum optical circuits. (via Hacker News)
  2. p-Hacking and False Discovery in A/B Tests -- Experimenters indeed p-hack, especially for positive effects. Specifically, about 57% of experimenters p-hack when the experiment reaches 90% confidence. Furthermore, approximately 70% of the effects are truly null, and p-hacking increases the false discovery rate (FDR) from 33% to 42% among experiments p-hacked at 90% confidence. Assuming that false discoveries cause experimenters to stop exploring for more effective treatments, we estimate the expected cost of a false discovery to be a loss of 1.95% in lift, which corresponds to the 76th percentile of observed lifts. But it feels good to optimize your product with data, and that's what counts.
  3. Rockstar -- a dynamically typed Turing-complete programming language. Rockstar is designed for creating computer programs that are also song lyrics, and is heavily influenced by the lyrical conventions of 1980s hard rock and power ballads.
  4. 10 Common Git Problems and How to Fix Them -- for every git newcomer.

Continue reading Four short links: 25 July 2018.

Categories: Technology

The five Cs

O'Reilly Radar - Tue, 2018/07/24 - 04:00

Five framing guidelines to help you think about building data products.

What does it take to build a good data product or service? Not just a product or service that’s useful, or one that’s commercially viable, but one that uses data ethically and responsibly.

We often talk about a product’s technology or its user experience, but we rarely talk about how to build a data product in a responsible way that puts the user in the center of the conversation. Those products are badly needed. News that people “don’t trust” the data products they use—or that use them—is common. While Facebook has received the most coverage, lack of trust isn’t limited to a single platform. Lack of trust extends to nearly every consumer internet company, to large traditional retailers, and to data collectors and brokers in industry and government.

Users lose trust because they feel abused by malicious ads; they feel abused by fake and misleading content, and they feel abused by “act first, and apologize profusely later” cultures at many of the major online companies. And users ought to feel abused by many abuses they don’t even know about. Why was their insurance claim denied? Why weren’t they approved for that loan? Were those decisions made by a system that was trained on biased data? The slogan goes, “Move fast and break things.” But what if what gets broken is society?

Data collection is a big business. Data is valuable: “the new oil,” as the Economist proclaimed. We’ve known that for some time. But the public provides the data under the assumption that we, the public, benefit from it. We also assume that data is collected and stored responsibly, and those who supply the data won't be harmed. Essentially it’s a model of trust. But how do you restore trust once it’s been broken? It’s no use pretending that you’re trustworthy when your actions have proven that you aren’t. The only way to get trust back is to be trustworthy, and regaining that trust once you’ve lost it takes time.

There’s no simple way to regain users’ trust, but we’d like to suggest a “golden rule” for data as a starting point: “treat others’ data as you would have others treat your own data.” However, implementing a “golden rule” in the actual research and development process is challenging—just as it’s hard to get from short, pithy oaths and pledges to actual practice.

What does it mean to treat others’ data as you would treat your own? How many data scientists have actually thought about how their own data might be used and abused? And once you know how you’d like to see your data (and others’ data) respected, how do you implement those ideas? The golden rule isn’t enough by itself. We need guidelines to force discussions with the application development teams, application users, and those who might be harmed by the collection and use of data.

Five framing guidelines help us think about building data products. We call them the five Cs: consent, clarity, consistency, control (and transparency), and consequences (and harm). They’re a framework for implementing the golden rule for data. Let’s look at them one at a time.

Consent

You can’t establish trust between the people who are providing data and the people who are using it without agreement about what data is being collected and how that data will be used. Agreement starts with obtaining consent to collect and use data. Unfortunately, the agreements between a service’s users (people whose data is collected) and the service itself (which uses the data in many ways) are binary (meaning that you either accept or decline) and lack clarity. In business, when contracts are being negotiated between two parties, there are multiple iterations (redlines) before the contract is settled. But when a user is agreeing to a contract with a data service, you either accept the terms or you don’t get access. It’s non-negotiable.

For example, when you check in to a hospital you are required to sign a form that gives them the right to use your data. Generally, there’s no way to say that your data can be used for some purposes but not others. When you sign up for a loyalty card at your local pharmacy, you’re agreeing that they can use your data in unspecified ways. Those ways certainly include targeted advertising (often phrased as “special offers”), but may also include selling your data (with or without anonymization) to other parties. And what happens to your data when one company buys another and uses data in ways that you didn’t expect?

Data is frequently collected, used, and sold without consent. This includes organizations like Acxiom, Equifax, Experian, and Transunion, who collect data to assess financial risk, but many common brands also connect data without consent. In Europe, Google collected data from cameras mounted on cars to develop new mapping products. AT&T and Comcast both used cable set top boxes to collect data about their users, and Samsung collected voice recordings from TVs that respond to voice commands. There are many, many more examples of non-consensual data collection. At every step of building a data product, it is essential to ask whether appropriate and necessary consent has been provided.

Clarity

Clarity is closely related to consent. You can’t really consent to anything unless you’re told clearly what you’re consenting to. Users must have clarity about what data they are providing, what is going to be done with the data, and any downstream consequences of how their data is used. All too often, explanations of what data is collected or being sold are buried in lengthy legal documents that are rarely read carefully, if at all. Observant readers of Eventbrite’s user agreement recently discovered that listing an event gave the company the right to send a video team, and exclusive copyright to the recordings. And the only way to opt out was by writing to the company. The backlash was swift once people realized the potential impact, and Eventbrite removed the language.

Facebook users who played Cambridge Analytica’s “This Is Your Digital Life” game may have understood that they were giving up their data; after all, they were answering questions, and those answers certainly went somewhere. But did they understand how that data might be used? Or that they were giving access to their friends’ data behind the scenes? That’s buried deep in Facebook’s privacy settings.

Even when it seems obvious that their data is in a public forum, users frequently don’t understand how that data could be used. Most Twitter users know that their public tweets are, in fact, public; but many don’t understand that their tweets can be collected and used for research, or even that they are for sale. This isn’t to say that such usage is unethical; but as Casey Fiesler points out, the need isn’t just to get consent, but to inform users what they’re consenting to. That’s clarity.

It really doesn’t matter which service you use; you rarely get a simple explanation of what the service is doing with your data, and what consequences their actions might have. Unfortunately, the process of consent is often used to obfuscate the details and implications of what users may be agreeing to. And once data has escaped, there is no recourse. You can’t take it back. Even if an organization is willing to delete the data, it’s very difficult to prove that it has been deleted.

There are some notable exceptions: people like John Wilbanks are working to develop models that help users to understand the implications of their choices. Wilbanks’ work helps people understand what happens when they provide sensitive medical and health data to a service.

Consistency and trust

Trust requires consistency over time. You can’t trust someone who is unpredictable. They may have the best intentions, but they may not honor those intentions when you need them to. Or they may interpret their intentions in a strange and unpredictable way. And once broken, rebuilding trust may take a long time. Restoring trust requires a prolonged period of consistent behavior.

Consistency, and therefore trust, can be broken either explicitly or implicitly. An organization that exposes user data can do so intentionally or unintentionally. In the past years, we’ve seen many security incidents in which customer data was stolen: Yahoo!, Target, Anthem, local hospitals, government data, and data brokers like Experian, the list grows longer each day. Failing to safeguard customer data breaks trust—and safeguarding data means nothing if not consistency over time.

We’ve also seen frustration, anger, and surprise when users don’t realize what they’ve agreed to. When Cambridge Analytica used Facebook’s data to target vulnerable customers with highly specific advertisements, Facebook initially claimed that this was not a data breach. And while Facebook was technically correct, in that data was not stolen by an intruder, the public’s perception was clearly different. This was a breach of trust, if not a breach of Facebook’s perimeter. Facebook didn’t consistently enforce its agreement with its customers. When the news broke, Facebook became unpredictable because most of its users had no idea what it would or wouldn’t do. They didn’t understand their user agreements, they didn’t understand their complex privacy settings, and they didn’t understand how Facebook would interpret those settings.

Control and transparency

Once you have given your data to a service, you must be able to understand what is happening to your data. Can you control how the service uses your data? For example, Facebook asks for (but doesn’t require) your political views, religious views, and gender preference. What happens if you change your mind about the data you’ve provided? If you decide you’re rather keep your political affiliation quiet, do you know whether Facebook actually deletes that information? Do you know whether Facebook continues to use that information in ad placement?

All too often, users have no effective control over how their data is used. They are given all-or-nothing choices, or a convoluted set of options that make controlling access overwhelming and confusing. It’s often impossible to reduce the amount of data collected, or to have data deleted later.

A major part of the shift in data privacy rights is moving to give users greater control of their data. For example, Europe’s General Data Protection Regulation (GDPR) requires a user’s data to be provided to them at their request and removed from the system if they so desire.

Consequences

Data products are designed to add value for a particular user or system. As these products increase in sophistication, and have broader societal implications, it is essential to ask whether the data that is being collected could cause harm to an individual or a group. We continue to hear about unforeseen consequences and the “unknown unknowns” about using data and combining data sets. Risks can never be eliminated completely. However, many unforeseen consequences and unknown unknowns could be foreseen and known, if only people had tried. All too often, unknown unknowns are unknown because we don’t want to know.

Due to potential issues around the use of data, laws and policies have been put in place to protect specific groups: for example, the Children’s Online Privacy Protection Act (COPPA) protects children and their data. Likewise, there are laws to protect specific sensitive data sets: for example, the Genetic Information Nondiscrimination Act (GINA) was established in 2008 in response to rising fears that genetic testing could be used against a person or their families. Unfortunately, policy doesn’t keep up with technology advances; neither of these laws have been updated. Given how rapidly technology is being adopted by society, the Obama Administration realized that the pace of the regulatory process couldn’t keep up. As a result, it created the roles of the U.S. chief technology officer and chief data scientist. The Obama administration also established more than 40 chief data officers and scientists across the federal government. The result has been to make sure the regulatory process fosters innovation while ensuring the question of potential of harm is asked regularly and often.

Even philanthropic approaches can have unintended and harmful consequences. When, in 2006, AOL released anonymized search data to researchers, it proved possible to “de-anonymize” the data and identify specific users. In 2018, Strava opened up their data to allow users to discover new places to run or bike. Strava didn’t realize that members of the U.S. military were using GPS-enabled wearables, and their activity exposed the locations of bases and patrol routes in Iraq and Afghanistan. Exposure became apparent after the product was released to the public, and people exploring the data started talking about their concerns.

While Strava and AOL triggered a chain of unforeseen consequences by releasing their data, it’s important to understand that their data had the potential to be dangerous even if it wasn’t released publicly. Collecting data that may seem innocuous and combining it with other data sets has real-world implications. Combining data sets frequently gives results that are much more powerful and dangerous than anything you might get from either data set on its own. For example, data about running routes could be combined with data from smart locks, telling thieves when a house or apartment was unoccupied, and for how long. The data could be stolen by an attacker, and the company wouldn’t even recognize the damage.

It’s easy to argue that Strava shouldn’t have produced this product, or that AOL shouldn’t have released their search data, but that ignores the data’s potential for good. In both cases, well-intentioned data scientists were looking to help others. The problem is that they didn’t think through the consequences and the potential risks.

It is possible to provide data for research without unintended side-effects. For example, the U.S. Internal Revenue Service (IRS), in collaboration with researchers, opened a similar data set in a tightly controlled manner to help understand economic inequality. There were no negative repercussions or major policy implications. Similarly the Department of Transportation releases data about traffic fatalities. The U.K. Biobank (one of the largest collections of genomic data) has a sophisticated approach to opening up different levels of data. Other companies have successfully opened up data for the public benefit, including LinkedIn’s Economic Graph project and Google Books' ngram viewer.

Many data sets that could provide tremendous benefits remain locked up on servers. Medical data that is fragmented across multiple institutions limits the pace of research. And the data held on traffic from ride-sharing and gps/mapping companies could transform approaches for traffic safety and congestion. But opening up that data to researchers requires careful planning.

Implementing the 5 Cs

Data can improve our lives in many ways, from the mundane to the amazing. Good movie recommendations aren’t a bad thing; if we could consolidate medical data from patients around the world, we could make some significant progress on treating diseases like cancer. But we won’t get either better movie recommendations or better cancer treatments if we can’t ensure that the five Cs are implemented effectively. We won’t get either if we can’t treat others' data as carefully as we’d treat our own.

Over the past decade, the software industry has put significant effort into improving user experience (UX). Much of this investment has been in user-centric approaches to building products and services that depend on the data the collective user base provides. All this work has produced results: using software is, on the whole, easier and more enjoyable. Unfortunately, these teams have either intentionally or unintentionally limited their efforts to providing users with immediate gratification or the ability to accomplish near-term goals. “Growth hacking” focuses on getting people to sign up for services through viral mechanisms. We’ve seen few product teams that try to develop a user experience that balances immediate experience with long-term values.

In short, product teams haven’t considered the impacts of the five Cs. For example, how should an application inform users about how their data will be used, and get their consent? That part of user experience can’t be swept under the rug. And it can’t mean making it easy for users to give consent, and difficult to say “no.” It’s all part of the total user experience. Users need to understand what they are consenting to and what effects that consent might have; if they don’t, the designer’s job isn’t done.

Responsibility for the 5 Cs can’t be limited to the designers. It’s the responsibility of the entire team. The data scientists need to approach the problem asking “what if” scenarios that get to all of the five C’s. The same is true for the product managers, business leaders, sales, marketing, and also executives.

The five C’s need to be part of every organization’s culture. Product and design reviews should go over the five Cs regularly. They should consider developing a checklist before releasing a project to the public. All too often, we think of data products as minimal viable products (MVPs: prototypes to test whether the product has value to users). While that’s a constructive approach for developing and testing new ideas, even MVPs must address the five Cs. The same is true for well-established products. New techniques may have been developed that could result in harm in unforeseen ways. In short, it’s about taking responsibility for the products that are built. The five C’s are a mechanism to foster dialogue to ensure the products “do no harm.”

Continue reading The five Cs.

Categories: Technology

Four short links: 24 July 2018

O'Reilly Radar - Tue, 2018/07/24 - 03:20

Data Transfer, Quantum Computing, Optimal Control Theory, and Observability

  1. Data Transfer Project -- Facebook, Google, Microsoft, and Twitter collaborating on a data interchange project. Data Transfer Project (DTP) is a collaboration of organizations committed to building a common framework with open source code that can connect any two online service providers, enabling a seamless, direct, user-initiated portability of data between the two platforms.
  2. Getting Started with Quantum Computing in Python -- In this tutorial, we’ll go through how you can program a simple quantum computer to generate random numbers. (via Hacker News)
  3. Introduction to Mathematical Optimal Control Theory -- lecture notes. In the words of one HN commenter, machine learning and OCT are attempting to solve the same problem: choose the optimal action to take at the current time for a given process. Control theorists normally start out with a model, or a family of potential models that describe the behavior of the process and work from there to determine the optimal action. This is very much an area of applied mathematics, and academics take rigorous approaches, but, in industry, many engineers just use a PID or LQR controller and call it a day, regardless how applicable they are to the actual system theoretically. Meanwhile, the reinforcement learning folk typically work on problems where the models are too complicated to work with computationally or often even to write down, so a more tractable approach is to learn a model and control policy from data.
  4. Veneur -- Stripe's distributed, fault-tolerant pipeline for observability data.

Continue reading Four short links: 24 July 2018.

Categories: Technology

How to take machine learning from exploration to implementation

O'Reilly Radar - Mon, 2018/07/23 - 04:05

Recognizing the interest in ML, the Strata Data Conference program is designed to help companies adopt ML across large sections of their existing operations.

Interest in machine learning (ML) has been growing steadily, and many companies and organizations are aware of the potential impact these tools and technologies can have on their underlying operations and processes. The reality is that we are still in the early phases of adoption, and a majority of companies have yet to deploy ML across their operations. The results of a recent survey we conducted (with 11,000+ respondents, a full report is forthcoming) bears this out—only about 15% of respondents worked for companies that have extensive experience using ML in production:

In this post, I’ll describe how one can go from “exploration and evaluation” to actual “implementation” of ML technologies. Along the way, I’ll highlight key sections of the upcoming Strata Data conference in New York this September. Recognizing the interest in ML, we assembled a program to help companies adopt ML across large sections of their existing operations.

Understanding key technologies and methods

Machine learning has enormous potential, but in order to unleash its promise, one needs to identify appropriate problems and use cases. The key to using any new set of tools and technologies is to understand what they can and cannot do. How do you put your organization in a position to take advantage of ML technologies? Because ML has the potential to affect every aspect of an organization, we are highlighting several companies that have invested resources in training and organizing their workforce on these new technologies.

Data preparation, governance, and privacy

Much of ML in use within companies falls under supervised learning, which means proper training data (or labeled examples) are essential. The rise of deep learning has made this even more pronounced, as many modern neural network architectures rely on very large amounts of training data. Issues pertaining to data security, privacy, and governance persist and are not necessarily unique to ML applications. But the hunger for large amounts of training data, the advent of new regulations like GDPR, and the importance of managing risk means a stronger emphasis on reproducibility and data lineage are very much needed.

As companies gain more experience, they start augmenting existing data sets with data that holds the potential to improve their existing ML models. There is growing interest in exploring alternative data sets and types. How exactly can companies augment their existing data sets with external data sources? Can decentralization technologies (like blockchains) pave the way for new forms of data exchanges?

Data integration and data platforms

Data used for ML models tends to come from a variety of sources. Because ML relies on large amounts of (labeled) data, learning how to design, build, and maintain robust data pipelines is important for productionizing machine learning. Depending on the application, companies typically have to grapple with variety (disparate data sources), volume (particularly for deep learning systems that are data hungry), and velocity (ingesting data from sensors and edge devices).

Over the last few years, many companies have begun rolling out data platforms for business intelligence and business analytics. More recently, companies have started to expand toward platforms that can support growing teams of data scientists. Common features of modern data science platforms include: support for notebooks and open source machine learning libraries, project management (collaboration and reproducibility), feature stores (for storing and sharing useful variables), and model visualization.

Model building: Some standard use cases

Machine learning has become commonly used for recommendation and personalization applications. The rise of new algorithms always tends to bring renewed interest. Deep learning has caused many companies to evaluate their existing recommenders, and many have begun to use neural networks to either supplement or replace their existing models. Deep learning has also reinvigorated interest in applications involving two data types found within many companies: text (natural language processing and understanding) and temporal data (correlations, anomalies, forecasting).

Model lifecycle management

Companies are realizing that machine learning model development is not quite the same as software development. Completion of the ML model building process doesn’t automatically translate to a working system. The data community is still in the process of building tools to help manage the entire lifecycle, which also includes model deployment, monitoring, and operations. While tools and best practices are just beginning to emerge and be shared, model lifecycle management is one of the most active areas in the data space.

Ethics and privacy

Newly introduced regulations in Europe (GDPR) and California (Consumer Privacy Act) have placed concepts like “user control” and “privacy-by-design” at the forefront for companies wanting to deploy ML. The good news is that there are new privacy-preserving tools and techniques—including differential privacy—that are becoming available for both business intelligence and ML applications.

Ethics and compliance are areas of interest to many in the data community. Beyond privacy, data professionals are much more engaged in topics such as fairness, transparency, and explainability in machine learning. Are data sets that are being used for model training representative of the broader population? For certain application domains and settings, transparency and interpretability are essential and regulators may require more transparent models, even at the expense of power and accuracy. More generally, how do companies mitigate risk when using ML?

Case studies

Putting all these topics together into working ML products—data movement and storage, model building, ML lifecycle management, ethics and privacy—requires experience. One of the best ways to learn is to hear presentations from peers who have successfully (and repeatedly) used machine learning to reinvigorate key facets of their operations. We showcase many case studies at the upcoming Strata Data conference in NYC; here are a selection of talks from a few application domains:

Continue reading How to take machine learning from exploration to implementation.

Categories: Technology

Be smart with responsive web design

O'Reilly Radar - Mon, 2018/07/23 - 04:00

By being intentional and deliberate in your approach, you can build an excellent user experience that performs well regardless of screen size.

Responsive Web Design

Mobile is no longer “the future.” As mentioned in Chapter 1, handsets are the primary Internet access method (http://slidesha.re/eW8wQ9) for a vast number of global Internet users. People are primarily using handsets to access the Internet, and these devices present their own unique set of challenges. Between the tremendous amount of latency on mobile networks (see “Mobile Networks”) and hardware challenges like WiFi signal strength and battery power (see “Mobile Hardware”), it’s more important than ever that we design and develop sites that are as high performing and efficient as possible. We need to aim for no unnecessary overhead for our users and optimize for perceived performance on all screen sizes.

The challenge with responsive web design sites is that it can be very easy to accidentally deliver unnecessary content like too-large images or unused CSS and JavaScript. Because the process of creating a responsively designed site can often include adding markup and functionality to optimize your layout and content for smaller screens, it’s no surprise that many sites deliver the same page weight or additional page weight to mobile devices without the designers and developers even realizing it.

Many creators of responsive sites are already going above and beyond in their decision-making process: reflowing content, choosing to hide or show various elements, making smart decisions about hierarachy, and more. We need to build an additional step into this responsive web design workflow: ensuring that we are delivering only the necessary content in terms of page weight and requests, not just information architecture.

Guy Podjarny found that the majority of responsively designed sites are currently delivering roughly the same page weight to small and large screens. But it doesn’t have to be this way: responsive web design is not inherently bad for performance, and we can be smart about what we deliver to our users. By being intentional in your approach to designing a responsive site and deliberate with what kinds of assets you require your users to download, you can build an excellent user experience that performs well regardless of screen size.

Deliberately Loading Content

Because we so often create a responsive site by adding things like more media queries for various screen sizes, it’s easy to forget that we may also be adding a ton of extra overhead for our users. This is especially true when a design starts with a desktop version and is then edited to scale down for smaller screens: what happens to those assets that have been optimized for the desktop view? Too often these are left as is; images are always served at the same size (just scaled down visually, through CSS), or fonts continue to be delivered and implemented as they are on desktop. We need to be deliberate with how we load content and ensure we are delivering only the bytes that our user absolutely needs.

Images

Images should be served at the size at which they are displayed on the page to eliminate any unnecessary overhead for your users. In Figure 1-1, we can see a screenshot of Google’s home page with Chrome DevTools open. The size at which the Google logo is displayed is smaller than the actual height and width of the logo file.

This means that users are downloading unnecessary bytes, since their browsers downloaded an image that’s unnecessarily large for how it’s displayed. As you inspect an image in Chrome DevTools, you’ll be able to see the height and width of the image as it is displayed on the page as well as the image’s “natural” size, which can often be different than the display size (Figure 1-2).

In Figure 1-2, we can see that Google may be sending a retina-sized version of the image to users. Since retina displays cram twice as many pixels into their screens, a designer or developer can send an image twice as large as necessary and scale it down for display in the browser. This technique makes images look crisp on retina displays. Unfortunately, it also means users who aren’t using retina displays will download unnecessary image file bytes.

Figure 1-1. In this example, we can see that the size at which the Google logo is displayed is smaller than the actual size of the logo file.Figure 1-2. Chrome DevTools will tell you how large an image is naturally as well as its actual displayed dimensions on the page.

Inspect the images on your site and see if there are opportunities for serving appropriately sized files. You have a few different ways to tell the browser which image to serve: RESS solutions, CSS media queries, and the new picture specification.

RESS, which stands for responsive web design with server-side components, is one option for creating and serving correctly sized images. You can improve performance by choosing which assets to serve to your user on the server side, rather than optimizing them on the client side. Your server can make smart decisions by looking at a user agent string, from which it can guess things like your user’s screen size, device capabilities like touch, and more. Tools like Adaptive Images (http://adaptive-images.com/) detect your user’s screen size and will automatically create, cache, and deliver correctly sized images based on your defined breakpoints (see Figure 1-3). In his book High Performance Responsive Design (O’Reilly), Tom Barker outlines a number of RESS techniques and how to implement them.

Figure 1-3. In this example from the Adaptive Images site (http://adaptive-images.com/), you can see different pixel widths and heights were generated from a single image with the Adaptive Images tool, as well as the different file sizes of the resulting images.

However, there are a number of downsides to RESS solutions. RESS won’t respond to client-size changes (e.g., if a user rotates the device from portrait to landscape). Let’s say you’re using RESS to send a perfectly resized image to your user’s browser. If that user rotates her device and your responsive layout changes, your server won’t know to send a new image to fit the new layout. This is why techniques like media queries and the new picture specification tend to be better solutions for responsive images.

There has been a lot of research done to determine which methods are best for displaying a correctly sized image using CSS in a responsive design, thanks in particular to Tim Kadlec (http://bit.ly/1jqN9gF) and Cloud Four (http://bit.ly/1tu0f7X). However, browsers can do unexpected things as they determine which image(s) to download for your page with CSS, which is why it’s important to test your site’s performance and ensure that you are asking your users’ browsers to download only the necessary resources.

For example, simply setting display: none to an element will not prevent a browser from downloading the image:

<div id="hide"> <img src="image.jpg" alt="Image" /> </div> /* Seriously, don't do this. Browsers will still download the image. */ @media (max-width: 600px) { #hide { display: none; } }

The same goes for applying display: none to an element with a background-image; the image will still be downloaded:

<div id="hide"></div> /* Again, don't do this. Browsers will still download the image. */ #hide { background: url(image.jpg); } @media (max-width: 600px) { #hide { display: none; } }

Instead, if you want to hide an image from displaying with CSS in a responsive design, you can try hiding the parent element of the element with a background-image:

<div id="parent"> <div></div> </div> /* Hide the parent element; Browsers will not download the image. */ #parent div { background: url(image.jpg); } @media (max-width: 600px) { #parent { display: none; } }

Alternatively, you could apply different media queries to tell the browser which background-image is appropriate to download at which screen size. A browser will download an image when it matches a media query:

<div id="match"></div> @media (min-width: 601px) { #match { background: url(big.jpg); } } @media (max-width: 600px) { #match { background: url(small.jpg); } }

Note that if media queries overlap, older browsers will download both images.

But what about serving up retina images with CSS? We can ensure that only the retina version is downloaded for most browsers by using a media query to serve the retina version:

<div id="match"></div> #match { background: url(regular.png); } @media (-webkit-min-device-pixel-ratio: 1.5), (min--moz-device-pixel-ratio: 1.5), (-o-min-device-pixel-ratio: 3/2), (min-device-pixel-ratio: 1.5) { #match { background: url(retina.png); } }

Devices running Android 2.x that have a device pixel ratio equal to or above 1.5 will unfortunately download both versions of the image (regular.png as well as retina.png), but as Kadlec notes in his article (http://bit.ly/1jqN9gF), it’s unlikely that you will encounter a retina device running Android 2.x.

Your best bet for displaying a correctly sized picture in modern browsers is to take advantage of the picture element in HTML. picture is currently supported in Chrome 38, Firefox 33, and Opera 25, and is a part of the new picture specification (http://bit.ly/1tu0v6R). This new specification allows you to tell the browser which image file to download and when, and it includes a fallback for browsers that don’t support the picture element.

Here’s a simple example of the picture element that uses a media query to determine which image file to download. The first source to match, top to bottom, is the resource that gets picked for the browser to download:

<picture> <source media="(min-width: 800px)" srcset="big.png"> <source media="(min-width: 400px)" srcset="small.png"> <img src="small.png" alt="Description"> </picture>

Check out how amazing this is. Not only are we able to match media attributes to tell the browser which image file to download, but we also have a low-resolution image that will be downloaded by browsers that don’t support the picture element. Picturefill (http://scottjehl.github.io/picturefill/) is a polyfill that enables support for the picture element in browsers that don’t currently support it, so you can start using picture today! A good rule of thumb here is that all the images defined in the same picture element should be able to be described with the same alt attribute.

You can use the picture element to serve retina images when applicable, too!

<picture> <source media="(min-width: 800px)" srcset="big.png 1x, big-hd.png 2x"> <source media="(min-width: 600px)" srcset="medium.png 1x, medium-hd.png 2x"> <img src="small.png" srcset="small-hd.png 2x" alt="Description"> </picture>

In this example, srcset tells the browser which image to choose at different pixel densities. Again, we’re saving overhead for our users by being precise and telling the browser exactly which single image file is the right one to retrieve and display.

One additional superpower of the picture element is the type attribute:

<picture> <source type="image/svg+xml" srcset="pic.svg"> <img src="pic.png" alt="Description"> </picture>

We can tell our user’s browser to ignore an image source unless it recognizes the contents of the type attribute. In this example, browsers that recognize SVG will download the SVG file, and the rest will download the fallback PNG. Again, we’re able to tell the browser exactly which single image file is the right one to download and display, saving our user from unnecessary page weight overhead.

But what about fluid designs? Or what if you just have a handful of different image sizes, and want your user’s browser to choose the most appropriate resource without listing specific viewport sizes or screen resolutions? The picture specification can help with these, too, using the sizes attribute. sizes follows this syntax:

sizes="[media query] [length], [media query] [length], etc... [default length]"

Each media query in the sizes attribute will relate to a length that the image will be displayed on the page, relative to the viewport size. So if you have a length of 33.3vw, the browser understands that the image will be displayed at 33% of the viewport width. If you have a length of 100vw, the browser understands that the image will be displayed at 100% of the viewport width. This math helps the browser choose which image will be most appropriate to retrieve and show to your user.

sizes is smart because it will look through each media query to see which applies before figuring out the correct image to download. In this example, we can tell the browser that at larger screens, the image will be shown at 33% of the viewport, but the default width of the image is 100% of the viewport:

sizes="(min-width: 1000px) 33.3vw, 100vw"

The browser looks in the srcset list of images to see their dimensions. We can tell the browser the width of each image in our list with the syntax image.jpg 360w, where image.jpg is the path to the image file and 360w indicates that this image is 360 px wide:

<img srcset="small.jpg 400w, medium.jpg 800w, big.jpg 1600w" sizes="(min-width: 1000px) 33.3vw, 100vw" src="small.jpg" alt="Description">

With this list of images in srcset and list of display widths in sizes, browsers can pick the best image to fetch and display to your user based on media query and viewport size. This comes in handy when you use a content management system, too; allow your CMS to generate the sources and markup for your image. This way, a CMS user has to upload only one version and not worry about how it will be displayed at different screen sizes. Note that, as demonstrated in this example, you can use the new picture specification without using the picture element!

You can use all of the pieces of this new specification in concert to give your user’s browser a ton of power in choosing which image should be downloaded and displayed. You’ll be able to choose to serve differently cropped images at different screen sizes, as well as retina-optimized images for high-pixel-density devices, and you can give the browser the power to choose the right image for the job based on media query. All of this is excellent for performance.

Fonts

Font files can add a huge amount of overhead to your site because they require additional requests and increase page weight. As discussed in “Optimizing Web Fonts,” there are several ways of optimizing your font files to ensure they are as high performing as possible. One additional consideration you can make in your responsive design is to load your custom font file only on larger screens. This is something we do at Etsy, as we would rather save our users from downloading the extra font file overhead if they’re on a mobile device.

To do this, set your normal fallback fonts on your content. Then use a media query to only apply your web font to content at a large breakpoint:

@font-face { font-family: 'FontName'; src: url('fontname.woff') format('woff'); } body { font-family: Georgia, serif; } @media (min-width: 1000px) { body { font-family: 'FontName', Georgia, serif; } }

This will download and apply the font file only if the user’s device matches the media query. All browsers (except Internet Explorer 8 and lower) are smart about downloading a font file only if it applies. Internet Explorer 8 and lower will download all @font-face files referenced in a page’s CSS file, even if they aren’t used on the page.

Approaches

While you’ll make many decisions about how to create your site’s responsive web design during the actual design and development process, it’s important to take a beat before you begin any work to consider your overall approach and how it will impact performance. Building performance into project documentation, taking the time to look at your site from a mobile-first perspective, and figuring out how you’re going to measure the performance of your site across media queries will help you to create a speedy, responsively designed site.

Project Documentation

If possible, incorporate performance into your project documentation for any project (not just responsive web designs!). For a responsive site, you’ll want to benchmark and continue to measure the same standard performance metrics like total page weight, total page load time, and perceived performance using the Speed Index. But you’ll also want to be able to set goals for devices and media queries, not just an average overall page using your design.

As we’ll discuss in “Approach New Designs with a Performance Budget,” there are ways to make compromises on site speed as you develop. By setting a performance budget, you’ll be able to make concessions as you balance aesthetics and performance. For any responsive web design, you’ll be making these same concessions; maybe you’ll want to serve a large image at a particular media query that puts you over your budget, so you’ll decide to not deliver extra font weights to make up the time. Table 1-1 outlines an example performance budget for a responsive web design.

Table 1-1. Example responsive web design budget Measure Goal Notes

Total page load time

2 seconds

For all breakpoints

Total page weight

500 KB

min-width: 900 px

Total page weight

300 KB

max-width: 640 px

Speed Index

1,000

For all breakpoints

Set some expectations within your project documentation about how you expect to avoid unnecessary page weight or requests to any device. In addition, make it clear that you will be measuring these things for each media query or screen size and what your goals are, as in Table 1-1. These kinds of budgets can get a bit fuzzy. For example, what happens if you rotate a device and it switches between budgets? It’s essential to have a baseline indicating the importance of performance to set expectations for those who are working on the project. Remember that this will benefit not just your mobile users, but your desktop users as well.

Mobile First

A mobile-first approach to designing any site will help you in so many areas. It will prompt you to:

  • Ask critical questions up front (“What is the core purpose of this page?”).

  • Identify the most important functionality and content for your users.

  • Establish design patterns and how they will change across screen sizes.

  • Think about your site from an accessibility perspective (“How accessible will this be for people on slower connections or less capable devices?”).

By starting with a mobile-first approach, you can attempt to avoid the square peg/round hole mentality that many designers and developers fall into when they try to reshape a desktop experience for mobile devices. You can progressively enhance your site by adding functionality, incorporating more powerful animations and styles, and taking advantage of newer devices’ capabilities, all while keeping track of performance implications as you add on.

The mobile experience shouldn’t be bare-bones. It should be a deliberate experience; designers and developers should use the benefits of, and be cognizant of the limitations for, each platform their site will be rendered on. Mobile isn’t just an add-on to desktop, and desktop isn’t just an add-on to mobile. Content parity doesn’t mean that each platform’s experience should be identical. We should be designing and developing with our users’ needs in mind.

A mobile-first approach forces you to ask these important questions about core user needs early and will help you with the performance of your site. An experience with intention about your users will help you focus on what kinds of assets are being delivered to them. An approach in which you make hard decisions about functionality and content hierarchy at small screen sizes will help you keep your total page weight and number of requests down. A site that starts with the most important content and assets, rather than tacking on media queries to handle smaller screen sizes, will be a huge help in keeping your performance under control.

For your responsive site, consider your smallest screen sizes first. Reorder your CSS to deliver small screen styles first, and use progressive enhancement to add content and capabilities as screen sizes get larger. Deliver correctly sized assets, ensure there’s no scrolling jank, and make the page’s core functionality interactive as quickly as possible. From there, you can make decisions about how to share larger assets on larger screens, reflow content in your hierarchy, and continue to be deliberate about performance in your overall user experience.

Measure Everything

In Chapter 6, we’ll cover how to continue to measure your performance as you iterate and test your designs. You’ll use all of these tactics on a responsively designed site, just as you would any other site. But there are some additional considerations for measuring a responsive web design.

Primarily, you need to ensure that only the appropriate content is being loaded at each breakpoint. Don’t join the other 72% of websites that are serving up the same size responsive design site across screen sizes.

If you’re able to, implement automated tests that measure the total page weight for each of your chosen breakpoints. Tom Barker included an excellent chapter on continuous web performance testing in his book High Performance Responsive Design, which outlines how to implement Phantom JS tests that measure each breakpoint’s performance, including YSlow score and total page weight.

You can also test this manually. Emulate a device using Chrome DevTools and use the Resources panel to see which image size is being downloaded for that device. Here is an example set of media queries in which I choose to serve a different image based on breakpoint:

@media (min-width: 601px) { section { background: url(big.png); } } @media (max-width: 600px) { section { background: url(small.png); } }

I want to make sure not only that the correct image is downloaded for a particular device size, but that both images aren’t downloaded. I used Chrome DevTools with caching disabled to emulate a Google Nexus 10 that would match the larger media query (Figure 1-4), and a Google Nexus 4 that would match the smaller media query (Figure 1-5).

Figure 1-4. In this example, I emulated a Google Nexus 10 to see which image would be downloaded. In the Network panel, we can see that big.png was called.

Each emulated device correctly downloaded only the image that was needed. We can also see the total page size transferred: 7.3 KB for the larger device, and 2.9 KB for the smaller device. Continue to check on the resources and total page weight being delivered to each breakpoint determined in your project plans to ensure that you’re meeting your goals.

For measuring total page load time and Speed Index at each breakpoint, check out WebPagetest’s drop-downs for browser (Figure 1-6) and connection speed (Figure 1-7).

The Dulles, Virginia, WebPagetest location includes a number of mobile browsers in the Browser drop-down. This testing location includes physical devices, like the iPhone 4 and the Nexus 5, on which you can test.

Figure 1-5. After switching the emulator to the Google Nexus 4 and refreshing the page, we can see that small.png was called instead of big.png.Figure 1-6. You can choose from an assortment of mobile browsers in your WebPagetest run.Figure 1-7. You can choose from an assortment of emulated connection speeds in your WebPagetest run.

The different connections listed in the Connections drop-down are created using traffic shaping. This means Chrome DevTools will emulate what a user may experience on this type of connection, but the results will be more consistent across tests because the test is actually happening on WiFi.

Compare the results for each breakpoint to make sure that your total page load time and Speed Index meets or beats the goal outlined in your project documentation.

All of the other techniques in this book will also help you optimize your responsive web design for performance. As you design your responsive site, be deliberate about which assets are downloaded by your users. Develop a performance budget at each breakpoint and use a mobile-first approach when designing and developing the site. Be sure to also check out Tom Barker’s book, High Performance Responsive Design, for more in-depth details on optimizing both the backend and frontend of your responsively designed website for performance.

As always, measuring performance as you work and as your site ages will help you keep page load time under control. In the next chapter, we’ll dive into tools and routines for checking in on the performance of your site to help you get a holistic view of your user experience over time.

Continue reading Be smart with responsive web design.

Categories: Technology

Four short links: 23 July 2018

O'Reilly Radar - Mon, 2018/07/23 - 03:45

State Sponsored Trolling, Public Standards, Explorable Explanations, and iOS Network Debugging

  1. State Sponsored Trolling (Institute For The Future) -- authoritarians around the world have mastered social media. Bloomberg did some great follow-up work on the IFTF report. (via Cory Doctorow)
  2. Public Resource Wins Right to Publish Standards Used in Law -- The question in this case is whether private organizations whose standards have been incorporated by reference can invoke copyright and trademark law to prevent the unauthorized copying and distribution of their works. [...] Because the district court erred in its application of both fair use doctrines, we reverse and remand, leaving for another day the far thornier question of whether standards retain their copyright after they are incorporated by reference into law.
  3. Explorable Explanations -- explanations and simulators for things to help you learn them. Regular readers will know I'm a huge fan of simulations as learning tools.
  4. Wormholy -- debug network iOS apps from within the app: Add it to your project, and that's all! Shake your device or your simulator and Wormholy will appear. In case, for whatever reason, the Charles proxy doesn't do it for you.

Continue reading Four short links: 23 July 2018.

Categories: Technology

Four short links: 20 July 2018

O'Reilly Radar - Fri, 2018/07/20 - 04:55

Convolutional Architectures, GPU Language, Acoustic Scenes, and Cybersecurity Numbers

  1. DARTS: Differentiable Architecture Search -- our algorithm excels in discovering high-performance convolutional architectures for image classification and recurrent architectures for language modeling, while being orders of magnitude faster than state-of-the-art non-differentiable techniques. And runs on a single GPU. Open source.
  2. The Spiral Language -- a functional language designed for GPUs by emphasizing inlining (GPUs don't have great stacks, so compilers have to handle subroutines carefully and differently than traditional architectures). Inlining is a trade-off that expresses the exchange of memory for computation. It should be the default instead of heap allocating.
  3. DCASE: Detection and Classification of Acoustic Scenes and Events -- workshops and a community for the researchers working on making sense of audio.
  4. Cybersecurity: Data, Statistics, and Glossaries (FAS) -- This report describes data and statistics from government, industry, and information technology (IT) security firms regarding the current state of cybersecurity threats in the United States and internationally. These include incident estimates and costs, and annual reports on data security breaches, identity thefts, cybercrimes, malware, and network securities.

Continue reading Four short links: 20 July 2018.

Categories: Technology

20 years later, open source is as important as ever

O'Reilly Radar - Thu, 2018/07/19 - 13:00

Sarah Novotny outlines two reasons why open source continues to be important: choice and infrastructure.

Continue reading 20 years later, open source is as important as ever .

Categories: Technology

O’Reilly Radar: Open source tool trends—What our users tell us

O'Reilly Radar - Thu, 2018/07/19 - 13:00

Roger Magoulas shares insights about the open source tools ecosystem based on analysis of usage and search data from O'Reilly's learning platform.

Continue reading O’Reilly Radar: Open source tool trends—What our users tell us.

Categories: Technology

The importance of community

O'Reilly Radar - Thu, 2018/07/19 - 13:00

Patricia Posey draws on her non-traditional journey into tech to illustrate how honest investments can build a sustainable community that is integral to the advancement of its members.

Continue reading The importance of community.

Categories: Technology

Open source opens doors for vets

O'Reilly Radar - Thu, 2018/07/19 - 13:00

Jerome Hardaway explains how Vets Who Code uses open source to create job opportunities for veterans.

Continue reading Open source opens doors for vets.

Categories: Technology

Open sourcing quantum: Get ready to help build a new future

O'Reilly Radar - Thu, 2018/07/19 - 13:00

Jay Gambetta explores Qiskit, an open-source framework that aims to make quantum computing accessible for everyone.

Continue reading Open sourcing quantum: Get ready to help build a new future.

Categories: Technology

Building with open source at the world’s largest home improvement retailer

O'Reilly Radar - Thu, 2018/07/19 - 13:00

Angie Brown explains how Home Depot uses open source in its stores, online search, order management, analytics, and more.

Continue reading Building with open source at the world’s largest home improvement retailer.

Categories: Technology

O'Reilly Open Source Awards 2018

O'Reilly Radar - Thu, 2018/07/19 - 13:00

The O’Reilly Open Source Awards recognize individual contributors who have demonstrated exceptional leadership, creativity, and collaboration in the development of open source software.

Continue reading O'Reilly Open Source Awards 2018.

Categories: Technology

Pages

Subscribe to LuftHans aggregator