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

[Stewart Dean]

On 16/11/05 7:21 pm, "Listera" <listera at rcn.com> wrote:

> Stewart Dean:
>  
>> That's all technical detail.
> 
> As a consultant who has lost tens of of thousands of dollars and a number of
> projects by insisting not ever to work with IT depts or get technology
> involved until a prototype was done over the years, it's purely ironic that
> we're having this discussion. But I'm trying not to open a can of worms
> about this that has been the subject of so many threads on this list.

I say open it. I understand why you would loose money by not working with
techies. If you read what I've been writing I've been promoting working with
them but during the design phase forgetting about implimentation. First you
find out the rough restraints of the communication you have, business needs,
user research - you then create and you then have to make it work, you can't
do that WITHOUT the technical department.
 
> I'll reiterate the narrow point which you have glossed over: Knowing about
> technology and implementing it are two *different* things. In the examples I
> gave, a lot of time and money could have *easily* been saved by
> understanding the technological barriers that rendered them impossible.

That's because you where specifying what technology was going to be used.
That's what I don't do and it works.

> Your approach is to let some programmer tell you much later down the process
> that it is, so that you can go back and forth to compromise and redo it. My
> advice is that if you already had an understanding that a concept is a
> non-starter because it's not implementable given a project's resources or
> technical barriers, there's no reason to waste time on it and wait for a
> compromise. After all, bad choices and going down blind alleys, does take
> time and resources away from pursuing more optimal choices. There's no free
> lunch. Not knowing it can give you agita.

As I haven't dictated the technical solution but what must happen from a
users perspective if the implementation can't match this then I'm working at
high enough level to make subtle changes that have little impact at on the
user experience but make the implementation much smoother. Getting the right
level of abstraction is the art and from all you've said I think you've got
it too  detailed. 

For example I see it my job to define inputs and outputs and when they
happen. It is not my job to say 'and then it writes to the database'. If
you've ever written that on a functional spec you are, without doubt,
working at the wrong level. In my world user cases only ever have humans as
'actors'. 

Stewart Dean