headers
Listera | 1 Jul 2002 01:30
Favicon

Re: [Sigia-l] Elements of Documentation

"christina wodtke" wrote:

> It is much as I thought...

If you could create functional prototypes in roughly the same timeframe
would you bother with any of the other stuff?

Best,

Ziya

------------
When replying, please *trim your post* as much as possible.

*Plain text, please; NO Attachments

ASIST SIG IA website: http://www.asis.org/SIG/SIGIA/index.html
_______________________________________________
Sigia-l mailing list -- post to: Sigia-l <at> asis.org
Changes to subscription: http://mail.asis.org/mailman/listinfo/sigia-l
Permalink | Reply | 10 comments |
headers
Donna Marie Fritzsche | 1 Jul 2002 03:22

Re: [Sigia-l] Elements of Documentation

Personaly,  I would continue with the creation of site maps and at 
least one round of wireframes because the artifacts mentioned serve 
as a form of communication by which collaboration is facilitated and 
ultimate agreement is established.  Additionally, the process of 
creating the artifacts facilitates the IA's processing of information 
and leads to refinements that might not take place if one went 
straight from a set of ideas to code.  The functional prototype can 
also facilitate the above in its own unique manner - in addition to 
offering a new degree of usability testing, but I do not think it 
should wholly replace them.

The working prototype does not give me the same information as the 
site map does for instance.
The working prototype does not invite group interaction and 
collaboration in the same way that a wireframe does.

This was the topic of one of the Chicago IA Learning Hours and we saw 
some excellent examples of both paper and functional prototypes - the 
session illuminated the benefits of each.

Donna

At 7:30 PM -0400 6/30/02, Listera wrote:
>"christina wodtke" wrote:
>
>>  It is much as I thought...
>
>If you could create functional prototypes in roughly the same timeframe
>would you bother with any of the other stuff?
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Donna Marie Fritzsche | 1 Jul 2002 03:31

Re: [Sigia-l] Elements of Documentation

Oops -Excuse my spelling error, I just turned off the command that 
checks for typos on words starting with a capital - I knew it looked 
wrong, but my computer told me it was spelled correctly so I left it! 
eeks!   that  should be:

Personally, I would continue,,,

At 7:22 PM -0600 6/30/02, Donna Marie Fritzsche wrote:
>Personaly,  I would continue with the creation of site maps and at 
>least one round of wireframes because the artifacts mentioned serve 
>as a form of communication by which collaboration is facilitated and 
>ultimate agreement is established.  Additionally, the process of 
>creating the artifacts facilitates the IA's processing of 
>information and leads to refinements that might not take place if 
>one went straight from a set of ideas to code.  The functional 
>prototype can also facilitate the above in its own unique manner - 
>in addition to offering a new degree of usability testing, but I do 
>not think it should wholly replace them.
>
>The working prototype does not give me the same information as the 
>site map does for instance.
>The working prototype does not invite group interaction and 
>collaboration in the same way that a wireframe does.
>
>This was the topic of one of the Chicago IA Learning Hours and we 
>saw some excellent examples of both paper and functional prototypes 
>- the session illuminated the benefits of each.
>
>Donna
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anders Ramsay | 1 Jul 2002 03:22
Picon

Re: [Sigia-l] Elements of Documentation

On 6/30/02 7:30 PM, Listera at listera <at> rcn.com wrote:

> If you could create functional prototypes in roughly the same timeframe
> would you bother with any of the other stuff?

I don't think a prototype by itself could replace documentation.  For any
system more complex than brochureware, e.g. anything containing elements
with more than one state, it could inherently not represent all potential
states of the system. E.g. it can not both represent the state of a list at
a maximum allowable length, and an empty list.  Even if someone were able to
finnagle it to represent all states and rules applying to the system,
actually revealing them would require that the user traverse every nook and
cranny of the prototype, which creates a very high risk of missing a
functional or content requirement (and is very labor-intensive).  And I
speak from experience in this case.  I was handed a project in which the IA
officially was complete, and the completed IA was in the form of a
functional prototype of the site.  Well, I can tell you that the IA was
pretty darn far from complete, and somewhat of a mess to boot.  For example,
the prototype did not/could not reveal how templated pages were to appear
depending on the multiple variations of content that might (or might not) be
present for optional  content slots.  It was in no way apparent what the
display rules were for these variations.  Or because the mock copy in text
pages in the prototype often was at the maximum expected length (which is
good on one hand), it made sense to have redundant navigation (such as
'next/previous' links) at the top and bottom of the page, but it would look
ridiculous if the copy were 1 or two sentences long, which was completely
possible.  The rules for when redundant links were non-existent. But
probably the most significant problem with having only a prototype is that
it increases the risk of what I think of as a cardinal sin  in the world of
system design--inconsistency, in part because it is completely unnecesary.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Scheid | 1 Jul 2002 03:27
Picon

[Sigia-l] IA case studies?

Searching on google for "Information Architecture" and "Case Studies" 
finds thousands of links, many/most not at all relevant sadly.

Good case studies put aside the hype and simply relate the practicalities 
involved. The hard and meaningful facts about the communication, design 
and technology problems which were encountered (and hopefully solved).

Do you know of any IA case studies you particularly liked? What would you 
look for in a case study?

e.

______________________________________________________________________
eric <at> ironclad.net.au                 i r o n c l a d   n e t w o r k s
information architect                      http://www.ironclad.net.au/

------------
When replying, please *trim your post* as much as possible.

*Plain text, please; NO Attachments

ASIST SIG IA website: http://www.asis.org/SIG/SIGIA/index.html
_______________________________________________
Sigia-l mailing list -- post to: Sigia-l <at> asis.org
Changes to subscription: http://mail.asis.org/mailman/listinfo/sigia-l
Permalink | Reply | 2 comments |
headers
Listera | 1 Jul 2002 04:14
Favicon

Re: [Sigia-l] Elements of Documentation

"Donna Marie Fritzsche" wrote:

> Additionally, the process of creating the artifacts facilitates the IA's
> processing of information and leads to refinements that might not take place
> if one went straight from a set of ideas to code.

In my book, 'prototype' is the last stage of structure/interface work and
*not* the first stage of production code. I don't necessarily expect a
single line of code to be adopted from the prototype. It's the distillation
of concepts, structure, architecture, interface, workflow, not a shell for
the production code. (There are ways of prototyping in this sense, with no
or next to no code at all.)

> The working prototype does not invite group interaction and
> collaboration in the same way that a wireframe does.

Perhaps not in the same way, but I've often had the most productive and
enthusiastic input from clients after I show them a prototype. I've written
about this effect before here, but the prototype, unlike anything else,
forces everyone to view the product as something real, something with
consequences, problems, benefits that will soon change their daily work
patterns. That's when everybody starts taking the project seriously. It's
right there. You can click on stuff. It walks and talks like...

So I find that more lights go off after the presentation of the prototype
than anything else. Personally, I want to get there as soon as I can.

Now the critical issue here is that the prototype should be flexible enough
to be changed easily, given all this input. It's the beginning of an
iterative process, not the last, frozen, rigid deliverable. It simply
(Continue reading)

Permalink | Reply | 4 comments |
headers
Donna Marie Fritzsche | 1 Jul 2002 06:26

Re: [Sigia-l] Elements of Documentation

At 10:14 PM -0400 6/30/02, Listera wrote:
>"Donna Marie Fritzsche" wrote:
>
>>  Additionally, the process of creating the artifacts facilitates the IA's
>>  processing of information and leads to refinements that might not take place
>>  if one went straight from a set of ideas to code.
>
>In my book, 'prototype' is the last stage of structure/interface work and
>*not* the first stage of production code. I don't necessarily expect a
>single line of code to be adopted from the prototype. It's the distillation
>of concepts, structure, architecture, interface, workflow, not a shell for
>the production code. (There are ways of prototyping in this sense, with no
>or next to no code at all.)

I was using "code" to mean prototype as you are using it here. - I 
didn't mean it in the sense of production code!

>
>So I find that more lights go off after the presentation of the prototype
>than anything else. Personally, I want to get there as soon as I can.
>
>Now the critical issue here is that the prototype should be flexible enough
>to be changed easily, given all this input. It's the beginning of an
>iterative process, not the last, frozen, rigid deliverable. It simply
>subsumes many of the initial half measures.
>
>This is not a recipe for all projects. It works best with more vertical than
>horizontal ones; more appropriate for online apps than general purpose web
>sites.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Listera | 1 Jul 2002 05:38
Favicon

Re: [Sigia-l] Elements of Documentation

"Donna Marie Fritzsche" wrote:

> How do you address the issue of getting feedback - the iterative nature of the
> process - are people as willing to give you feedback and suggest changes?

Absolutely. That's the whole point.

With anything less than a prototype, you are relying on people to be able to
visualize and contextualize the app with less expressive and sophisticated
aids. Not everybody is as good as you in deciphering diagrams, flowcharts,
wireframes, etc.

Now, it's crucial that the prototype should be presented as the beginning of
an iterative process of a suggestion-refinement cycle, not as the last step
before the production coding. That's where most of the mistakes are made.
Instead of working with drawings on a napkin, you are interacting with a
balsa-wood model, one that you can experiment on.

Best,

Ziya

------------
When replying, please *trim your post* as much as possible.

*Plain text, please; NO Attachments

ASIST SIG IA website: http://www.asis.org/SIG/SIGIA/index.html
_______________________________________________
Sigia-l mailing list -- post to: Sigia-l <at> asis.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
PeterV | 1 Jul 2002 09:12

Re: [Sigia-l] Elements of Documentation

Of interest to this whole discussion could be the IBM goal of connecting 
the documentation with the prototype (and the eventual implementation 
maybe): they model the entire user experience (in a UML style notation, 
based on Rational Rose), and then generate interfaces from that. They've 
been evolving this approach for many years, I saw a presentation on this in 
London last year, and you can download good stuff from http://ibm.com/easy 
(I can't find the URL for the relevant papers and tutorials right now).

http://www.easybase.com/ have a product where you can design functional 
prototypes and then link those to the modelling environment (Rational 
again), that will get updated automatically. So basically you build a 
prototype, and the documentation gets generated automatically from that.

I personally think the idea of "make models and then push the button and 
have a website" will partially work: it will be good enough for 
prototyping, and small websites, the same way Visual Basic (a prototypig 
language really I believe, correct me if I'm wrong with this example) is 
good enough for small applications.
PeterV

------------
When replying, please *trim your post* as much as possible.

*Plain text, please; NO Attachments

ASIST SIG IA website: http://www.asis.org/SIG/SIGIA/index.html
_______________________________________________
Sigia-l mailing list -- post to: Sigia-l <at> asis.org
Changes to subscription: http://mail.asis.org/mailman/listinfo/sigia-l
(Continue reading)

Permalink | Reply | 1 comment |
headers
Listera | 1 Jul 2002 10:03
Favicon

Re: [Sigia-l] Elements of Documentation

"PeterV" wrote: 
> I personally think the idea of "make models and then push the button and
> have a website" will partially work: it will be good enough for
> prototyping, and small websites, the same way Visual Basic (a prototypig
> language really I believe, correct me if I'm wrong with this example) is
> good enough for small applications.

I'm not sure we agree or disagree on this :-) but I'm against the strong
coupling of prototype to production code.

People who have no understanding of the intricacies of code writing should
not be in the business of showing/telling programmers what to do. The
prototype should show WHAT to do. The programmers should deconstruct it to
figure out HOW to do it in code. Mixing the two is asking for trouble.
That's why when I see UML charts done by IAs , business analysts, project
managers, GUI architects, etc., with method descriptions, classes, global
variables, etc., I want to reach for Prozac, AK47 or ice cream, depending on
the humidity outside.

My ideal is to give programmers a functional prototype (preferably done in a
language they don't know) and spend as many hours as they require to go over
every functionality. Step by step. Let them absorb it at their own pace. Ask
me all the questions and let them take their own notes, the way it makes
sense to them. My objective is to make sure that they understand each
functionality;  not necessarily discuss how to implement it in code. That's
usually not what I get paid for (although, occasionally, I look at code to
optimize performance, workflow, etc).

I've seen ridiculously 'well-documented' apps, with specs amounting to a
medium-sized city phone book. You don't have to be a genius to figure out
(Continue reading)

Permalink | Reply | 0 comments |

Gmane