Do You Find Your iPhone Sexy?

See Google.

Sexy has recently become a word used to describe new gadgets and cool web applications.  Let’s examine the word Sexy.

Sexy implies sexual arousal on the part of the observer and suggestiveness on the part of the thing being observed. The thing being observed is suggesting sex. It is creating associations in the observers mind related to sexual pleasure, excitement and the promise of gratification. 

Although I’ve been somewhat grossed out hearing people associate sex and the suggestion of sex with an iPhone or the latest gadget, the more I think about it, the less surprised I am.

Look at the iPhone. It’s curvy and sleek. It responds instantly to your fingertips. I’ll bet it generates a small amount of warmth when you hold it to your face.

But what are we really saying when we call an iPhone sexy?

Do we mean we might stand in line all night just to have one in our lives?

Do we mean we want to take it with us wherever we go?

Do we mean that it physically excites us to hold one and makes us think of sex?

Apple has been humanizing and personalizing technology ever since that little smiling Mac icon first appeared on startup. And Apple is just the best at it.  We know that people become attached to, and identify themselves with the products they own, but the portability and interactivity of cell phones, mp3 players and lap tops brings this into a different realm. They are always with you and always respond to you. And before you get bored of this one, you are already being promised the next one.

Essentially, that promise is a sexual one. It is the promise of delayed gratification that can only be satiated by the object of your desire.

So, maybe sexy is the right word for an iPhone.

I want mine in Pink.

In-context Procedural Instructions

People always have a lot to say when you tell them you write instructions, especially software instructions. And I always sympathize.

Last weekend, I elicited a group groan from some of my friends when I brought up the annoying fact that, in most software, if you try to follow along with the procedures, they disappear as soon as you click back on the application.

Tom Johnson’s post today on using graphics and screenshots highlights the user perspective on procedural documentation. Pitcures are more important than words.

Perhaps the problem isn’t that people need more pictures, it’s that they need procedural help to be more integrated into the task they are performing. 

Why would you open another window to show a picture of a screen that you already have open? It’s all so post-modern!

The latest version of Fullshot has a nice solution to this. Little callouts popup that point to the next button to click and guide you through the process of taking a screen capture.

When procedures appear one step at a time, there is only one step to read.

I think in the technical writing field there is a lot of questions about the utility of the work we do. In my opinion, a lot of that has to do with not what we write, but the way people get access it. 

When Words Lose Their Meaning

Structurally deficient. Functionally obsolete.

Which one of these words mean that a bridge will collapse?

In 2001, this is how the I35W bridge in Minneapolis was described by a technical writer.

Holly Harkness wrote a short post that points the finger at unresponsive politicians, but I think, as technical writers, we have to think about the effects of the language we use.

We are taught not to use jargon. But, as we regularly speak to people with extensive knowledge in a field and learn more about the subjects we document, we adopt the language of our industry.

We begin to speak, think and write like the people we were hired to translate into plain english.

In the least, this results in poor documentation. In the worst, people don’t understand the significance of a situation because the words we use diffuse the meaning of what we are trying to say.

I am not blaming the techncial writer for this tragedy. In cases like this there are major factors like millions of dollars in public money, law suits, politics and bureaucracy that add up to a collapsing bridge being described as “structurally deficient” and “functionally obsolete”.

I do think, as technical writers we have a responsibility to stand up for language and words and do our best to make sure that a collapsing bridge is described as what it is: a collapsing bridge.

Delighting People

Lately, listening to podcasts and reading articles about user experience, I have heard the word delight come up frequently as a goal of design.

Can we delight people with technical writing?

I think so. Most of us know all the rules of writing well (whether we use them or not). But, if technical writing was only a matter of good content, then most users would be happy and satisfied.

My guess is that a large percentage of the time people are dissatisfied with their help because they can’t find what they are looking for and they don’t know how to ask for it.

What makes really cool websites “delightful” to use?

Responsiveness. Interaction. That’s why people like sites that use Ajax so much. Sites like Google Maps make you feel like the page is responding to you, like you are communicating with the page and it is listening to what you want.

When people click help and get the search box, a massive list of faq’s, or worse yet, the dreaded industrial-sized table of contents, they are no longer communicating. It is like they are dropped in the middle of a giant library with no librarians and usually very little guidance.

This is not delightful.

How can we start a dialogue with people before they completely frustrated and lost, hopelessly clicking on faq’s and typing “I hate you” in the search box?

The Aptana ide had a very nice way of doing this. Although, it seems to be gone in the latest version. The first time you open the software, the start page in the middle of the screen gives you information about different parts of the UI and what they do.

I think to delight people, you want them to feel like you care about them and have anticipated what they need to make them happy.

The Aptana interface answered my questions before I knew I had them. This is very similar to video games that show you how to play with little pop-up windows that explain things without interrupting the flow of the game.

You are not alone. We are here to help. We know, this stuff is confusing. Let us help you. How can we help you?

This is delightful.

Use bug tracking software to track errors in help content

My manager had an interesting idea today on how to make sure we keep our help accurate and current: use bug tracking software.

We are trying to figure out the best way for other groups (especially Client Services who use the help frequently) to let us know when they spot errors in the help content. If we are lucky, we get an email. But I work for a very large company and trying to find the right person to email when you have a problem can be difficult.

Why not treat content errors in the help like software bugs? Most software companies already have a streamlined system for tracking software bugs reported internally and externally.

I think that is a cool idea and hopefully we can try it out.

Wii Bowling at Yahoo Brickhouse in San Francisco

Challenge Yahoo’s finest and other ramen eating peeps to a game of Wii bowling.

Keeping Help Fresh and Crispy

Our team is starting a project to correct, review, revise and re-organize a large amount of user documentation for financial  industry software. We’ve involved Project Manager’s and Client Service Reps in the process and everyone is excited and supportive of the project.

One thing people keep repeating is, “How do we keep ourselves from doing this again a year from now?”

Our products are constantly updating and we are swamped. How do we make sure our help stays fresh and crispy? How do we ensure the help stays as current as the latest release of the product?

How much is too much?

How do you know, as a Technical Writer, when you are giving too much information.

Yes, one of the great things about the Internet is that you are not limited space-wise in the same way you are when creating actual, paper documents.

However, this can be a curse, especially when it comes to creating user documentation. The more you create, the thicker the forest of links and clicks grows, overrunning any semblance of a straight path from question to answer.

I was recently documenting software at my job for a component that displays a large table displaying financial statement data, among other things. The table can be filtered with drop-downs at he top of the page. The table headings are somewhat complex, breaking down into sub-levels of financial data. I addressed these things in the help but then noticed at the top of the page two icons.

One was a printer icon, one was an Excel icon. For some reason, in much of the help written for the software product I document with a group of about six other people, there are usually instructions for printing or exporting data to Excel.

In most cases, these icons are placed very visibly on the screen and don’t require any additional steps that someone who has printed a document or opened an Excel spreadsheet need to know. Just click an icon, both of which have tool-tips indicating what happens when you click them.

Still, out of habit, I started to write up my little topic about printing and exporting the table data to Excel. But then I stopped myself. It wasn’t necessary information.

I document advanced stock analysis software for the Financial Services industry. Everyone’s portfolio is screwed if the person who is managing my mutual fund is so confused by these icons they have to search help content for instructions on how to use them.

However, morel likely is the possibility that it is the other way, around, they don’t need step by step instructions on the how to click an icon, then click the ok button. But, there is a possibility they may not see the icon. They may not be able to find what they are looking for. In addition, the way the software is set up, there is a main toolbar menu that has a File>Print option. This prints out different things than just clicking the Print icon about the table.

Confusing, huh?

I decided to leave out the Print/Excel instructions, but, as I write this, I realize I was right and wrong. It’s not my job to explain the basic functions of computer use, but it is my job to anticipate confusion between the two print options.

So, the answer is show the user where the icons are in the help documentation, explain what they do, but tasked-based instruction is completely unnecessary.

Don’t think like a user.

Think like a user. Think like a user. It’s the usability mantra. But how can you really think like a user? Especially when you have been documenting the same software for a long period of time. You are familiar with the interface, you don’t have to search for buttons. You know the names of all the toolbars and buttons and special features and you even know you know exactly where to find the answer to questions because you probably wrote the answer yourself.

You are getting so used to talking to Product Managers and Programmers that you are using words like query string and concatenate in instructions for saving documents.

It’s hard to stay fresh as a Technical Writer. Everyone says that no one reads instructions, anyways. It can be discouraging. But people need our help. They really do. And people want to be helped. They want to click that help button and find exactly what they are looking for, quickly.

Unfortunately, you can never truly “think like a user” because you are not a user. You are a Technical Writer. You are a teacher, you are a guide through the bewildering universe of formatting toolbars, right-click menus, dialog boxes and error messages.

When people click the help button, they do not want someone who thinks like them, they want someone who can anticipate their problem and guide them quickly to the answer they are looking for.

Don’t think like a user, think like a user advocate. It’s your job to understand not only what questions users have, but also to know the questions they don’t know they have. To lead them on to more relevant information, to show them things they didn’t even know they had questions about, all the time gently, yet quickly herding them towards the answer to their question.

UI Mockups

This post on the blog Usable Help has a great solution for dealing with the problem of using a screen shot of the user interface to instruct users.

Screen shots of the full interface can be a problem for many reasons. For online help, the window size that displays user documentation may be small and a large screen shot will create scrolling and other usability issues. Also, reducing the image to a size that fits often makes it nearly impossible to clearly view small type on the interface. In addition, in can often be difficult to find a clean, unobtrusive way to highlight specific parts of the interface.

I have experimented with with grey-scaling certain parts of the image to emphasize certain parts of the interface. However, at my job, we do not have Photoshop or similar software, and I have been stuck trying to do this with Fullshot 7, which is not the right tool for the job.

This mock up software is good way to solve this issue, allowing you to create a model of the user interface that can be resized and fit a variety of window sizes.