Wireframes for non-web apps

15 Nov 2004 - 5:58pm
9 years ago
36 replies
664 reads
Jenifer Tidwell
2003

Has anyone ever seen or used the term "wireframes" in the context of
an application that's not a Web site or Web app?

At my company, we're working out some guidelines for our numerous
design teams to follow, and we'd like to agree on what to name our
deliverables and processes. This is what we're trying to name:

"A simple low-fidelity mockup of the interface panel/screen contents,
without concern for the graphic look&feel, that communicates the
content and functionality intended for the screen. It might be
annotated with callouts, menu contents, descriptions of behaviors etc.
It could be the backbone for a functional spec, after design review
and agreement on the functionality and behaviors suggested by the
mockup."

I think "wireframe" comes closest, but we're curious about what other
companies and design houses call it.

- Jenifer

---------------------------------------
Jenifer Tidwell
jenifer.tidwell at gmail.com
http://jtidwell.net

Comments

15 Nov 2004 - 6:08pm
Listera
2004

Jenifer Tidwell:

> communicates the content and functionality intended

P
R
O
T
O
T
Y
P
E

There, I said it.:-)

Ziya
Nullius in Verba

15 Nov 2004 - 6:17pm
Jenifer Tidwell
2003

On Mon, 15 Nov 2004 18:08:59 -0500, Listera <listera at rcn.com> wrote:
>
> > communicates the content and functionality intended
>
> P
> R
> O
> T
> O
> T
> Y
> P
> E
>
> There, I said it.:-)
>
> Ziya
> Nullius in Verba

Well, of course it's a prototype.

So is a fully-mocked-up paper prototype of a key window. So is an
onscreen experiment intended to test how smooth the interaction will
be. So is an early-stage storyboard. So is an architectural
prototype intended to test whether the desired functionality can
actually be supported.

I was curious about naming this *particular* kind of prototype, to
help distinguish it from other kinds.

- Jenifer

---------------------------------------
Jenifer Tidwell
jenifer.tidwell at gmail.com
http://jtidwell.net

15 Nov 2004 - 6:24pm
Andrei Herasimchuk
2004

On Nov 15, 2004, at 2:58 PM, Jenifer Tidwell wrote:

> Has anyone ever seen or used the term "wireframes" in the context of
> an application that's not a Web site or Web app?

Yes. It's part of the process I use. And in fact, I've been meaning to
post an article on the proper use of wireframes for digital design for
some time now, as I've seen so many people use them in ways I feel that
are both restrictive an inaccurate for some time now.

> "A simple low-fidelity mockup of the interface panel/screen contents,
> without concern for the graphic look&feel, that communicates the
> content and functionality intended for the screen. It might be
> annotated with callouts, menu contents, descriptions of behaviors etc.
> It could be the backbone for a functional spec, after design review
> and agreement on the functionality and behaviors suggested by the
> mockup."

I would add:

* Is accurate to scale for content, window size, placement of objects
and flow of data. Wireframes that are not accurate to scale (in the
same way blueprints are accurate to scale) tend to allow decision to be
made without a real understanding of the relationship of all elements
on a screen. Without accuracy of scale, wireframes lose a lot of their
usefulness in expediting the design process.

* It *must* be annotated, otherwise, it loses a large part of it
ability to communicate function. Again, same as a blueprint, which is
always annotate to label bedrooms, kitchens, etc.

* Wireframes must use data and content -- whether it be Lorem Ipsum
dummy text or placeholders for objects -- that is set to scale. I can't
tell you the number of times I've seen people use text not to scale
only to discover later they simply don't have the room to do hat they
need to do, and have to rush to bandage the problem.

Andrei

15 Nov 2004 - 6:29pm
Todd Warfel
2003

Regardless of the medium, we still refer to them as wireframes. Here
are a few we've done "wireframes" for:

1. iTV
2. IM
3. MP3 player
4. Mobile phone interfaces
5. Web-based applications
6. Websites
7. CRM (non-web and web)
8. CMS
9. RIAs

Keep in mind that Flash apps (RIAs) can be very close to a desktop
application in terms of functionality, but we still do "wireframes" for
those, which are well annotated. And while many RIAs run inside a web
browser, those that run off Macromedia Central do not. Other than that,
we've done many a wireframe for C and Java apps as well.

On Nov 15, 2004, at 5:58 PM, Jenifer Tidwell wrote:

> I think "wireframe" comes closest, but we're curious about what other
> companies and design houses call it.

Cheers!

Todd R. Warfel
Partner, Design and Usability Specialist
MessageFirst | making products easier to use
--------------------------------------
Contact Info
voice: (607) 339-9640
email: twarfel at messagefirst.com
web: www.messagefirst.com
aim: twarfel at mac.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

15 Nov 2004 - 6:26pm
Andrei Herasimchuk
2004

On Nov 15, 2004, at 3:08 PM, Listera wrote:

> P
> R
> O
> T
> O
> T
> Y
> P
> E
>
> There, I said it.:-)

I would disagree. Wireframes are like blueprints, drawn to scale,
annotated and accurate to make crucial design decisions. Prototypes are
like models built from those wireframes, used to flesh out details, and
get a feel for the end result without having to build the real end
result.

They are not the same thing and do not serve the same purpose. But both
are needed on projects.

Andrei

15 Nov 2004 - 6:54pm
Listera
2004

Andrei Herasimchuk:

> Wireframes are like blueprints, drawn to scale, annotated and accurate to make
> crucial design decisions.

Are you saying that it's impossible to design apps via iterated prototypes
but without producing wireframes as distinct "deliverables"?

Ziya
Nullius in Verba

15 Nov 2004 - 7:07pm
Listera
2004

Jenifer Tidwell:

> I was curious about naming this *particular* kind of prototype, to
> help distinguish it from other kinds.

My point was that prototype is an *iterative* process: it gains
functionality, depth, scope, fidelity, etc., as the design progresses. Its
purpose (as you aptly put it) is to "communicate the content and
functionality intended" but, at least in my world, there's only *one*
prototype, called "the prototype."

Why am I harping on this? I see companies chopping up the design process
into little distinct fiefdoms (usually each reigned over by a title holder)
focused around a "deliverable." It's stop and go. I'd like to see a more
fluid, extended, iterative, comprehensive vehicle to take design from
concept all the way to the doorsteps of the developers, i.e. the prototype.

Ziya
Nullius in Verba

15 Nov 2004 - 7:19pm
Andrei Herasimchuk
2004

On Nov 15, 2004, at 3:54 PM, Listera wrote:

> Are you saying that it's impossible to design apps via iterated
> prototypes
> but without producing wireframes as distinct "deliverables"?

No. Just that wireframes are not prototypes and wireframes cannot
substitute for prototypes and vice versa, which is what you seemed to
imply. Wireframes have their place and purpose on a project, as do
prototypes, in the same way blueprints and models have their place in
the design of buildings or automobiles.

I used to do all my design work with informal wireframes. My own little
sketchbook with grid paper. I never used these wireframes as part of
the general design process with other members of the team. But I'm
finding that opening the wireframes up to other people on the team
makes for a faster, smoother decision at the beginning of a project
making the process moving into the prototyping and production stages
that much more quick and that much more relevant. But only if those
wireframes are accurate to scale and annotated.

I still use lots of iterative prototypes, for all the reasons you have
said to use them. Well done prototypes are great at communication
functionality, useful for testing, and a great way to iterate on the
design quickly once it's up and running. But prototypes can't replace
the purpose of accurate, well annotated wireframes at the beginning
stages of a design project. IMHO.

Andrei

15 Nov 2004 - 7:25pm
Listera
2004

Andrei Herasimchuk:

> But only if those wireframes are accurate to scale and annotated.

We work differently then.

Ziya
Nullius in Verba

15 Nov 2004 - 8:25pm
Pradyot Rai
2004

> Andrei Herasimchuk:
>
> > Wireframes are like blueprints, drawn to scale, annotated and accurate to make
> > crucial design decisions.
>
> Are you saying that it's impossible to design apps via iterated prototypes
> but without producing wireframes as distinct "deliverables"?

Wireframes is irritating by it's very origin, but they are needed in
many circumstances. Their role is much different than "interactive"
prototypes. Although they are best described as "low fedility"
prototypes, mainly geared towards solving communication problem. It
may be hard to understand, but at many places Designers/IAs/UX allign
with business side and never talk to developers directly. In this
circumstance, you need artifacts of UI design process to write
something that can map with requirements, and to it's downstream
phases.

I know, Ziya would say this is another example of how a profession (of
design) gives birth to beurocracy, and I would partly agree with him.
So, if you are at the point to think about wireframes, think also how
can you avoid them. After a while they will become such a huge problem
that you will need bigger team to handle it, bigger than what you need
for improving quality of product.

My 2 cents,

Prady

15 Nov 2004 - 8:59pm
Andrei Herasimchuk
2004

On Nov 15, 2004, at 5:25 PM, Prady Rai wrote:

> I know, Ziya would say this is another example of how a profession (of
> design) gives birth to beurocracy, and I would partly agree with him.
> So, if you are at the point to think about wireframes, think also how
> can you avoid them.

Why avoid them? Would you tell an architect to avoid making blueprints
and just skip to the model building stage? And how are wireframes
contributing to design by committee any more than anything else
designers do?

Wireframes are fine as part of the design process if used for what they
are good for: deciding on structural and architectural pieces of a
design without having to build a full on prototype. Wireframes are
*not* low fidelity prototypes, and to use them such is probably the
problem you're having or are referring to. Wireframes are best used in
the same way blueprints are used in architecture, and in that regard
should follow the same rules of scale, annotation and structural
detail. Prototypes are an entirely different animal and have entirely
different uses in the design process.

To think a designer should actively avoid wireframes seems wrong to me.
That's like saying a graphic designer should ignore using a grid to
create a new magazine layout.

Andrei

15 Nov 2004 - 10:12pm
Jenifer Tidwell
2003

I'll reply to a couple of people at once here.

Andrei, when in the development process do you build your wireframes?
I thought you and I were talking about the same approximate thing -- a
set of low-fidelity "sketches" early in the process, before decisions
are made about specific controls and detailed layout -- but now you're
saying yours aren't low-fidelity at all. So I guess they're different
things.

You make a good point about accuracy of scale, but I usually work on
that at the paper-prototype stage or just beyond. Yes, scale needs to
be sanity-checked early. But until I know most of what's actually
going into the layout, including the length of labels and other text,
I can't possibly create a scale-accurate layout! Those decisions
often aren't made until later, and they can change often, iterative
design being what it is.

The wireframes I'm talking about come earlier than that. We're
thinking of them as the first deliverable with any layout at all, and
they're deliberately very rough. It's for "broad strokes," not detail
work.

Annotation is certainly important, though.

On Mon, 15 Nov 2004 19:07:10 -0500, Listera <listera at rcn.com> wrote:
>
> My point was that prototype is an *iterative* process: it gains
> functionality, depth, scope, fidelity, etc., as the design progresses. Its
> purpose (as you aptly put it) is to "communicate the content and
> functionality intended" but, at least in my world, there's only *one*
> prototype, called "the prototype."

I could see that being valuable under some circumstances. But in my
experience, several prototypes are sometimes needed for solving
different kinds of problems. I'd expect that design prototypes and
engineering prototypes would be developed as separate entities, even
if there's good communication between the people involved. While
their ultimate goals are to produce a working product, their
intermediate goals are very different.

So Ziya, do you mean one single *design* prototype, which ends up
being the spec?

Even if that's so, I'd argue that multiple prototypes are sometimes
needed to fully communicate different aspects of one design. A single
window in an app may require special attention to get the low-level
interaction right, for instance -- one prototype can go
narrow-and-deep on that window, while the rest of the app gets a lower
fidelity, broad-and-shallow prototype.

- Jenifer

---------------------------------------
Jenifer Tidwell
jenifer.tidwell at gmail.com
http://jtidwell.net

15 Nov 2004 - 10:44pm
Listera
2004

Jenifer Tidwell:

> design prototypes and engineering prototypes would be developed as separate
> entities

Bingo, go no further! They should be utterly and absolutely separate. And we
care about only one of them.

Ziya
Nullius in Verba

15 Nov 2004 - 11:02pm
Pradyot Rai
2004

> Jenifer Tidwell:
>
> > design prototypes and engineering prototypes would be developed as separate
> > entities

Listera

> Bingo, go no further! They should be utterly and absolutely separate. And we
> care about only one of them.

This conclusion is not complete unless we go round the circle again -- WHY?

What about design deliverables to engineering? How do you make them
understand Design?

Prady

15 Nov 2004 - 11:11pm
Andrei Herasimchuk
2004

On Nov 15, 2004, at 7:12 PM, Jenifer Tidwell wrote:

> Andrei, when in the development process do you build your wireframes?

Before I build a prototype, after I have done adequate research about
the product and users, and after I have a 80% list of solid
requirements for the functionality of the product from whomever owns
that decision.

> I thought you and I were talking about the same approximate thing -- a
> set of low-fidelity "sketches" early in the process, before decisions
> are made about specific controls and detailed layout -- but now you're
> saying yours aren't low-fidelity at all. So I guess they're different
> things.

They are low fidelity. My wireframes are just accurate to proportion
and scale, just like blueprints, which quite frankly are low fidelity.
That's the only difference. Instead of drawing boxes, I draw boxes that
are to scale. If I know the min size screen is 1024 x 768, I use a 1:1
pixel scale where 1pt. = 1px. If I'm using a 1600 x 1200 screen as a
starting point, I might raw boxes at a 1:10 scale, where 1pt = 10px.

I only use boxes, circles and text for my wireframes. The difference is
that I make everything to scale. I use to do set design back in my
theater days, so drawing to scale takes the same amount of time for me
to think as sketching on grid paper. However, I think it is vital to
draw to scale to see proportionality where you are putting things. In
fact, it's a lot like architecture. Once you start working in this way,
it just comes more natural that even the lowest fidelity wireframe
sketches maintain a good deal of accuracy. It doesn't take that much
time away from "rough sketches."

Also if you don't know the exact character limit of text labels, then
at least accommodate for the worst case scenario to maintain scale and
most importantly, maintain accuracy for the broad decisions you'll need
to make with the wireframe. I discover that if I don't have a grip on
those sorts of details very earlier, coming back to address them later
become a serious pain to correct. So you might as well start addressing
them real early by creating wireframes to scale.

> ...until I know most of what's actually
> going into the layout, including the length of labels and other text,
> I can't possibly create a scale-accurate layout! Those decisions
> often aren't made until later, and they can change often, iterative
> design being what it is.

Then I'd dare say you can't make accurate decisions about a lot other
things as well. In which case, you are using a lot of valuable time in
the design phase when in fact it sounds as if you are still in research
and functional spec stage. Further, if those things are changing, then
you need to get your Product Managers and Engineers under control and
tell them to stop changing things during the design phase of a product.

Iterative design is fine, but if you're iterating so much that you are
changing broad stroke of the design, that just says to me you aren't
spending enough time int he research phase of the project. (I know
that's not always at a designer's control, but there it is.)

> The wireframes I'm talking about come earlier than that. We're
> thinking of them as the first deliverable with any layout at all, and
> they're deliberately very rough. It's for "broad strokes," not detail
> work.

Blueprints lack a lot of detail too. And yet they are very accurate.

Again, drawing to scale and aiming for accuracy takes no more time once
you force yourself to work that way. Wireframes are not about design
detail, but making structural decisions correctly. They act in the same
way blueprints do, as they become (or at least should become) the
foundation for the entire structure of a product.

> Annotation is certainly important, though.

If you are in the habit of annotation, then drawing to scale and
proportions will take a week's worth of training to force yourself into
that model.

Andrei

15 Nov 2004 - 10:18pm
Pradyot Rai
2004

Andrei Herasimchuk <andrei at involutionstudios.com> wrote:

> > I know, Ziya would say this is another example of how a profession (of
> > design) gives birth to beurocracy, and I would partly agree with him.
> > So, if you are at the point to think about wireframes, think also how
> > can you avoid them.
>
> Why avoid them? Would you tell an architect to avoid making blueprints
> and just skip to the model building stage?

Actually, architect's blueprint does not directly translate into
digital design processes milestones. Reason is the nature of two
design processes -- Interaction design can afford to be "iterative",
so you don't need blue print for the sake of it. Most of the software
application developments are heading in the same direction, without
exploiting "iterative" process of design, which is a problem.

WFs should be avoided because they hinder your creativity to think
"interactively". For the same reason, they are low-fedility prototypes
too. All the places where I have seen them, they are used for
documentation or audit purposes. Which then gives birth to another
problem -- managing them, taking attention away from actual product
design/development.

BTW, I am not completely against them either. There are few things in
this industry which just can't run without beurocracy, and WFs are
good at reinstating them.

Prady

15 Nov 2004 - 11:27pm
Pradyot Rai
2004

Andrei Herasimchuk <andrei at involutionstudios.com> wrote:

> They are low fidelity. My wireframes are just accurate to proportion
> and scale, just like blueprints, which quite frankly are low fidelity.
> That's the only difference. Instead of drawing boxes, I draw boxes that
> are to scale. If I know the min size screen is 1024 x 768, I use a 1:1
> pixel scale where 1pt. = 1px. If I'm using a 1600 x 1200 screen as a
> starting point, I might raw boxes at a 1:10 scale, where 1pt = 10px.

I am interested to learn how do you do it at such an early stage, what
tools you use? Also, why do you call it wireframe? I would say this is
very much what one does at prototyping. What am I missing?

The definition of wireframes that has been discussed earlier, is to
capture what can't be otherwise handled with prototyes -- validation
rules, actual content, messages, lables, what-ifs, task flows,
scenarios, etc... And that wireframing tools are different than
prototyping tools.

Prady

15 Nov 2004 - 11:28pm
Andrei Herasimchuk
2004

On Nov 15, 2004, at 7:18 PM, Prady Rai wrote:

> Actually, architect's blueprint does not directly translate into
> digital design processes milestones.

It does more so than you are giving it credit.

> Reason is the nature of two
> design processes -- Interaction design can afford to be "iterative",
> so you don't need blue print for the sake of it.

Architects don't make blueprints for the sake it.

> WFs should be avoided because they hinder your creativity to think
> "interactively".

Sorry, I find that faulty logic and completely disagree. The only thing
that hampers creativity is a designer who allows their creativity to be
hampered. Does the grid hamper graphic design creativity? Does musical
scale and note structure hamper musical creativity?

> All the places where I have seen them, they are used for
> documentation or audit purposes.

Sounds like they are using incorrectly.

> Which then gives birth to another
> problem -- managing them, taking attention away from actual product
> design/development.

Being held accountable in a business process is just the nature of the
beast. You have to embrace that problem head rather than trying to
avoid doing things that would hold you accountable to decisions.

> BTW, I am not completely against them either. There are few things in
> this industry which just can't run without beurocracy, and WFs are
> good at reinstating them.

That's just inaccurate, imho.

Andrei

15 Nov 2004 - 11:29pm
Listera
2004

Prady Rai:

> How do you make them understand Design?

If I may be direct: I don't.

I view folks downstream from design as pure implementers, of what designers
wrought and encapsulated into the prototype.

For example, I wouldn't expect an architect to feel obligated to educate
subcontractors on the nuances of architectural history and various other
aesthetical considerations behind the design of a building.
Contractors/implementers should receive enough input for them to execute the
prototype/blueprint. More than that, they would be playing designers.

So it comes back to: who shall drive design? Designers or somebody else?
In my world, designers design, developers implement. You can expect problems
if either or both move in each other's domain.

Ziya
Nullius in Verba

15 Nov 2004 - 11:39pm
Josh Seiden
2003

I wonder if we are all talking about the same thing
when we say wireframes?

I have always considered "wireframe" to be a fairly
broad term denoting a wide range of informal low- and
med- precision representations of a UI. Included in
this, for me, are whiteboard sketches, word and
powerpoint drawings, visio sketches (with boxes, not UI
elements), paper drawings.

Further, I've always considered a wireframe to be a
type of prototype.

For me, the key things about wireframes are that they
are low (usually) or medium (sometimes) precision
artifacts that are inherently disposable.

Andrei, you've done a good job of describing your idea
of a wireframe. What do the rest of you call a
wireframe?

Jenifer, to your original question: I used wireframes
to represent desktop UI's years before I started
working on the web. But I called them sketches back
then.

JS

16 Nov 2004 - 12:26am
Pradyot Rai
2004

Joshua Seiden <josh at 36partners.com> wrote:

> Andrei, you've done a good job of describing your idea
> of a wireframe. What do the rest of you call a
> wireframe?

Somebody mentioned earlier --
"The definition of wireframes that has discussed earlier, is to
capture what can't be otherwise handled with prototypes -- validation
rules, actual content, messages, lables, what-ifs, task flows,
scenarios, etc... And that wireframing tools are different than
prototyping tools."

I am not understanding whom are you siding with? If Wireframes are
low-fedility prototypes, then there's no debate (neither there is need
for wireframes).

> I have always considered "wireframe" to be a fairly
> broad term denoting a wide range of informal low- and
> med- precision representations of a UI. Included in
> this, for me, are whiteboard sketches, word and
> powerpoint drawings, visio sketches (with boxes, not UI
> elements), paper drawings.

Can you describe -- "fairly broad term denoting a wide range of
informal low- and med- precision representations of a UI" a.k.a.
"wireframe", because this is where this whole group is stuck.

Prady

16 Nov 2004 - 12:35am
Greg Petroff
2004

If we are going to use the Architect practice metaphor
there is a univeral notion of the phases of a project
and the expected deliverables for each phase.

Within architecture you have pre-design, schematic
design, design development, constuction documentation,
construction administration and if you practice design
build then add construction.

Depending on the architect, the size and scope of the
project and the budget for design there will be a host
of different media prepared as part of the process.

In IXD I like to think we do the same /similar things
and then within each we have tools and media that we
prepare.

If an architect uses yellow tracing paper, then
models, then cad models, then water colors then
develops blueprints we do something similar.

We create wireframes, site maps, navigation studies,
interaction studies, low fidelity prototypes, high
fidelity, crude working models etc.

The choice of degree of media, level of
detail/fidelity, presentation styles is highly
personalized in the early phases of a project and
highly standardized in the later when getting into the
documentation phase of an architectural project.

The interesting discussion might be which methods
introduce happy accidents and allow synthesis and
design to flourish, which methods/media refine detail
and develop the design, which methods articulate best
to the builders (software developers) what your intent
is. Which methods convey direction without setting
expectations the wrong way. Can we aknowledge personal
expression, process and methodology while having some
consistant standards to prepare deliverables to
developers.

greg

=====
Gregory Petroff

gpetroff at vizrt.com
+1 212 560 0708 tel
+1 212 560 0709 fax
+1 646 387 2841 mobile

16 Nov 2004 - 12:51am
Listera
2004

Gregory Petroff:

> We create wireframes, site maps, navigation studies,
> interaction studies, low fidelity prototypes, high
> fidelity, crude working models etc.

Shouldn't all these be internal work-products?

> The interesting discussion might be which methods
> introduce happy accidents and allow synthesis and
> design to flourish,

For internal work-products, during design.

I don't think you'd be actively looking for happy accidents after you hand
in your stuff to the developers. :-)

The design end-product, the prototype, should reduce ambiguity and risks as
much as possible, not increase the possibility for accidents, synthesis,
creativity, etc. The time for that is *during* design, among designers [1]
not *after* the prototype is handed over to the developers.

Ziya
Nullius in Verba

[1] As I have said many times previously, I see nothing wrong with
consulting developers for technical clarifications, if designers aren't
efficient at that, during design.

16 Nov 2004 - 1:18am
Greg Petroff
2004

Ziya,

I could be clearer. Much of what I am talking about
can be internal work product. Some never shown to
others. Happy accidents is never at the end of the
process but a question of how a particular method one
uses in the design process including the media,
(paper, digital, visio versus photoshop, etc.) has a
way of:

a: dialoging with/informing you in a different ways
while you are in the process of designing

b: enforcing certain constraints / opportunities on
you because of the media or the softwares ways of
working.

Happy accidents in my book in a simplest way to
describe it is sketching roughly on paper an idea only
to see something completely different that is more
valuable to you in your drawing because of the nature
of that media, something that you had not thought of
before. Kind of like looking at clouds and seeing
shapes in them and then seeing another. Certain
exercises we undertake during the design process can
really dialog with us and can be exploited if you know
the weakness and strengths of each.

Its the difference between paper prototyping and
building low fidelity wireframes. Using vector
graphics like visio and using nested shapes or using
layers in photoshop.

During early design of a project this can be highly
specialized to the individual designer and part of
their unique process.

Along the way we all have to use our work products to
meet with the customer and gain buy in, to discuss
"engineering" considerations with developers to
document our decisions, to test with potential users
before we hand it over to builders.

The thought I was trying to make is that in
architecture the steps are well known. The individual
process during the design phases of an effort are
highly varied but when "documentation" for
construction is created to give the builder there is a
very structured and agreed upon methodology for doing
this.

Similarly in ixd we could benefit by having a
discussion about what those deliverables are that are
handed over to developer from a format, content and
level of detail perspective.

Greg

=====
Gregory Petroff

gpetroff at vizrt.com
+1 212 560 0708 tel
+1 212 560 0709 fax
+1 646 387 2841 mobile

16 Nov 2004 - 1:30am
Listera
2004

Gregory Petroff:

> Happy accidents is never at the end of the process but a question of how a
> particular method one uses in the design process...

No problems here then.

(I'm fascistic only when developers want to play designers, not when
designers want to pick different creative tools during design.:-)

> Similarly in ixd we could benefit by having a discussion about what those
> deliverables are that are handed over to developer from a format, content and
> level of detail perspective.

Fair suggestion.

I think this is preceded, however, by a firmer understanding/agreement on
what design role can/should developers play. If, as previously suggested
here for example, you hand in usecase prose to developers [meaning they'll
interpret, expand upon and ultimately (re)design] the nature of the
discussion would be very different.

Ziya
Nullius in Verba

16 Nov 2004 - 11:00am
Jennifer Brownson
2004

--- Jenifer Tidwell <jenifer.tidwell at gmail.com> wrote:

> [Please voluntarily trim replies to include only
> relevant quoted material.]
>
> Has anyone ever seen or used the term "wireframes"
> in the context of
> an application that's not a Web site or Web app?

Yes. We use the term wireframe, but I've also seen
them called screen mocks.

Jen

__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com

16 Nov 2004 - 12:00pm
erin malone
2004

I have always called them wireframes. Whether representatives of a web
page or of a screen in an application - the essence is the same: a
blueprint of the functionality and maybe layout of the elements. I
have also heard them called schematics. All the work at AOL was for
software applications - not web and we still caled them wireframes.

/e

On Mon, 15 Nov 2004 17:58:26 -0500, Jenifer Tidwell
<jenifer.tidwell at gmail.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> Has anyone ever seen or used the term "wireframes" in the context of
> an application that's not a Web site or Web app?
>

16 Nov 2004 - 12:06pm
Todd Warfel
2003

Well, it looks like what he's saying is that they're a blueprint
(guideline) with annotations for making (guiding) intelligent
(informed) design decisions. I don't see anything in Andrei's statement
about "impossible".

Clearly you can make a prototype w/o them, but that's not necessarily
the best approach. A prototype serves a different purpose than a
wireframe.

On Nov 15, 2004, at 6:54 PM, Listera wrote:

>> Wireframes are like blueprints, drawn to scale, annotated and
>> accurate to make
>> crucial design decisions.
>
> Are you saying that it's impossible to design apps via iterated
> prototypes
> but without producing wireframes as distinct "deliverables"?

Cheers!

Todd R. Warfel
Partner, Design and Usability Specialist
MessageFirst | making products easier to use
--------------------------------------
Contact Info
voice: (607) 339-9640
email: twarfel at messagefirst.com
web: www.messagefirst.com
aim: twarfel at mac.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

16 Nov 2004 - 12:22pm
Narey, Kevin
2004

Todd wrote:

>Clearly you can make a prototype w/o them, but that's not necessarily
>the best approach. A prototype serves a different purpose than a
>wireframe.

At the moment in my current environment.....
I see a full wireframing exercise being a non-technology specific research
tool as a precursor to a prototype.
Where the technology of choice has already been defined (yes I know that's
not ideal) - then I would wireframe less.
The prototype is characteristically a form of the technology based solution
intended for the final product (some people may see this as Hi-Fi).

Kevin
_______________________________________________
Interaction Design Discussion List
discuss at ixdg.org
--
to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
--
Questions: lists at ixdg.org
--
Announcement Online List (discussion list members get announcements already)
http://subscribe-announce.ixdg.org/
--
http://ixdg.org/

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

16 Nov 2004 - 1:15pm
Andrei Herasimchuk
2004

On Nov 16, 2004, at 9:22 AM, Narey, Kevin wrote:

> At the moment in my current environment.....
> I see a full wireframing exercise being a non-technology specific
> research
> tool as a precursor to a prototype.

That's the thing about my use of wireframes. They aren't a "research
tool." They are a design tool. They are used to build out the
architectural and structural design of the thing I'm working. I don't
use wireframes for the purpose of research, I use them to help make
decisions on the larger design approach. Hence the need for wirefames
to be accurate to scale.

Andrei

16 Nov 2004 - 3:47pm
Peyush_Agarwal ...
2004

Comparing software design-build process with architecture is fine, but I
have noticed some inconsistencies in the mapping of processes.

In particular, the usage/purpose of blueprints as opposed to "our"
wireframes. To me, they are not analogous at all. Blueprints are
effectively design-build specifications for consumption by governing
agencies to understand the proposed work, contractors to understand the
scope/deliverable of work, and as final deliverable to the client (before
perhaps overseeing the construction). Blueprints are exact in their scale
and proportions, and have a tremendous amount of annotation/written
details. In fact the whole construction should be aparant from blueprints
on paper. Changes happen on site of course, but the lead-in is always the
blueprint; in fact, specifications on BPs and accompanying docs constitue a
contract between the client and the contractor/s who have agreed to
implement the BP. Any departure from BPs on site requires education of the
people upstream i.e. the architect, client, regulatory agency etc.
depending upon the gravity of the change.

I doubt if most people on this list assume wireframes to be those
documents.

The software design-build equivalent of the above would be UI
specifications which would include mock-ups (if they are intended to be
implemented as is), use cases, IA, ID diagrams, and even prototypes (if
their scope is defined alongside). Mock-ups could be 1:1 WYSIWYG or a paper
sketch drawn in proportion or define layout rules, and has detail enough
for devs to implement properly. Use cases just describe the different
scenarios of use so devs can implement behavior for those conditions, ID
could address the screenflow to complement identified taskflows or
usecases, and prototypes could be a visio clickable or paper sketch, or
even an HTML proof-of-concept. These are needed to be delivered to Devs/PMs
etc. for them to estimate the scope of work to a higher precision and know
what they need to implement exactly.

So where do wireframes figure?

To me, wireframes lie on the initial end of the design process where the
designer is considering/drawing/mocking alternate designs with some
high-level specification (for example: design A will be layed out in 3
columns, design be will have 2 sets of label:field columns, and a 2-level
hierarchy of buttons etc.). These will have a flow of screens if pertinent.
The designer may choose to share these with others for iteration or do it
him/herself. These might even be presented as final output, though then
they will actually be design specs and will need to include a lot more
annotation for implementing it as designed.

I disagree with the viewpoint that wireframes need to be drawn in scale and
need to have all details figured out in one pass. That's akin to saying the
blueprints ought to be figured out in one pass. Firstly, they would not be
wireframes but rather a specification meant to be relatively final as WFs
are a high-level view of the emerging system. Second, you never have all
info at the same time, but must produce something, however high-level or
incomplete so iteration can take place providing the design with further
resolution. WFs can even be rough sketches, communicating with proportions
rather than scale, responding with specifics to all known design
constraints, and generalizing against unknown factors.

All this is semantics of course; a person can use whatever tools in
whatever process to produce design. The key is to deliver a design spec so
it can be followed without ambiguity by the dev team so it delivers the
user experience you desire.

Regards

Peyush Agarwal
Interaction Designer
EnterpriseOne
PeopleSoft Inc.
303-334-0603 Phone
303-334-1815 Fax
peyush_agarwal at peoplesoft.com

16 Nov 2004 - 4:51pm
Andrei Herasimchuk
2004

On Nov 16, 2004, at 12:47 PM, Peyush_Agarwal at peoplesoft.com wrote:

> Blueprints are exact in their scale
> and proportions, and have a tremendous amount of annotation/written
> details. In fact the whole construction should be aparant from
> blueprints
> on paper.

Indeed, this is true. I wouldn't take my "wireframes" analogy to that
depth, but in terms of some sort of way to think of wireframes, I feel
that comparing them to blueprints is still relevant. Mostly with regard
to scale. But I agree the analogy is bit stretched.

> The software design-build equivalent of the above would be UI
> specifications which would include mock-ups (if they are intended to be
> implemented as is), use cases, IA, ID diagrams, and even prototypes (if
> their scope is defined alongside).

I would disagree that use cases, IA and ID diagrams constitutes "specs"
to be used in the same way a blueprint would be. No UI spec I have ever
written or used puts those design docs into the final spec. Prototypes,
yes, but definitely not those other pieces.

> To me, wireframes lie on the initial end of the design process where
> the
> designer is considering/drawing/mocking alternate designs with some
> high-level specification

Agreed.

> I disagree with the viewpoint that wireframes need to be drawn in
> scale and
> need to have all details figured out in one pass.

I don't think I ever said they need to have all the details figured out
in one pass. Just that wireframes should be drawn to scale.

I'm curious, what is so hard or difficult about drawing to scale? Why
are people resisting this aspect for wireframe work? It really takes
little extra effort and makes the entire process for figuring out broad
design problems about a thousand times easier in my experience.

Andrei

16 Nov 2004 - 5:12pm
Alain D. M. G. ...
2003

--- Andrei Herasimchuk <andrei at involutionstudios.com> a écrit :

> I'm curious, what is so hard or difficult about drawing to scale? Why
>

Because there is no fixed reality to refer to, as is the case for
blueprints. You never know ahead of time exactly how things will turn
out given the various types of computers and their versions of
operating systems.

Even with traditional paper blueprints making true scale drawings is a
lot of work, a lot of infinite constant attention to detail. I was the
head of a CADD (we used Autocad) department for a large cellular phone
service company (Bell was a competitor) and we churned out dozens of
different kinds of drawings (rack layouts, antenna locations, antenna
orientations, equipment shelters, microwave interconnect maps, etc.)
and not a single one of them was to scale. It would have taken too
much time. We could never have produced thousands of drawings (black
and white blueprints in a sense) and their constant modifications, and
the ever present "as builts" that followed, each month with such a
small staff. To respect drafting customs and standards one of the
metadata boxes in the lower right of each drawing always had NOT TO
SCALE written in it in very large letters.

Alain V.

__________________________________________________________
Lèche-vitrine ou lèche-écran ?
magasinage.yahoo.ca

16 Nov 2004 - 5:29pm
Andrei Herasimchuk
2004

On Nov 16, 2004, at 2:12 PM, Alain D. M. G. Vaillancourt wrote:

>> I'm curious, what is so hard or difficult about drawing to scale? Why
>
> Because there is no fixed reality to refer to, as is the case for
> blueprints.

That doesn't make much sense to me. I usually don't start my wireframes
until I know minimum systems requirements (which gives me screen size)
and a agreed upon list of features that is 80% of the way there. So I
very much work from "reality" in this regard.

> You never know ahead of time exactly how things will turn
> out given the various types of computers and their versions of
> operating systems.

I disagree with this. Very much so in fact. It's our job to know how
things will turn out on a variety of systems if we are designing
software.

> Even with traditional paper blueprints making true scale drawings is a
> lot of work, a lot of infinite constant attention to detail.

For final blueprints, sure, it can be a lot of work. Again, my analogy
comparing wireframes to blueprints is a bit stretched and overreaching,
and that I admit. The blueprint analogy in my mind has more to do with
the spirit of what blueprints convey information-wise and what
wireframes should convey information-wise. And in that I find
wireframes drawn to scale and proportionality correct to be far more
effective than when they are not.

> I was the head of a CADD (we used Autocad) department for a large
> cellular phone
> service company (Bell was a competitor) and we churned out dozens of
> different kinds of drawings (rack layouts, antenna locations, antenna
> orientations, equipment shelters, microwave interconnect maps, etc.)
> and not a single one of them was to scale.

Slightly off topic, but why bother with CADD software then? Why not
just use pencil and paper?

> To respect drafting customs and standards one of the
> metadata boxes in the lower right of each drawing always had NOT TO
> SCALE written in it in very large letters.

Sure, but I'll bet they were proportionally correct, weren't they? I'd
even be happy if more designers would create wireframes that are
proportionality correct. Also, to be clear, the wireframe work we do in
this field is significantly simpler than the things you are describing,
so drawing rough wireframes to scale doesn't not seem like a burden to
me.

Andrei

16 Nov 2004 - 6:38pm
Peyush_Agarwal ...
2004

[I would disagree that use cases, IA and ID diagrams constitutes "specs"
to be used in the same way a blueprint would be. No UI spec I have ever
written or used puts those design docs into the final spec. Prototypes,
yes, but definitely not those other pieces.]

I was generous in including use cases as part of specs, but the intent was
that's what dev team needs to match their implementation goals against.
However they *do* need IA and ID diagrams to keep track of screenflows and
hierarchies they are coding. In my experience, exposing this information to
devs has always resulted in better construction, than not sharing these.

[I'm curious, what is so hard or difficult about drawing to scale? Why
are people resisting this aspect for wireframe work? It really takes
little extra effort and makes the entire process for figuring out broad
design problems about a thousand times easier in my experience.]

I don't believe its necessary to do them to scale, only that they be
roughly proportional. Scale introduces additional overhead whose benefit is
typically not worth the effort at initial design formation stages.
Wireframes are like a bird's-eye view as opposed to something like a
photoshop mockup which might be eye-level. As in architecture, initial
design work is not about being exactly accurate, its about exploring ideas
on how pieces will work together, and then iterate. Another way of defining
appropriate level of detail for a wireframe is what you'd likely see with a
squint-test is what should be represented on a WF. So for me, its more
about layout, containers, areas of functionality, proximity, prominence,
screenflows etc. As I've mentioned before, you can deliver WFs as your
design spec, but its no longer exactly a WF anymore.

Regards

Peyush Agarwal
Interaction Designer

16 Nov 2004 - 9:26pm
Daniel Harvey
2004

Schematics get used a lot as well.

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com]On Behalf Of Jennifer Brownson
Sent: Tuesday, November 16, 2004 11:01 AM
To: discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: Re: [ID Discuss] Wireframes for non-web apps

[Please voluntarily trim replies to include only relevant quoted material.]

--- Jenifer Tidwell <jenifer.tidwell at gmail.com> wrote:

> [Please voluntarily trim replies to include only
> relevant quoted material.]
>
> Has anyone ever seen or used the term "wireframes"
> in the context of
> an application that's not a Web site or Web app?

Yes. We use the term wireframe, but I've also seen
them called screen mocks.

Jen

__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com

_______________________________________________
Interaction Design Discussion List
discuss at ixdg.org
--
to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
--
Questions: lists at ixdg.org
--
Announcement Online List (discussion list members get announcements already)
http://subscribe-announce.ixdg.org/
--
http://ixdg.org/

Syndicate content Get the feed