Managing Complexity of Wireframes

29 May 2008 - 11:46pm
6 years ago
20 replies
1010 reads
Oleg Krupnov
2008

I'm looking for the current best practices of managing complexity of
wireframes.

What do you do in the following situations?

1. A page includes multiple panels, each of them is quite complex, with many
details and notes. How to show all child panels and their notes without
cluttering the parent page's wireframe?

2. A page includes an interactive panel, i.e. one that has multiple states.
The size of the interactive panel can be small (i.e. a creeping line) or
large (i.e. a tab page). How to show all panel states best?

3. A page includes a panel that is reused on different pages (i.e. as common
info block), or multiple times on the same page (e.g. item in a list). How
to show the reused panels best, avoiding copying/out-of-sync problems?

4. Different notes and different level of detail should be shown to
different audiences. How to create different versions of the same wireframe
best? Also what to do if there is not enough room in the sidebar for all
footnotes?

Thanks!
--
View this message in context: http://www.nabble.com/Managing-Complexity-of-Wireframes-tp17532426p17532426.html
Sent from the ixda.org - discussion list mailing list archive at Nabble.com.

Comments

30 May 2008 - 12:00am
Steve Baty
2009

Oleg,

One thing I try to aim for in my documentation is that each page has the
same density of information. So where I have a screen that includes a lot of
complexity, I would look to break that complexity off into separate pages
with references on the parent. That principle would apply to your scenarios
1 & 2. And it applies across deliverables for that project. Depending on the
primary audience for the wireframes I'd adjust the 'standard' level of
complexity and then maintain that density consistently.

For scenario 4 I would use layering within your wireframing tool and place
the more detailed information into layers that are hidden or shown depending
on the audience.

For scenario 3 I would use the equivalent of a pattern library with the
parent wireframe containing a simple representation with a reference to the
component detailed wireframe.

Regards
Steve Baty

2008/5/30 Oleg Krupnov <oleg.krupnov at gmail.com>:

>
> I'm looking for the current best practices of managing complexity of
> wireframes.
>
> What do you do in the following situations?
>
> 1. A page includes multiple panels, each of them is quite complex, with
> many
> details and notes. How to show all child panels and their notes without
> cluttering the parent page's wireframe?
>
> 2. A page includes an interactive panel, i.e. one that has multiple states.
> The size of the interactive panel can be small (i.e. a creeping line) or
> large (i.e. a tab page). How to show all panel states best?
>
> 3. A page includes a panel that is reused on different pages (i.e. as
> common
> info block), or multiple times on the same page (e.g. item in a list). How
> to show the reused panels best, avoiding copying/out-of-sync problems?
>
> 4. Different notes and different level of detail should be shown to
> different audiences. How to create different versions of the same wireframe
> best? Also what to do if there is not enough room in the sidebar for all
> footnotes?
>

------------------------------------------------
Steve 'Doc' Baty B.Sc (Maths), M.EC, MBA
Principal Consultant
Meld Consulting
M: +61 417 061 292
E: stevebaty at meld.com.au

UX Statistics: http://uxstats.blogspot.com

Member, UPA - www.upassoc.org
Member, IA Institute - www.iainstitute.org
Member, IxDA - www.ixda.org
Contributor - UXMatters - www.uxmatters.com

30 May 2008 - 12:15am
Oleg Krupnov
2008

Thanks Steve,

Your answer is clear except that I don't quite understand how you
technically avoid the problem that a child panel wireframe, contained
in another drawing document, and copied to the parent wireframe in
scenarios 1, 2, 3, can get out of sync when its source is modified? Do
you mean (by the "simple representation") that you don't copy but
instead show a plain gray box with a reference? In this case, doesn't
it affect the visual presentability of the parent wireframe?

Are there other caveats I have overlooked?

Oleg.

On Fri, May 30, 2008 at 8:00 AM, Steve Baty <stevebaty at gmail.com> wrote:
> Oleg,
>
> One thing I try to aim for in my documentation is that each page has the
> same density of information. So where I have a screen that includes a lot of
> complexity, I would look to break that complexity off into separate pages
> with references on the parent. That principle would apply to your scenarios
> 1 & 2. And it applies across deliverables for that project. Depending on the
> primary audience for the wireframes I'd adjust the 'standard' level of
> complexity and then maintain that density consistently.
>
> For scenario 4 I would use layering within your wireframing tool and place
> the more detailed information into layers that are hidden or shown depending
> on the audience.
>
> For scenario 3 I would use the equivalent of a pattern library with the
> parent wireframe containing a simple representation with a reference to the
> component detailed wireframe.
>
> Regards
> Steve Baty
>
> 2008/5/30 Oleg Krupnov <oleg.krupnov at gmail.com>:
>>
>> I'm looking for the current best practices of managing complexity of
>> wireframes.
>>
>> What do you do in the following situations?
>>
>> 1. A page includes multiple panels, each of them is quite complex, with
>> many
>> details and notes. How to show all child panels and their notes without
>> cluttering the parent page's wireframe?
>>
>> 2. A page includes an interactive panel, i.e. one that has multiple
>> states.
>> The size of the interactive panel can be small (i.e. a creeping line) or
>> large (i.e. a tab page). How to show all panel states best?
>>
>> 3. A page includes a panel that is reused on different pages (i.e. as
>> common
>> info block), or multiple times on the same page (e.g. item in a list). How
>> to show the reused panels best, avoiding copying/out-of-sync problems?
>>
>> 4. Different notes and different level of detail should be shown to
>> different audiences. How to create different versions of the same
>> wireframe
>> best? Also what to do if there is not enough room in the sidebar for all
>> footnotes?
>
> ------------------------------------------------
> Steve 'Doc' Baty B.Sc (Maths), M.EC, MBA
> Principal Consultant
> Meld Consulting
> M: +61 417 061 292
> E: stevebaty at meld.com.au
>
> UX Statistics: http://uxstats.blogspot.com
>
> Member, UPA - www.upassoc.org
> Member, IA Institute - www.iainstitute.org
> Member, IxDA - www.ixda.org
> Contributor - UXMatters - www.uxmatters.com

30 May 2008 - 12:26am
Steve Baty
2009

Oleg,

Not a plain grey box, but close to it - you should be able to strike a
balance; all of that extra detail is contained in the separate
representation. An actual object library can also be used if your
wireframing supports them. Although I suspect no matter what software you
utilise, synchronising instances of a panel will require some effort.

Other caveats: the final choice will necessarily depend on how you feel most
comfortable working :)

Steve

2008/5/30 Oleg Krupnov <oleg.krupnov at gmail.com>:

> Thanks Steve,
>
> Your answer is clear except that I don't quite understand how you
> technically avoid the problem that a child panel wireframe, contained
> in another drawing document, and copied to the parent wireframe in
> scenarios 1, 2, 3, can get out of sync when its source is modified? Do
> you mean (by the "simple representation") that you don't copy but
> instead show a plain gray box with a reference? In this case, doesn't
> it affect the visual presentability of the parent wireframe?
>
>

30 May 2008 - 1:03am
Oleg Krupnov
2008

And I've been thinking about the following solution: you draw both
parent and child on the same wireframe, but in different layers, and
then draw their notes, in another two layers. Then you switch the
notes layers parent/child. In this way you can show both parent with
preview of the child and the child in context of its parent. Do you
think it's practicable to do so?

Oleg.

On Fri, May 30, 2008 at 8:26 AM, Steve Baty <stevebaty at gmail.com> wrote:
> Oleg,
>
> Not a plain grey box, but close to it - you should be able to strike a
> balance; all of that extra detail is contained in the separate
> representation. An actual object library can also be used if your
> wireframing supports them. Although I suspect no matter what software you
> utilise, synchronising instances of a panel will require some effort.
>
> Other caveats: the final choice will necessarily depend on how you feel most
> comfortable working :)
>
> Steve
>
> 2008/5/30 Oleg Krupnov <oleg.krupnov at gmail.com>:
>>
>> Thanks Steve,
>>
>> Your answer is clear except that I don't quite understand how you
>> technically avoid the problem that a child panel wireframe, contained
>> in another drawing document, and copied to the parent wireframe in
>> scenarios 1, 2, 3, can get out of sync when its source is modified? Do
>> you mean (by the "simple representation") that you don't copy but
>> instead show a plain gray box with a reference? In this case, doesn't
>> it affect the visual presentability of the parent wireframe?
>>
>

30 May 2008 - 2:53am
Sam Woodman
2008

Oleg,

Not too sure what software you're using to do your wireframes, but
I've designed and specified websites before with a similar sort of
complexity using Axure. Axure allowed me to create wireframes with
different panels in the page and different states for each panel.
Axure has a great prototyping feature and also the ability to export
specifications to a Word document. When exporting, all of the
features, panels and states are automatically described in the
specifications document. Therefore if you update your wireframes, you
simply re generate the specs. I understand that it's difficult to
switch software half way through wireframing, but I'd recommend you
take a look perhaps for next time.

Sam

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=29601

30 May 2008 - 6:42am
Dan Brown
2004

Oleg,You're not alone. More and more, we IxDs are dealing with situations
like the one you describe.

You're asking about two things:

1. How do make the document understandable given the complexity of the
interface
2. How to manage the document given the complexity

For #1:

We've found it most effective to document each "panel" (we call them
components) separately. One page of your document can show different
versions/states.

For #2:

We put each panel and each wireframe in separate files. This way we can
"place" one inside the other. When one file is updated, it is reflected in
all the other files in which it's been placed. This technique makes the
documentation much easier to manage because a certain amount of that
management is automated.

Now the tools that do this successfully are limited. We use Adobe InDesign
CS3, which does file-placing beautifully. OmniGraffle's support is limited.
Visio's support is promising, but I haven't used the tool in a while, so I
can't speak to it.

Note that with this file-placing technique, it becomes much easier to create
separate documents for separate audiences, because you need create the
wireframe (or panel or component) only once and place it into two different
documents.

-- Dan

On Fri, May 30, 2008 at 12:46 AM, Oleg Krupnov <oleg.krupnov at gmail.com>
wrote:

>
> I'm looking for the current best practices of managing complexity of
> wireframes.
>
> What do you do in the following situations?
>
> 1. A page includes multiple panels, each of them is quite complex, with
> many
> details and notes. How to show all child panels and their notes without
> cluttering the parent page's wireframe?
>
> 2. A page includes an interactive panel, i.e. one that has multiple states.
> The size of the interactive panel can be small (i.e. a creeping line) or
> large (i.e. a tab page). How to show all panel states best?
>
> 3. A page includes a panel that is reused on different pages (i.e. as
> common
> info block), or multiple times on the same page (e.g. item in a list). How
> to show the reused panels best, avoiding copying/out-of-sync problems?
>
> 4. Different notes and different level of detail should be shown to
> different audiences. How to create different versions of the same wireframe
> best? Also what to do if there is not enough room in the sidebar for all
> footnotes?
>
> Thanks!
> --
> View this message in context:
> http://www.nabble.com/Managing-Complexity-of-Wireframes-tp17532426p17532426.html
> Sent from the ixda.org - discussion list mailing list archive at
> Nabble.com.
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--

Dan Brown, Principal • (301) 801-4850
EightShapes, LLC • eightshapes.com
Also at: communicatingdesign.com • greenonions.com

30 May 2008 - 7:04am
Todd Warfel
2003

1. Patterns—using patterns will address items 1-3 in your list. Have
the patterns first in your wireframe deck w/all their behavior notes
and states.

2. Layers in InDesign (or other)—using layers for behavior notes will
tackle #4. You can have notes on different layers for each audience.

On May 30, 2008, at 12:46 AM, Oleg Krupnov wrote:

> I'm looking for the current best practices of managing complexity of
> wireframes.
>
> What do you do in the following situations?
>
> 1. A page includes multiple panels, each of them is quite complex,
> with many
> details and notes. How to show all child panels and their notes
> without
> cluttering the parent page's wireframe?
>
> 2. A page includes an interactive panel, i.e. one that has multiple
> states.
> The size of the interactive panel can be small (i.e. a creeping
> line) or
> large (i.e. a tab page). How to show all panel states best?
>
> 3. A page includes a panel that is reused on different pages (i.e.
> as common
> info block), or multiple times on the same page (e.g. item in a
> list). How
> to show the reused panels best, avoiding copying/out-of-sync problems?
>
> 4. Different notes and different level of detail should be shown to
> different audiences. How to create different versions of the same
> wireframe
> best? Also what to do if there is not enough room in the sidebar for
> all
> footnotes?

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

30 May 2008 - 7:47am
Fred Beecher
2006

To elaborate on how Axure can help with this...

On 5/30/08, Dan Brown <brownorama at gmail.com> wrote:
>
>
> We've found it most effective to document each "panel" (we call them
> components) separately. One page of your document can show different
> versions/states.

This is exactly how Axure handles it when you output printed documentation.
However, it's slightly annoying as the "dynamic panels" section is at the
end of the document. When I generate a spec I cut and paste this info to be
near the container page. So it ends up looking like this:

Page Wireframe
Page Annotations
Dynamic Panel State 1 Wireframe
DP State 1 Annotations
DP State 2 Annotations
Etc.

When you create a DP, you specify its 1 or more states. Then when you edit
each state, it displays as its own wireframe. If it's the first state,
that's what you'll see on the actual page wireframe. You then use
interactions (OnClick, OnMouseEnter, etc.) to change the state of the panel
in the HTML prototype.

We put each panel and each wireframe in separate files. This way we can
> "place" one inside the other. When one file is updated, it is reflected in
> all the other files in which it's been placed. This technique makes the
> documentation much easier to manage because a certain amount of that
> management is automated.

In Axure, you have the capability to create "masters." You can create a
master that has a dynamic panel and drag it to as many pages as you like. If
you change something about the master, every instance of that master
instantly reflects the change.

Now the tools that do this successfully are limited. We use Adobe InDesign
> CS3, which does file-placing beautifully. OmniGraffle's support is limited.
> Visio's support is promising, but I haven't used the tool in a while, so I
> can't speak to it.

Since I've started using Axure (maybe 2.5 years ago), I literally have not
used Visio for wireframes *at all.* It meets more of our needs more easily,
oh and it outputs prototypes too. : ) Seriously though, the ease of
accomplishing what I need to accomplish plus the ability to do rapid
prototyping has revolutionized and improved the way I work. It has improved
the quality of my work as well, by allowing me to ideate madly and then very
quickly and simply test those ideas.

I hope this is all helpful! If you have any specific questions, feel free to
ask.

- F.

30 May 2008 - 8:02am
Oleg Krupnov
2008

Thanks Todd,

Please explain what do you mean by patterns in this context.

Oleg.

30 May 2008 - 6:18am
Guru
2008

Hello all

The discussions and the comments IxDA gives me a great insight about
IxDesign

Now i am in a project which is similar to have the interface like
iGoogle i.e, drag and drop feature...

I have to build wireframes for this...How can i build wireframes
for this project. Is there any tool available for this kind of
prototypes?

I have some experience in using Axure RP to build wireframes

Could anyone please tell me some suggestions?

Also any resource URLs or Links would be great helpful for me

Thanks
Guru

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=29601

30 May 2008 - 8:07am
.pauric
2006

Oleg "3. A page includes a panel that is reused on different pages
(i.e. as common info block) , or multiple times on the same page
(e.g. item in a list) . How to show the reused panels best, avoiding
copying/out-of-sync problems?"

Omni has a master page feature that was designed for common layout
structures... headers, navigation etc. You can have multiple
masters.

A trick I've used in the past is to tailor multiple masters when
there's a need for common element on a few pages. E.g. I've got a
5 page wizard to design, I create a new master from the original
master, layout the common wizard components in the new master and
then go on to design the individual pages.

This works well if the master layout is set and you can start
duplicating them, then link to the customised masters to reuse the
component instead of the copy'n'pasting issue you describe in No.3.
I hope I've understood the issue correctly?

But be warned.. it doesn't scale too well and can push the
dependency break further upstream if you find yourself having to
change the layout basics in the masters. Its not the end of the
world modding the masters as they are generally fewer in number.
Also, this technique doesnt address your need for the same component
multiple times on one page.

I always wished components on the page could be dependent on changes
in the stencils in Omni. Maybe someone knows of a way to do that?
That would totally nail this issue.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=29601

30 May 2008 - 8:13am
AlokJain
2006

Guru,

You could do it in three ways:

1. Just use diagrams to explain each state of drag and drop
2. Use flash or something like that to create an animation
3. Use javascript library like Scriptaculous/Yahoo UI - http://script.aculo.us/
- might seem a big deal initially, but its not so much.

I haven't tried Axure myself, so can't talk about that.

Regards
Alok Jain

On May 30, 2008, at 4:18 AM, Guru wrote:

> Hello all
>
> The discussions and the comments IxDA gives me a great insight about
> IxDesign
>
> Now i am in a project which is similar to have the interface like
> iGoogle i.e, drag and drop feature...
>
> I have to build wireframes for this...How can i build wireframes
> for this project. Is there any tool available for this kind of
> prototypes?
>
> I have some experience in using Axure RP to build wireframes
>
> Could anyone please tell me some suggestions?
>
> Also any resource URLs or Links would be great helpful for me
>
> Thanks
> Guru
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=29601
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

30 May 2008 - 8:22am
Oleg Krupnov
2008

Thanks Fred and Sam,

I agree that Axure makes some real good points. In particular, it
seems to handle wireframe complexity pretty well by its masters and
dynamic panels.

I am a little wary of Axure though because it looks to be designed
primarily for prototyping, not for wireframing. I.e. its ideology is
to *implement* some functionality in the prototype rather than
*present & explain* it to the developers. Then the stuff that you have
implemented in the prototype is "self understood" and slips out of
attention, unless the developer clicks through all buttons and
interactions of the prototype, which is not a reliable method.

Are there other opinions about Axure? What is its catch?

Oleg.

30 May 2008 - 8:30am
Todd Warfel
2003

On May 30, 2008, at 9:02 AM, Oleg Krupnov wrote:

> Please explain what do you mean by patterns in this context.

I mean patterns in the traditional sense (e.g. Yahoo! pattern
library). Those common, repeatable, reusable components (or tiles)
that are present across multiple screens. You create a separate page
in your documentation for each one of them. You provide detailed
behavior notes for each pattern and the different states (if present).

When the reader comes to the screens that show the patterns, you don't
have to provide behavior notes for those patterns, as they've already
been provided earlier in the document. Instead, you can use that space
for behavior notes about how those different patterns interact with
each other, affect the screen, and/or for non-pattern items.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

30 May 2008 - 9:23am
Fred Beecher
2006

Hi Oleg,

On 5/30/08, Oleg Krupnov <oleg.krupnov at gmail.com> wrote:
>
>
> I am a little wary of Axure though because it looks to be designed
> primarily for prototyping, not for wireframing. I.e. its ideology is
> to *implement* some functionality in the prototype rather than
> *present & explain* it to the developers. Then the stuff that you have
> implemented in the prototype is "self understood" and slips out of
> attention, unless the developer clicks through all buttons and
> interactions of the prototype, which is not a reliable method.

I can definitely see why you'd think that, and to an extent it's true. From
my perspective, the actual way the prototype functions *is* part of the
documentation. I'm a fan of showing *in addition to* telling. That's one of
the major advantages of interactive prototyping for me. I'd never want to
just show *without* telling.

There are many ways I "tell" in Axure:

1. I use the Flow shapes to create navigation diagrams that are linked to
pages in the prototype.
2. I use the Page Notes section to talk about how the page is supposed to
work, what it's supposed to communicate, etc.
3. I create a separate document that details things like audience
characteristics (i.e. rough personas), high-level business requirements,
purpose of the site, etc. I then use this document as the "prefix" that gets
prepended to the specification when the printed documentation is generated.
4. You can generate prototypes that give users access to the annotations.
E.g., if you have a text field with annotations, in the generated prototype
you'll see a little note icon. Clicking on the icon will display all the
annotations for that object. (You can turn this feature on and off in the
Generate Prototype dialog... obviously you would not want this during a user
test.)

Are there other opinions about Axure? What is its catch?

It has a few:

1. It's not good for site mapping. So I still have to use Visio. *sigh*
2. No Mac version.
3. No way to trace business requirements to UI elements automatically. If
you need to do this, you have to do it manually.
4. No facility for quickly importing fake data. If you need to display a
lot of data in your prototype, you need to put it into pages or dynamic
panels yourself.
5. Specification generation options are limited, though Version 5 has
addressed this. I haven't played with that version too much yet. Yet!
6. There are a LOT of dialog boxes... that spawn other dialog boxes...
eek. The net result of this is that to do anything you end up doing a whole
lot of clicking.
7. You really have to learn its language... it's developer-centric in
some of its terminology.
8. It makes it possible to waste a lot of time if you make a big change
late in a project and have not set up your project appropriately to make
such changes a simple matter.

I guess that's more than a few. : ) But despite those catches, it allows me
to do what I need to do. Better.

- Fred

30 May 2008 - 11:14am
Oleg Krupnov
2008

Fred,

Thanks for your elaborate and seemingly impartial answer about Axure. You
make some good points.

There's a couple of things by the way I'd like ask you about:

Fred Beecher wrote:
>
> 3. No way to trace business requirements to UI elements automatically.
> If
> you need to do this, you have to do it manually.
>

Sounds like something I've been thinking about myself. Could you please shed
more light on what your business requirements look like and how you trace
them to the UI elements?

Fred Beecher wrote:
>
> 4. No facility for quickly importing fake data. If you need to display
> a
> lot of data in your prototype, you need to put it into pages or dynamic
> panels yourself.
>

I am just curious where designer folks usually take those data and in what
form.

Thanks!
--
View this message in context: http://www.nabble.com/Managing-Complexity-of-Wireframes-tp17532426p17562833.html
Sent from the ixda.org - discussion list mailing list archive at Nabble.com.

30 May 2008 - 12:41pm
Fred Beecher
2006

Hi Oleg,

On 5/30/08, Oleg Krupnov <oleg.krupnov at gmail.com> wrote:
>
>
> Sounds like something I've been thinking about myself. Could you please
> shed
> more light on what your business requirements look like and how you trace
> them to the UI elements?

In my organization, we have (among other practices) highly-skilled BAs and
UXDs. In situations in which we're dealing with very detailed business
requirements (new business processes, detailed technical interactions,
etc.), the BA on the project handles and documents all that stuff
independently of the UXD. We collaborate, of course, to keep aware of what
each other is doing.

Axure allows you to customize annotations to fit your needs. On my projects,
I always add a field called "Business Requirements." 90% of the time it's
just me filling out this annotation with directions to mask the field,
character limits, etc. But when there are more detailed requirements, I'll
get input from the BA and essentially paste the text they give me into the
field. Where appropriate, our documents reference each other, e.g., "For
details on this functionality, see the User Interface Design Document" or
"For details, see the Software Requirements Specification."

I have never found the need to trace specific requirements to specific UI
elements. If I did, I'd handle it by including a simplified list of the
requirements in the prefix document (that gets added to the beginning of the
spec) in which I textually indicate how the requirement is met in the UI. I
might also provide links to relevant sections of the spec, but that could
only happen after you generate it (which I recommend not doing until you've
completed, tested, and revised your prototype).

Also, I try to use masters whenever possible. Maybe 75% of each prototype I
create is composed of masters. This makes it real easy to change stuff if
business requirements change. Otherwise, you'd have to find each instance of
an object that references the requirement that has changed.

> 4. No facility for quickly importing fake data. If you need to display
>
> I am just curious where designer folks usually take those data and in what
> form.

What I do is develop the prototype test plan *BEFORE* I develop the
prototype. This way, I know the specific information that participants will
be looking for during the test, so I can just put it in at the start. Where
I get this data from is usually the client. I ask for example content and
integrate that into the prototype. If they've got an existing site, I often
just copy and paste from that.

I guess for me it's mainly content rather than data...

I got a tweet this morning from Dave Malouf with a link to his rant about
the suckage of MS Expression Suite in which he laments its inability to
integrate data... Dave, can you elaborate on this question?

Take care,
F.

30 May 2008 - 10:18am
Burak Özdelice
2008

hi,

is there any WEB based forum version of this mail list messages data?
because I cant't follow messages effectively via mail list system althought
i use a mail program.

thnx,
Burak
www.delizade.com

30 May 2008 - 5:49pm
erica
2008

Burak Delice wrote:
> is there any WEB based forum version of this mail list messages data?
> because I cant't follow messages effectively via mail list system
> althought i use a mail program.
Hi Burak,

You can indeed follow on a web version hosted by Nabble at
http://www.nabble.com/ixda.org---discussion-list-f6702.html

--

Cheers,
Erica
Technical Communicator, Budding User Experience Designer, Mama of Two Little Boys...
http://designingux.com

2 Jun 2008 - 7:33pm
Anonymous

Have you tried sorting your mail "by conversation" or "by thread"?
Alinta

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Burak Delice
Sent: Saturday, 31 May 2008 1:19 AM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] Managing Complexity of Wireframes

hi,

is there any WEB based forum version of this mail list messages data?
because I cant't follow messages effectively via mail list system
althought i use a mail program.

thnx,
Burak
www.delizade.com

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org Unsubscribe
................ http://www.ixda.org/unsubscribe List Guidelines
............ http://www.ixda.org/guidelines List Help ..................
http://www.ixda.org/help

Syndicate content Get the feed