“WARNING! This is app is in beta!”
Hey how come all these apps for my phone say that.
Lol what’s wrong with that and what is it?
That’s the mobile phone text message that greeted me on New Year’s Eve and for a moment stopped me in my tracks. Then, I burst out laughing for a good 20 seconds.
The text was from my college age daughter, who is really smart and consumer-tech savvy, and knows pretty much everything there is to know about using consumer devices. Yet, I realized, she doesn’t really know the jargon of tech, and a word like beta is a mystery to her. And why should she know our strange vernacular? Why on earth would we in the tech industries expect her to understand an esoteric term like “beta,” which in turn requires at least a superficial description of the software development process to properly explain it?
(You twist down a path needing to explain that there’s an “alpha” that precedes beta, and before long you’re waxing poetic about the agile development movement, Scrum stand-up meetings, and pigs and chickens and how chickens can’t talk but pigs can. Not the kind of banter you really need when you’re trying to get something like Angry Birds installed on your new phone.)
So it got me to thinking: When is jargon needed and when isn’t it? It seems to me that words like “beta” don’t belong at all in the consumer world, even though some consumers are beginning to understand what the term means, at least with regard to their phones (mainly, I find that people think of a “beta” for phone apps as meaning “discounted price, but buggy”).
But sometimes jargon does fill a void and serve a purpose.
While having a spirited conversation with some younger indie/alternative music fans this past week, I was suddenly struck that they use a super-geeky standards term – MP3 — all the time without a second thought. Not only that, but it’s a nickname term with an arcane history, which emerged from the need to have sound accompany video (you might remember when Internet “movies” were created using sequenced silent JPEGs). The ISO standards organization’s Motion Picture Experts Group (MPEG) created multiple schemes (also called “layers” ) for audio encoding, and one of them, MPEG-1 (later 2) Audio Layer III, took hold for music. Since it needed a file extension definition, it naturally got .mp3, and thus the file extension name became the nickname for the format and was eventually baked into a million conversations about music that happen even day among ordinary mortals. I know our Cisco audience will totally enjoy reading an early RFC document so here is one: RFC3003
On the other hand, there is the FireWire story. There was a need to name the thing, but the official term, which is IEEE-1394, was way too geeky for consumers to swallow. That’s why IEEE-1394 got remarketed as “FireWire” by Apple and “i.LINK” by Sony. (Oh, for those who want the spec for bedtime reading: IEEE-1394-2008 IEEE Standard for a High-Performance Serial Bus.)
All of the above underscores how much worlds of Internet and other engineering standards and technologies have become the hidden underpinnings that make everything tick in our homes, from the video that is delivered on our TVs via cable or satellite, to conferencing technologies that bring us together like ūmi telepresence for the home, to how our music is delivered, to how our cooktops work, to how our electricity is metered. With all of these technologies and standards flying around, I think all of us need to be careful not to outright terrify people with techie names. So that is one of my jargon-related resolutions this year: Use jargon appropriate the to audience, and keep it simple enough that it doesn’t confuse or alarm.
Caveat: In the business and technology area, terms like IPv6, 802.11n, MPLS, SNMP, Multicast, WAAS, etc are quite necessary as a way to communicate about standards and technologies that are supported. As long as it’s the right audience, a rich alphabet soup of names on a page is wonderful.
That brings me, though, to the other jargon-related resolution I have for 2011, which is around jargon-laden navigation. Sometimes, I see us (and our colleagues in all regions of technology) taking shortcuts where we’ll invent new names to “make things simpler” and somehow hope that, though Jedi mind tricks, customers will magically understand what these names or labels represent, and be able to navigate through a forest of them.
I’m not going to give you any examples of this second sort of jargon terms, because instead I would like you to nominate your favorites. What names for things do you see deep in the Cisco.com web sites that you believe make your navigation confusing or otherwise disorient you? Comment on this blog, and I’ll then add some of my own favorites that we’re working on addressing.
Cheers, and Happy New Year.
P.S. Yeah, I just know one of the original MPEG group members is going to read this and call out multiple historical simplifications that I made. I will be honored to make any corrections needed.
P.P.S. By the way, Jennifer McAdams has interesting blog from last year about how Internet standards are born and how Cisco helps.
Tags: jargon, standards, webexperience
On the web team, we’re always experimenting with new functions to make your life easier. The latest is an interactive product comparison module, that allows you to filters views of models by different criteria, and build a dynamic side-by-side comparison showing the different attributes of the models you’ve selected.
We’re piloting the first one on a Cisco Small Business 100 Series Unmanaged Switches comparison, and we’d like your feedback on this functionality.
Here’s how it works: Let’s say you want to compare the features of the models in the 100 series. When you go to the comparison page, you’ll see the complete list, partially shown here:
You can check and compare straightaway, or filter the list (via the control box on the left) to make it more focused. In this case, I have filtered on Gigabit Ethernet just as an example, which sizes down the list:
Then check off the boxes you want to compare, press the Compare button, and you’ll be presented with a side-by-side listing showing the various features and attributes of the various models:
We’re thinking of using this elsewhere around the site, so give it a try and let us know what you think.
Tags: small business, specs, switches, webexperience
On Cisco.com we usually won’t do anything with quite the entertaining production values of JibJab’s latest year in review (a romp through US political headlines of 2010). But it turns out that our rich media design process at Cisco has a lot in common with JibJab. I know this because the JibJab team took time to put together a fascinating behind-the-scenes commentary showing how they created their latest video.
What struck me especially is that the basic process they follow at JibJab is similar to what we do on Cisco.com when we’re creating more business oriented online demos, conceptual overviews or training. It’s standard great design practice: Creating a brief, then writing a script, then storyboarding , then laying the audio tracks, potentially creating animatics to show how the resulting video or Flash piece will be, and then animating or doing full production.
Whether it’s the demo of the Cisco FlipPRO camcorders, or the adventures of IT Willis, we go through pretty much the same journey with scripting, storyboarding, etc as the folks at JibJab.
Of course, we explain these steps every week to our internal teams at Cisco, as do countless design organizations in every company and organization around the globe. But the folks at JibJab have captured the design process in a really interesting format that lots of people are likely to read.
Here are a couple of samples from their design process overview: An example of a storyboard, and a puppeteering session:
One difference. At Cisco.com and most other web sites, the teams don’t get to play with puppets, which looks like a lot of fun. I’m jealous.
Tags: design, webexperience
Chances are you have used Wikipedia for something in the last few months. And if so, chances are you have seen one of their fundraising pleas, such as these:
What’s really interesting is that Wikipedia is publishing the results of the ads, in something we in the biz call an “A/B” or multivariate test. The idea is this: Create a series of different ads – with different pictures, headlines, buttons and links – then alternate them across the site, and see which combinations work best. You can measure “version A” versus “version B” (that’s called an A/B test), or you can do a more sophisticated mix and match of the elements, called a multivariate test. The great thing is you get data from 10,000 or 100,000 or 1,000,000+ interactions with your web site creative content, and from that can see what visitors are actually interested in, based on their behavior.
Commercial web sites do this all day every day, but the difference is that Wikipedia is posting their results in real time publicly, to the world. There’s a ton of raw data about click behavior in multiple languages.
In their link to their A/B tests data updates you see a lot of interesting and counter-intuitive behaviors. For instance, I thought “Admit it- without Wikipedia, you never could have finished that report.” is a fantastic headline, but it got less than a 1% click-through rate, whereas the “personal appeal from Jimmy Wales” with his picture got almost 3% clickthrough on a recent week.
The Wikipedia team are also posting regular summaries of their findings, in case you don’t want to slog through their detailed testing page or download their spreadsheets of raw data. Some findings from last week emphasize that the total experience (from clicks through donation) are important to measure, and not just the initial click-through rate:
- “The original two-step payment form we’ve been using is the most effective, it performed better than the new one-step process.”
- “Adding an editor’s image to the landing page did not significantly affect donations.”
- “The click-through rates on the editor banners continue to be on par with the winning Jimmy banner, but bring in fewer donations.”
- “Many donors appear to relate better to letters which focus on readers showing support instead of individuals editing.”
- “There has been a positive response to the new editor banners, the variety keeps our campaign interesting.”
From the commercial web world, there are a couple of other sites that post results of A/B and multivariate tests: WhichTestWon.com and MarketingExperiments.com both show recent design tests and let you guess which ones were most effective.
By the way, you don’t have to use A/B tests just for advertising. In fact, many companies use them as part of their design regimen to test for which designs actually are most effective for users to complete a task. The A/B test tells you which design works better, but of course not why it works better; you still need usability testing for that.
P.S. Shoutout to the folks at digitaloptimizer and others for pointing out the Wikipedia tests to me – very interesting.
Tags: design, usability, webexperience
This past weekend, I enjoyed a couple of very straightforward and simple online shopping experiences. But, unfortunately, I also endured some really bumpy ones. Which led me to wonder: Doesn’t everyone in the digital world know about doing walkthroughs before a launch?
Walkthroughs are a very simple way of previewing experiences so you know what they’ll be like when you go live. They’re like a dry-run of the experience that you can do early in the development process. Here is how it works:
- Figure out the common paths through an experience. (For instance, one that I saw this week on a consumer site was to sign up for a promotional program: It started with an ad, led to a landing page, which went to a Facebook page and on to a sign-up form [which turns out is too many steps, but that was the flow, so that is what you would walk through].)
- Mock up a placeholder page for each step. If you have a small team that’s in one place, you can just draw with pencil or pen; if your team is more distributed, pop some fake screens into PowerPoint or another online tool so you can share via WebEx. If parts of the web site or mobile screens are already built, use those.
- Then, in a small meeting, have someone pretend to be the site visitor, and step through the experience. Make sure someone takes notes about missing steps, messages you want to get across on specific screens, what the main calls to action should be, etc.
The picture below shows what it’s like if you walk through the steps posted on a wall. We sometimes do it this way at Cisco, although more often we set up WebEx Meeting sessions so and walk through web pages or PowerPoint mockups. But the idea of walking through sequential steps is the same.
A walkthrough is a great focusing exercise because it gets everyone to focus as a team on what the end customer will see, and a lot of petty or political issues melt away once everyone is focused on the end experience. On a big project, you should walk through many key scenarios and repeat until you get it right.
I can’t remember a walkthrough I’ve done where something wasn’t caught. And catching problems before launch is much better than having thousands or millions of people experiencing them live.
Tags: design, web design, webexperience