Re: Diagramming tools?

On 4/5/07, Ziya Oz <listeraearthlink.net> wrote:

> If in fact Visio is the 'obvious industry standard' and
thus reflects the
> current state of the art, so to speak, we're all in
trouble. Technology and
> design have moved on from wireframes, static pictures,
site-maps, the page
> paradigm, etc. That's so last century. And so
inadequate in the era of fast
> prototyping, interactivity, dynamic apps, Ajax, mobile
devices, declarative
> language driven UIs and so on.

The concept of creating a prototype is good and recommended
in many
cases but has problems. First up you run into the danger of
approaching the user interface form an overly technical
point of view.
Why is this bad?  Well quite simply instead of thinking of
the user
journeys, about what the user wants and starting from a
technical
level you run a huge danger of thinking 'I saw this great
ajax app
that allowed me to flip pages, let's use that'. You can end
up using
lots of arbitrary elements that just look cool. In most
cases a good
user experience is about keeping things as simple as
possible,
reducing the amounts of button presses and the visual noise.
New
techniques for updating pages on the fly really help and I
now use
these a lot but I don't get bogged down in how it's done.  I
was
taught in university to use time in my interfaces and now
can do that
on the web. It's not Ajax or Flash but a time based
interface. Many
Web 2.0 interfaces are currently as unusable as Web 0.1
beta
interfaces, often due to lack of context and relying on
assumed
knowledge.

If you have to code up your solution you can become  focused
on the
bells and whistles not the core use experience.  For example
some may
become fixated on personalisation because that's part of the
CMS tool
kit, when really it's just targeting customers that can be
done using
the sites navigation!  You can also assume that the user
wants more
power tools than they need. Again customisable pages are a
indication
of this.  I recently worked with a IA who had clearly come
from a
technical background. His dream for an intranet was to have
lots of
customisable pages, that way the user could create the site
they
wanted.  Problem is that's a lot of hard work on the part of
the user,
they have go through a sharp learning curve to understand
what they
can add, you have to do a lot of hard work to create ways
they can
find the content they need and you start becoming very
reliant on
having a great search.  Search becomes the primary
navigation tool in
this case.  Awful IA work.

There are very good reasons to diagram first before rushing
to code.
Now if there was a way diagrams could be transformed into
prototypes
that's great.  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.

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.  How do you
prototype your
sites? What are the weaknesses of the process and in what
types of
projects  does your process work best?  Can you see a time
when a
diagram is better than a prototype?

Stew Dean

-- 
Stewart Dean
------------
IA Summit 2007:  Enriching IA
Rich Information, Rich Interaction, Rich Relationships
March 22-26, 2007, Las Vegas, NV
www.iasummit.org
-----
When replying, please *trim your post* as much as possible.
*Plain text, please; NO Attachments

Searchable Archive at http://www.in
fo-arch.org/lists/sigia-l/




________________________________________
Sigia-l mailing list -- post to: Sigia-lasis.org
Changes to subscription: http://
mail.asis.org/mailman/listinfo/sigia-l

Stew Dean:

> First up you run into the danger of...

[a lot of strawman arguments snipped]

> ...Awful IA work.

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.

> 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.

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

This is not about code, it's about revelation of design
intent
contextualized for different audiences at different times.
It's a matter of
appropriate communication. It's to move the idea along the
path to
completion. Nothing achieves that as well as a prototype.
Nothing.

> 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 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.
 
> 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.'

> How do you prototype your sites?

I'm a designer, therefore context is everything to me. I use
whatever tool
is needed for a given context from HTML to Flex to Basic to
PowerPoint to
Visio. They are just tools.

> Can you see a time when a diagram is better than a
prototype?

Yes, when you can't create a prototype.

----
Ziya

Complexity is simple.



------------
IA Summit 2007:  Enriching IA
Rich Information, Rich Interaction, Rich Relationships
March 22-26, 2007, Las Vegas, NV
www.iasummit.org
-----
When replying, please *trim your post* as much as possible.
*Plain text, please; NO Attachments

Searchable Archive at http://www.in
fo-arch.org/lists/sigia-l/




________________________________________
Sigia-l mailing list -- post to: Sigia-lasis.org
Changes to subscription: http://
mail.asis.org/mailman/listinfo/sigia-l

On 4/5/07, Ziya Oz <listeraearthlink.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
------------
IA Summit 2008:  
April 10-14, 2007, Miami, Florida

-----
When replying, please *trim your post* as much as possible.
*Plain text, please; NO Attachments

Searchable Archive at http://www.in
fo-arch.org/lists/sigia-l/
________________________________________
Sigia-l mailing list -- post to: Sigia-lasis.org
Changes to subscription: http://
mail.asis.org/mailman/listinfo/sigia-l