[IxDA Discuss] True or False: In a perfect world we'd all create html clickable wireframes after the static ones have been don

[James Leftwich, IDSA]

This seems to be a never-ending discussion, regarding methods of  
design and development.  I contract to have certain system/apps that  
I've designed prototyped, but certainly not all nor even the majority.

I work on wireframes, graphical layouts and keyframes, intensive  
flows, and comprehensive implementation documentation, and have done  
so for numerous OS GUIs (starting back in the 80s), lots of medical  
equipment and devices, complex military systems, and so many mobile  
device, phone, smartphone, and media players that I can't even count  
them.  And I've envisioned and designed the entire dynamic experience  
architectures and the layout of every screen, menu, sequential  
pathway, and the general rules for extension and further development  
in my head and then documented.

Many times in my career, the programmers implementing my interaction  
design and interfaces have been remote, or have done all the  
implementation afterward.  I don't do websites, but this has included  
lots of very complex systems and even some that had many different  
types of applications within an overall OS application framework  
(that I also designed).

If I'd mocked up or made interactive every thing I've designed since  
1983, it would've taken much longer and would've taken time away from  
intense detailing and functional management that I spent my time on  
instead.

Nowadays, I and my partners will often have portions mocked up and  
made interactive, mostly for show to our clients or execs while  
implementation is underway.  No engineers I work with would prefer to  
have interactive models _in lieu of_ the kinds of implementational  
documentation I've traditionally provided.

So mileage varies, and many of us that have been working in this  
field for decades have developed a number of highly leveraging  
methods for getting more designed faster, and implemented with  
rigorous detail and consistency.

None of my most successful products and software were interactively  
prototyped.  If you know it and can see it in your head (upside down,  
backward, and in every dimension dynamically), you can document it in  
such a way that when it's implemented, it will be just as conceived.   
Work out the details on paper, and learn to communicate with massive  
detail (and in my projects, considerable attention to generalized  
rules and patterns), and you'll do fine.

Don't ever let anyone tell you that there's only one way, or a best  
way to design interaction.  It's just not true.

Jim

-------------------------------
James Leftwich, IDSA
Orbit Interaction
Palo Alto, CA
jleft at orbitnet.com
http://www.orbitnet.com



> From: davewalker at interfacevisuals.com
> Date: September 28, 2007 3:45:30 PM PDT
> To: "Dan Saffer" <dan at odannyboy.com>, "IxDA Discuss"  
> <discuss at lists.interactiondesigners.com>
> Subject: Re: [IxDA Discuss] True or False: In a perfect world we'd  
> all	create html clickable wireframes after the static ones have	 
> been done
>
>
> I agree that wireframes are useful. I also think that prototypes  
> are critical if we are to advance our trade. I use my own  
> wireframes to build working prototypes, because I need the  
> discipline that comes from doing the wireframe. Prototypes are a  
> lot of work and that work can be wasted if you haven't already put  
> process behind it.
> This is especially true if you are delivering XAML directly to a  
> dev team. The XAML can be a prototype, but because it is also the  
> actual design, wireframes help refine the vision before creating  
> the XAML. Wireframes are a lot easier and it's just easier to toss  
> my darlings into the wastebin and start over. If I go directly to  
> the XAML, inevitably I invest too much and I try to hard to rescue  
> early explorations from the cutting floor.
> Dave
>
>> -----Original Message-----
>> From: Dan Saffer [mailto:dan at odannyboy.com]
>> Sent: Friday, August 31, 2007 05:59 PM
>> To: 'IxDA Discuss'
>> Subject: Re: [IxDA Discuss] True or False: In a perfect world we'd  
>> all create html clickable wireframes after the static ones have  
>> been done
>>
>>
>> On Aug 31, 2007, at 2:15 PM, Victor Lombardi wrote:
>>
>>> Andrei wrote:
>>>
>>> RE>I think one has to build a functioning prototype of what you
>>> design for any project...
>>>
>>> Amen. Wireframes follow a workflow that architects use that is
>>> inappropriate for what we do. As the Henry Dreyfuss quote
>>> illustrates, industrial design is a much better metaphor. Industrial
>>> designers have 'works-like' prototypes and 'looks-like'
>>> prototypes, but non-interactive wireframes are neither, and lacking
>>> vital usefulness.
>>
>> Really? In the world I live in, where I don't always get to hook up
>> prototypes to live databases and where I have neither the time nor
>> resources to build prototypes that replicate every use case I can
>> think of, wireframes are still important. Why? Because they can
>> document detail that a prototype, unless it is absolutely working
>> (which is to say, it is the final product) cannot. I can also link
>> decisions in a design to earlier decisions and show how logic flows
>> within an application in a way that is not apparent in a prototype.
>> Unlike analog objects made by industrial designers, the "works-like"
>> prototypes to demonstrate digital behavior are extremely challenging.
>> I'd argue that is what wireframes really are: the "works-like"
>> prototypes.
>>
>>
>>> there's no reason to keep using static diagramming tools.
>>>
>>> 2007 should be the year the wireframe dies.
>>>
>>
>> Actually, there are a lot of reasons. Paper has been shown time and
>> time again to be an excellent communication tool. The time it takes
>> to diagram (and revise that diagram) on paper is considerably less
>> than the time it would take to mock it up (unless we're talking some
>> really basic product). Paper is easily transportable and simple to
>> edit and draw on. On paper, unlike a prototype, I can document:
>>
>> - Logic flows
>> - Constraints
>> - Conditional states and their triggers
>> - Changes to the design over time
>> - Notes on the hows and whys something is to be built to the
>> developers/engineers/industrial and graphic designers.
>>
>> Paper documents can be read of sit beside my teammates as they
>> work to make my design a reality without forcing them to launch a
>> prototype and have to re-engineer it themselves from what they are
>> seeing. Wireframes show how a product is to be built--information
>> that can be used to build a prototype as well. But digital products
>> are no better than another product--and perhaps worse than analog
>> ones--in that you can't see what the constraints and specifications
>> are from simply looking at a prototype of a final product.
>>
>> In my mind, wireframes and prototypes are two sides of the same coin.
>> Both serve different purposes and one shouldn't substitute for the
>> other, except in some cases. Both are important and I'd never confuse
>> one for the other, or substitute one for the other if I could help  
>> it.
>>
>> Dan
>>
>> ps. I do know that there are some people who do hybrids--mixing a
>> prototype with annotations. That is kind of cool.