"prototype" entries

Rethinking and redesigning at beta.oreilly.com

O’Reilly’s new beta site puts the focus on learning and ideas.

Screenshot from beta.oreilly.com

Some while back, we realized that O’Reilly is really in the education business — very specifically, the self-education and self-improvement business. People read our books, come to our events, and watch our videos because they need new skills and have the discipline and initiative to seek them out on their own. In a lot of ways, the history of the company has been searching out new ways to achieve the same goal, which 15 years ago I articulated as “changing the world by spreading the knowledge of innovators.”

That goal requires us to notice the ideas and technologies that are new and important; to find the people who have figured out how to make the most of those technologies; and of the people who’ve figured it out, to discover who has the willingness and the ability to invest in helping others to follow in their footsteps. Over time, pursuit of our goal has also required us to learn how to write, edit, publish, and distribute books; to run events that bring people together to learn from each other; and (more recently), to develop video training courses and other online learning products.

We aren’t the only ones who’ve noticed that O’Reilly is a learning company. I was delighted to see oreilly.com chosen as the #1 online course provider, ahead of MOOCs, video training companies, and others who explicitly position themselves as training providers. I like to think that the breadth of ways that we give people to learn — print, video, in-person, and interactive online — is unique because it doesn’t restrict itself to people who have one single learning style.

All of this is by way of explaining the redesign that we’re rolling out at beta.oreilly.com. Over the years, we’d let oreilly.com become mostly a front end for ecommerce, selling access to books and videos and conference seats, with a dose of reporting and advocacy on the side. Read more…

Building the right thing vs. building the thing right

Usability does not determine usefulness.

Register for the UX Design for Growth — Improving User Conversion training session with Laura Klein. In this online, interactive training workshop, Klein, author of “UX for Lean Startups,” will teach you to design for product growth.

Cantilever_bridge_human_modelI love it when companies test prototypes. Love love love it. But it makes me incredibly sad when they use prototype testing for the wrong thing.

First, let me give you my definition of “prototype testing.” I often build interactive, or semi-interactive, prototypes when designing a product. These prototypes are not actual products. They’re simulations of products. People who see the prototype can often click around them and perform some simple tasks, but they’re generally not hooked up to a real backend system.

“Well, what good is that?” you might reasonably ask. Excellent question. Interactive prototypes are incredibly useful for finding problems in usability testing settings. In a checkout flow, you might create a simple interactive prototype and watch four or five people go through the process (with test accounts) in order to find out if there were any parts of the flow they found confusing or hard to use.

It’s a great technique for any reasonably complicated interaction that you want to test before you spend a lot of time writing code. Interactive prototype testing can save you a ton of time because it helps you make sure that you’re building the product right before you spend a lot of time and money actually writing code.

However, the thing I see all the time is people using prototypes to try to validate that they’re building the right product. Stop it. Stop it right now.

Let me explain. The common pattern is that people go out and do some research on a problem (yay!) and then their next step is to build a prototype of their solution in order to show it to people and get feedback.

This is a wonderful thing to do. You should absolutely show your prototype to people in order to get feedback. You just shouldn’t expect feedback about whether or not anybody will actually buy or use your product. In other words, you can’t use a prototype to learn if you are building the right product.

Why not? Well, it has to do with the nature of doing qualitative research on a prototype.

Imagine that you ask somebody to look at your product. Maybe you stopped them on the street. Maybe they answered an ad on Craigslist. Maybe it’s a friend or a friend of a friend. You ask them a few questions about their life or job. Then you show them something that looks kind of like a product. They can click around and input some data. They can perform a few tasks. Then you ask them if they would use this product when it becomes available in a couple of months or weeks.

They will overwhelmingly say, “yes.” If they don’t say yes, they will say, “probably,” or, “no, but my cousin would use it.” You will get a huge number of false positives for all of the following reasons:

  • People want to be polite and helpful.
  • People dramatically overestimate their willingness to adopt new things.
  • People are bad at predicting the future.
  • People are bad at extrapolating real product behavior from an interactive prototype.

None of these problems come into play when you’re using a prototype to test for usability because usability testing is about evaluating facts. It answers questions like:

  • Will a reasonable person be able to perform a specific task?
  • Will a normal person get confused by the messaging?
  • Am I building this product right?

Testing for usefulness, on the other hand, is about trying answer questions like:

  • Will a lot of people buy my product at some uncertain point in the future?
  • Is this product the best solution to a problem?
  • Am I building the right product?

And these are simply not things you can answer with prototype testing.

But don’t worry. All hope is not lost. You can still test whether you’ve got the right solutions to problems before you build an entire product. You just need to validate in other ways. Important ways. Ways I’m not going to go into right now, but I covered a few of the key points in my talk at the Lean Startup Conference in 2013 though, and you can see a video of that here.

Public domain image on article and category pages via Wikimedia Commons.

5 Surprises for PHP Developers Coming to JavaScript

Unique features concealed within familiar syntax

PHP programmers often see the familiar C-like syntax of JavaScript and think it’s all flowers and roses. And while trivialities like loops and conditions are pretty much equivalent in both languages, things get very weird very quickly. Let’s take a look at the top 5 marvels JavaScript has to offer to the unsuspecting PHP veteran.

1. Functions are objects

Consider a function:

  function sum(a, b) {
    return a + b;
  }

It looks familiar, the only apparent difference being the missing $ to denote variables. But it turns out there’s more than that. The function sum() is actually an object. That means it can have properties and methods.

Something like:

 sum.length; // 2

… may come as a surprise. In this case length property of the sum object gives you the number of arguments this function expects.

And you’re not limited by built-in properties; you can assign any properties you like to the sum object. For example you can have a cache property that stores the results of previous (potentially expensive) calculations.

And since you can refer to functions just as regular variables, that means your function can take other functions as arguments (callbacks) and can also return functions as return values.
Read more…

Smuggling Web Practices into the Enterprise

How fast can the enterprise change?

At last year’s Fluent Conference, I kept having the same conversation with attendees from large companies. They had come to the show with a mandate from their bosses to figure out how to bring that fast-moving web work into their slow-moving enterprise systems.

I enjoyed some of that same conversation this year, but also a different note: even with management support, making that transition was difficult. Some parts meshed, others were difficult: changes in one place could reverberate through many others. The whole concept of “rapid prototyping” fit badly with a variety of technologies and approaches meant to minimize unpleasant surprises. Even eight years after the advent of Ajax, a variety of server-centric techniques limit the flexibility of front-end developers.

Someone at lunch said that “the technology helps, but the culture matters.” A few others talked about how everyone wanted better front-end work, but thought it could be grafted easily on existing back-end practice. The shiny parts are easy to talk about, but the plumbing is harder.

I was happy to see Bill Scott (@billwscott) of PayPal take on these challenges in his keynote. Bill wasn’t smuggling anything—that would be difficult under the title “Clash of the Titans: Releasing the Kraken.” He was brought to PayPal to change the company, to bring the lean “build – measure – learn” approach. In a risk-averse world, with “a 20-day class on how to use their version of Spring,” Scott had to change the “culture of a long shelf life” (something publishing folks are starting to do as well).

It’s a hard-hitting talk, calling for major change, skunkworks projects, and shifts in both company culture and technology.

Read more…

The Fluent Online Conference Preview

JavaScript power on display

As JavaScript and the Web connect more and more technologies, conversations grow broader and broader. While the Fluent conference is large enough to cover a broad range, we created a sampler of topics for the two-hour online conference I hosted with Peter Cooper last Thursday. They’re all very different talks, showing many paths you can explore.

Martha Girdler opened the show with a pure JavaScript talk, “this” in JavaScript: How It Really Works (at 6:38). She isolated the headaches I’d given myself the last time I used “this” with her discussion of sorting out the scope chain (at 14:34).

Next up was Wes Bos, demonstrating Hardware Access and Device APIs with JavaScript and HTML5 (at 23:30). As new APIs let JavaScript connect more deeply with the capabilities of the mobile devices we carry, he’s finding opportunities that go well beyond what we thought of as “the Web” even a couple of years ago. He demonstrated how access to the camera and microphone can let you treat the device as a motion detector, an unusual task for a web browser (at 44:07).

Pam Selle visited the server side, demonstrating Prototyping a la Node with Express (at 1:02:41). She showed how to quickly build a simple application for user testing, explaining how the testing worked as well as the code (at 1:14:17, though I really liked the discussion of anger in testing at 1:17:20).

Given the intense activity in JavaScript frameworks, we had to explore at least one. Brad Green and Shyam Seshadri, who just finished our AngularJS book, explored the Principles of AngularJS (at 1:23:35). The shift toward a model in which a framework “allows you to teach the browser how to understand these new components that you create” (at 1:27:08) reminded me that JavaScript isn’t just working with the browser lately. In many ways, it’s becoming a tool for adding capabilities to the browser instead. As they put it later (at 1:42:03), AngularJS is in many ways a meta-framework.

The video doesn’t quite capture the interactivity of the event, though you’ll get to see the questions speakers took from the audience over chat. For a much more intense encounter with JavaScript and the Web, please consider coming to the live version of Fluent, May 28th to 30th in San Francisco. We’ll have coverage of all of these topics and many many more.

[adrotate banner=”3″]