[Sigia-l] "Who Really Turns Off JavaScript?"

[Stewart Dean]

On 15/11/05 11:47 pm, "Listera" <listera at rcn.com> wrote:

> Stewart Dean:
> 
>> I say forget the technology for at least most of the time.
> 
> Why?

Glad you asked.

I see my job as designing the user experience. The only real limits I need
to concern myself about are the time and space constraints, in HCI terms
these are time multiplexing and space multiplexing. A web site traditionally
uses space over time and computer games tend to use time over space. Extreme
examples a newspaper is space and a film is time.

So why all this conceptual stuff?  Simply because  I view the user
experience as implementation neutral to a large degree. The elements of a
user experience, such as scroll bars, hyper links, multiple pages, menus,
sound effects, keys to get to you past a door, zombie with a chain saw are
what we are concerned about. How they get there can be done in a thousand
different ways. By trying to double guess how something is going to
implement you are much more likely to limit  yourself and miss good user
experience ideas than if you say 'I'll forget about and just think how
ideally this should work'.

In short the functionality should be separated from the technology to allow
the most effective and appropriate solution. This is not totally without
limits and the arena for exploration is set by the space and time factors I
mentioned above, but even these can be pushed. We also build up a tool kit
of guidelines around the user experience, such as always provide a forward
path, always provide feedback to the user and have the most important and
used items most visible but none of these relate to technology.

To my view you can create a user experience for a project then have tailor
it for many different platforms. Having worked on Kiosks, interactive TV,
web and CD rom I probably have a different view to those who have done web,
web and a bit more web. It also means that 'web 2.0' just means I have to
make less compromises.


>> My view is everything is technically possible given enough time and money...
> 
> Therein lies the art and science of design: balancing the needs of the user
> and the client.

User = user experience. Business = business model.

> In other words, there's almost never enough time and money.

That's why you have a project manager to say - okay Stew, you have X amount
of days and implimentation is Y days. You start off blue sky and then bring
it into land by compromising so it is feasable. If you start off limited
you'll end up with a crimpled solution.

> You make a wrong architectural or design decision on a multi-million dollar
> project because you were unfamiliar with some technology that made some
> interaction pattern possible *or* impossible (as in, beyond your means) you
> have only yourself to blame. Knowing something (strategy) and implementing
> it at the code level (tactics) are not the same thing.

This really isnt how things work. I work on large projects on a constant
basis and work as a team - with the right experience you know where the
compromises are to be made. The larger the project the more the need to
ignore the technology as few will understand what it really does and trying
to set functionality by what it current does at the moment is a very very
bad idea to do. The technology will do what you want it to do in most cases,
if not then you find a compromise. But often if you don't set the
functionality over the implimentation you'll never get the best user
experience.
> 
> What you don't know can hurt you.

And a little bit of knowledge is a dangerous thing.

Stew Dean