[Sigia-l] Diagramming tools?

[Stew Dean]

On 4/5/07, Ziya Oz <listera at earthlink.net> wrote:
> Stew Dean:
>
> > First up you run into the danger of...
>
> [a lot of strawman arguments snipped]
>
> > ...Awful IA work.

The central argument is that an overly technical approach to creating
a user eperience ends up with an overly compliated and obscure
interface that does a lot with lots of whizzy bits but doesnt really
answer the core user journeys.

User journeys often form the heart of what I do now, they are easy to
communicate to the client, easy for anyone to understand and feed
directly into all kinds of aspects of the process - be it translating
them into use cases or just sanity checking what you've designed.


> You *can* take a pencil and stab yourself into interminable pain, too. You
> can keep drawing diagrams till the cows come home and never leave Kansas.
> Yes, there are countless ways to screw up if you are so inclined.

So to avoid screwing up you do some planning before divng in. The
diagrams I draw are akin to architectural diagrams for a building, the
set the scope prior to build.

Or as I say....

> > There are very good reasons to diagram first before rushing to code.
>
> Or you can start by understanding that the prototype is not a proof of code
> but a proof of concept.

I would be able to understand that if you go through how you create
the prototype and explain what YOU mean by prototype. Is it a
wireframe with clickable bits or more than that?


> Early on, the prototype might illuminate how, say, a change in one widget
> might affect content or form in another widget to a certain set of
> stakeholders.

Widgets?

 > At another milestone in its lifecycle, the same prototype
> might demonstrate to developers how that widget-to-widget interaction is
> simply an array manipulation.

You mean the developers descide that the best way to impliment the
'widget' or element of the interface to turn it into english, is by
manipulating an array.  How they achive the results I've designed is
up to them, I am not the developer and trust that they will provide
the fastest, most stable solution.




> In the first instance, all you want is the
> smile on the faces of non-technical people when they witness the smooth
> interaction between two widgets that, say, hides a whole bunch of previous
> complexity.

Again - widgets?  Sorry but sounds like flash bits just of the sake of it.

> In the second instance, all you care is that developers realize
> beyond all that UI wizardry all they have to do is to map two arrays from
> two different XML files. And so on.

I want them to understand how I want the interface to work. What the
error cases are, the exceptions etc. Notes are better than a prototype
in that case becaue if you include all error case it's very time
consuming and almost the finished product and also you are reliant on
the developer playing with the interface to find all the
possibilities.  A diagram trumps a prototype in making this visible
quickly.

A prototype is good for checking flow and for clarifying things in
some ways, like I've said, I've used them, but they have problems.  Do
you acknowledge that or are you too set in your ways? (something you
are claiming everyone else is).


> > Now if there was a way diagrams could be transformed into prototypes
> > that's great.
>
> There are many tools that operate in that domain, some even from Microsoft.
> MSFT even sells a tool that can interactively move from a logic flow diagram
> to rules/code, back and forth. Depends on what you want.

I want to turn wireframes into prototypes from process folows and sitemaps.

> > I used to use Flash for this and I still recommend it.
> > Other tools are available but appear to be very 'drag a widget'
> > orientated, not sure they will allow me to prototype up some of the
> > new interface elements I use.
>
> Flash isn't the appropriate tool for that. Flex is You can do a lot of UI
> prototyping in Flex with components that actually function with no or
> minimal scripting.

It's widgets. It's also an IDE.

> > I'm sure someone will come up with a way to appease both of us but so
> > far I havnt see you suggest a solution.
>
> I'm not into imposing 'obvious industry standards.'

Neither am I.  Visio is the obvious industry standard at the moment.
I'm not imposing it, that's just what's happening. Water is wet, night
is darker than day and most IAs use Visio.

Go back to Flax and explain why a platform designed for coders can be
of use in the IA process.


> > How do you prototype your sites?
>
> I'm a designer,

Not again.

> therefore context is everything to me.

The ironic thing is the word designer requires context to be
understood. Desgner is usualy preceded by something to add context. A
sound designer is not the same as a interaction designer.

> I use whatever tool
> is needed for a given context from HTML to Flex to Basic to PowerPoint to
> Visio. They are just tools.

Okay can't argue with that.


> > Can you see a time when a diagram is better than a prototype?
>
> Yes, when you can't create a prototype.

This does contradict what you've already said. So much for context and
appropiate solutions.

-- 
Stewart Dean