|
Why care about devices? Because they'll grow faster,
that's why.
They'll grow faster than computers in absolute numbers, and in diversity of abilities, and in the audiences you can reach. They'll offer you more opportunities, more new niches. I also suspect they'll be more fun.
You don't have to care about this new area... lots of work will continue, same as before. But I do think this new area could very well repay your interest.
Let's look at where we came from: After centuries of hand calculation we humans created large mechanical calculators, which gave way to mainframe computers, which shrank down and multiplied into desktop computers.
More people started publishing, and visual design skills increased.
Some started using these desktop computers for presentations, which added animation, audio and video, and which became interactive so that viewers could make choices. Computer prices fell, ownership increased, and you could store more on cheap CDs.
More people started creating applications, and interactive design skills increased.
Then it became cheaper to connect these desktop computers together. From a
slow growth of dialing up individual bulletin boards
to find others of similar interest, Internet access
suddenly exploded and the world changed.
More people started creating web documents and applications, and data design skills increased.
These machines are still getting smaller, and cheaper, and more accessible
to more people worldwide. Interactivity is more important
than ever—you don't want to just look at things,
you want to communicate with others, to do
things. Wireless connectivity is exploding out from
offices and into public areas.
Just as radios changed from a cabinet plugged into a wall to something you
could listen to anywhere—just as bulky rotary
telephones shrank, lost their wires and tagged along
in your pocket—personal computer connectivity
is today becoming part of the background of life.
And I think the rate of change will be greater than
for desktop publishing, interactivity, or the Internet
because this is more of a person-to-person technology
than a broadcast technology. Telephone messaging exploded
recently, but what happens when you add video and
voice? When servers help you connect with new people?
When what one person sees in the world, others can
instantly see?
If you've got skills in visual design, interactive design, or data design, then opportunities to exercise those skills will still increase. But combining these skills with personal connectivity devices will offer you a better reward for your time, I wager.
No one else is poised to take advantage of these opportunities like you are. Who better to design such new applications?
There's a bunch of articles in DevNet this week on the subject. I haven't read them all yet, but I know the people who have written them, and I'd recommend at least scanning them through to pick up background knowledge about where we are right now.
But there are two specific issues we'll be struggling with over the next few years, device homogeneity and interaction distribution, that could use some special attention here.
Device homogeneity is a problem we've all dealt with before. Print designers know about going out to different imagesetters, CD developers know about testing on a range of playback machines, and web designers know about how different browsers implement defined standards in different ways. With devices it's a little trickier, because they have very different displays, processors, inputs, and connection speeds.
We're focusing on two main delivery formats to devices: markup and SWF. When a display is mostly text characters it makes sense to use ASCII or HTML or some other text-based delivery format. A certain amount of interactivity is also possible with JavaScript. As projects get more complex, though, you have to do more testing to handle the various renderers and script interpreters.
That's when the Macromedia Flash Player kicks in. It's a single known engine
across various environments. You still have to test
for form factor, input devices, processing speed,
but using a single engine across multiple environments
spares you from much environmental testing. (If you
use widespread components you could also reap some
labor savings when new devices emerge, because you're
using known encapsulations with a wide user base.)
I suspect the key approach here will be to develop quickly, keep costs low, and float across the waves of devices that arrive. Watch out for getting lots of labor locked up into a single device or single development effort... I suspect it will be stronger to develop the ability to develop quickly. Using the same server-side technology to deliver to either text or SWF lets you take deepest advantage of the widest range of devices.
Interaction distribution is a problem we really haven't had before. How much interaction should be handled on the server, and how much on the client? How much data should be fed to the user, and when should it be fed? How much should you anticipate user needs?
Mapping is a good example. Some maps have a big upfront download, and then
you can zoom in as you wish. Others, like MapQuest,
give you a simple plain pixel map, and then go back
to the server when you wish to zoom or pan.
Or suppose you're looking for a movie schedule, or choosing a restaurant or other service. Should all theatres be downloaded at the start? Or should you be forced to query theatre by theatre? Or something in between?
Or look at a webcam chat app. If each participant is live all the time, then that requires a lot more bandwidth than a "click to talk" implementation. A news aggregator could respond faster if the server integrated various feeds and fed only those articles which matched certain preferred keywords. Where's the balance point in deciding when to cache web service requests? When the interaction is distributed across various machines, how do you design the most efficient and usable experience?
I suspect much will depend on the device's transmission and storage constraints, but it will really require a good imagination on the designer's part to anticipate how to make such applications really usable. It's not enough to just program these applications... good designers become more important than ever now.
Usually I close out these columns with a link to a feedback thread, but I've
found that we tend to discuss these in our usual newsgroups,
mailing lists and weblogs instead. I'll also be traveling
a bit this summer and won't be here consistently to
respond. If you've spent the last few years creating
digital content, then I really believe we're on the
verge of some exciting new abilities... I hope the
articles in DevNet this summer
let you take advantage of these opportunities!
|
