Language Lag

While reading NYT's How to Train a Teacher, I noticed that the fifth slide shows a digital video recorder (Flip Mino) and the caption says the class is being videotaped. Now, that kind of camera uses either an SD card or internal flash memory, so there is no tape involved - but "videotaped" is how the process of recording is described.

This reminded me of how - fifteen years or so ago, when I was a freelance video shooter (using tape, yes) - the clients and even some people in the business would say what we did was "filming." You couldn't call it "recording" because then there would be a question as to whether we were recording audio only, and "filming" was easier to say than "videotaping" -- less than half the syllables. I think "film" sounded more professional and more high-class, too. People knew what you meant, even if the terms were not technically correct.

But now we say "videotape." Most people these days have little familiarity with film of any kind, so they say "videotape" instead of "video recording." It doesn't sound more professional or high-class &emdash; fewer syllables seems to be the goal. But videotape is hardly common, either. It's maybe only a little more common in everyday life than movie film was way back in the 90s. But everybody knows what videotape is (just like everybody then and now knows what a home movie is, even if they've never seen a Super 8 camera).

Maybe it's the same kind of safety-thinking that leads many of us to wait a while before getting a new version of Windows or Photoshop or whatever you happen to use daily. In the case of technology, you want to make sure it's going to work reliably, even if it means you'll stick with something that is arguably outdated; and in the case of language describing a technologically-driven process, you want to be sure your meaning is reliably understood, even if the words describing the process are no longer accurate.

The end goal is what's important - just as your computer needs to work without crashing, the concept of the act of recording video needs to be conveyed. Being easily understood is the point -- and that's a usability issue.

So... in fifteen years, when our videos all go straight to the cloud, will we be saying "I'll card your class today" or "I'm going to flash you when you give your presentation?"

That's going to be interesting.

Do you need a use case or a target audience?

Do you need a use case or a target audience?

A use case means considering how your product will be used by a hypothetical individual who represents a part of your user base - for example, a tech-savvy 35-year-old project manager who is eager to do all her administrative reports in a shared web-based environment instead of working in Microsoft Word and sending the reports as email attachments (note that the use case may be more or less specific). If you're building a product to serve this person, you've got some specifics to work with regarding probable expectations, the amount of guidance and hand-holding needed, and so on. By developing additional use cases describing other probable users (and these are developed by talking with the client - you may even have access to the users themselves) you will have done the groundwork for making a design that suits the users. A target audience is more of a passive recipient, not a true user. "Anyone working in acquisitions" for example. Without a real understanding of the users, the product will be generic and bland. You'll be doing the least you can - putting the product out there in another gray blob among thousands of gray blobs that meet the requirements but are ultimately forgettable. Understanding the difference between a user and an audience is important - are you showing them something or are they doing something?

This distinction is not unique to the web - a hands-on constructivist learning product based on paper or in the classroom can just as easily be dulled into a passive presentation, but web- based products provide constant opportunities to make the choice whether to lecture or to engage. Can the user get in there and really use it -whatever it is - without being told at length what it is, what to do, and how to do it? Less telling the user about the product and more of the user using the product is the goal.

Collaboration - synergy or too many cooks:

Every stakeholder has an opinion. So they should. But if every stakeholder is pushing and pulling the design of a product in a different direction - even if every stakeholder has some knowledge of design, and every stakeholder won't - the result will function poorly and please no one. Like users, stakeholders will tell you what they think they want with little idea of what is actually needed. If you can make them understand that their knowledge of engineering or sales or contracts does not qualify them as art directors or graphic designers - and the good ones will know this already - then you will be able to proceed more efficiently. Beyond the subject matter experts, your colleagues - managers, artists, programmers - will likely have views that they will feel should be accepted gratefully and integrated into the design. Compromising here - to keep the peace in the office or out of friendship - will compromise the design.

Management will often announce an initiative to promote collaboration. Sometimes they'll rearrange the workspace to serve this goal, without realizing the effect an "open" or "collaborative" workspace can have on getting the actual work done - distractions and interruptions can become the rule rather than the exception. In that case you'll find yourself looking for ways to get the work done despite all the collaboration. Don't take this to mean that good ideas cannot come from anyone, anywhere. But you have to retain the power to pick and choose. If you're designing the product, be sure you make the decisions. Individuals decide. Groups decide to meet again.

Honesty

The importance of honesty in design:

Beyond the obvious concerns of conflict of interest or complying with nondisclosure agreements, you have to be honest about your capabilities and your expectations - first with yourself, and then with clients and colleagues. The consequences of deceiving yourself or your partners in the effort, whatever that effort may be, can be quite serious. The professional, financial, legal, and personal costs are worth taking some care to avoid. Be able to assure yourself that every decision you make was made because it was the right thing to do - it's too easy to talk yourself into spending time (yours and the user's) and the client's money on an unnecessary feature that you personally liked or wanted experience with. Did you do it because it was right for this product at this time, or did you do it just because you could?

Perception, rightly or wrongly, is also a factor under this topic. Does your work seem honest? Designs that are unnecessarily complex give the impression that the designer is trying to conceal something - incompetence, perhaps. Conversely, a clean, simple approach is reassuring to both the user and the client - as well as being more effective. They should never wonder if what they're seeing is really what they're getting. Your work and your approach to the work should be simple and straightforward.

Pitfalls of Organizational Thinking

Foreseeing the pitfalls created by organizational thinking:

Any large organization will eventually pollute any good idea. It's true - we've all seen it time and again. And it's not because of malice or malevolence. We like to think organizations operate on a strategic scale - the big picture. The truth is, organizations are operating in response to a multitude of little pictures - one for every member. That amount of compromise, of splitting the difference, of horse-trading to get anything moving forward leads to an end product that rarely bears a resemblance to the original concept. If you think about how government seems to work, or the military, or corporate management, you'll see what I mean. So how does anything get accomplished? Working groups, tiger teams - environments protected from the larger organization just to get things done, to get projects off the ground. This is a good approach, and it's followed by organizations large and small. But there's a built-in danger. The organization will often view the special team, and their work, with suspicion and resistance.

Why?


Organizations are entities - corporations, for example, are treated in many ways like people from a legal standpoint. Like a person, self-preservation and by extension maintenance of the status quo are basic reactions to any change in the environment an organization exists in. Innovation can easily be perceived as a threat - because it's a change to the status quo. If you suggest a change to workflow, standards, or processes, the organization will often push back. You will likely find yourself pushing back when a change comes toward your own working routine - quite naturally. And change is not always good, and it isn't always (or usually) easy to tell. The trick is to keep yourself from expecting an organization to readily embrace whatever change you may be trying to bring - that expectation will frustrate you and quite possibly sour you on both the task and the organization itself. With that, it's also necessary to ask yourself whether your initial (and natural) resistance to a change coming toward you is really a gut instinct that you see a disaster looming.

Reality? Check.

Every now and then, step back and ask: am I living in the real world?"

Are you sure?

From The Center for Internet and Society at Stanford University Law School. Fair(y) Use Tale.

It takes a little patience at first, but it's well worth it for a good lesson on copyright principles.... using Disney characters.