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

[Stewart Dean]

On 16/11/05 10:41 am, "Listera" <listera at rcn.com> wrote:

> Stewart Dean:
> 
>> I see my job as designing the user experience.
> 
> Setting up a UX scenario of, say, grabbing a live electrical wire while
> standing in a bathtub full of water only betrays deadly confusion about what
> works and what doesn't. Knowing something about electricity/conductivity/etc
> won't hurt you.

What are you talking about?

 
>> That's why you have a project manager to say...
> 
> Interesting. You won't let knowledge of technology affect your creativity
> but gladly let a PM dictate the boundaries?

It's a compromise - you have a budget - so time is set. Part of my time
working with the technical team to see how the user experience can be
implemented (or not). I'd be nuts to set those limits on myself unless I
know as much as the technical team. I trust the folks I work with and the
project is so much better for specialists.

 
>> with the right experience you know where the compromises are to be made.
> 
> If "right experience" does not contain knowing something about technology,
> how do you know where to make the compromises?

You've got the wrong end of the stick are beating yourself around the head.
The point is I do know about the technology, not as much as the tech team
but enough to be a techie at times. What I'm saying is I'm not worrying
about that - not worrying about the implementation until later, much later.
It's at that much later the compromises are made.
 
> The reality is that if you don't/can't anticipate the technical ramification
> of your own design choices, technologists will certainly dictate them to
> you.

But that is not the reality. I say it's dangerous to double guess what is
possible in most cases, even if you have a good amount of technical
knowledge. I am saying that avoiding a technical mind set it vital to good
user experience design. An information architect should not be seen as one
of the technical people on the team.
 
>> By trying to double guess...
>> If you start off limited...
>> as few will understand what it really does...
>> And a little bit of knowledge is a dangerous thing.
> 
> To me, these signal a fear of technology, indeed an abdication of a
> designer's obligation to understand the tight interplay between design and
> technology, concept and implementation, strategy and tactics, etc.

Actually it's a healthy disrespect for technology - it shall do our bidding,
not the other way around. The tight interplay is a red herring - we are
talking about team work and that happens through communication, not by doing
each others jobs.
 
> Why should you "double guess" or feel "limited" or lack understanding or be
> satisfied with "a little bit of knowledge" of how what you conceptualized
> can or cannot be implemented?

Because you are not the implementer on the team. It doesn't matter how much
you know about the technology, you might even be a good programmer, as long
as you're the IA or similar role you need to focus on the user experience
not JavaScript. To my mind not focusing on the user but worrying about
implementation is pointless and will result and bad design.

 
> Who will pay you to conjure up scenarios, for example, that cannot possibly
> be implemented given the resources of your client?

That has nothing to do with the Javascript question - that's understanding
the business which is again removed from technical implementation and should
be abstracted out. 

>From the way you're speaking I get a feeling you're much more in the
implementation camp than the user experience design camp.

> Who will pay you to recommend, say, a great high-def user experience for
> your teenage audience by "assuming" 1080p video streaming at several Mbps
> over ordinary DSL?

That's all technical detail. In the user experience design I specify full
screen high quality video and then see what is possible through the
compromise process. I never state things like 'it will be 1080p video' -
that's not part of the initial user experience design but determined at the
compromise stage.


> Or instant language translation without understanding the
> current limitations we have?

That is a work flow issue. I would state a page needs to be available in
more than one language - how it's translated is an implementation issue. Why
do you want it to be instant? The user needs the content in French - how
that is achieved is implementation.

> Or ensuring accessibility to certain disabled
> audiences without knowing what can and cannot be done?

Accessibility is mostly an implementation issue! Content creation is a user
experience issue and there are accessibility guidelines for that. I work
with meta data etc and common templates that can then be coded up to achieve
accessible standards.

> Or designing a UX
> dependent on real-time database lookups via Ajax without having some
> understanding of scalability issues at the backend or browser
> multithreading?

Who says it's dependent on real time database lookups. I would say something
needs to update. Sure I know about Ajax and what it can do but to have a bit
of information update in real time on the screen could use many different
methods - all of them are implementation.

Your examples prove the point I am making. The implementation in all these
cases are separate from the user experience definition and are later brought
together. 

> Or "porting" apps to mobile devices without a firm grasp of
> the severe technical limitations therein? And so on.

I don't port apps. I only need to worry about the display options and speed
of response (time and space).

Let me give you another example of why getting to close to the technology is
bad for the user experience, and one I've seen far to often, and that's the
'because you can' school of user interface design. If you look at those who
are heavily into flash you'll see a lot of wizzy stuff done because they
can, not because it improves the user experience. Flickr is a good example
where some of that also happens, the user experience in places is confused
because it finds new ways to do things but does it in an inconsistent way.

If you really want to create the best user experience you need to have a
healthy disrepect for technology, to be able to think outside of the
onscreen box and think about the users first, the business issues second
(after all nearly all of use are here to make them money) and the technology
is way down the list after things like content.

My view is you should be able to take any user experience and impliment it
in a totally different way and it will still work as effectively. Sure the
nature of time and space you've used will dictate which machines it will or
won't work on but it's a good attitude to have to user experience in my
view.

Stewart Dean

Stewart Dean