|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
|
|
Managing Complexity of WireframesI'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! |
|
|
Re: Managing Complexity of WireframesOleg,
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 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesHello 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@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesOleg,
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@...>: > > 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@... 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 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesThanks 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@...> 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@...>: >> >> 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@... > > 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 Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesOleg,
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@...>: > 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? > > Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesAnd 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@...> 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@...>: >> >> 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? >> > Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesOleg "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 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesOleg,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@...> 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@... > 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 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of Wireframes1. 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@... AIM: twarfel@... Blog: http://toddwarfel.com Twitter: zakiwarfel ---------------------------------- In theory, theory and practice are the same. In practice, they are not. ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesTo elaborate on how Axure can help with this...
On 5/30/08, Dan Brown <brownorama@...> 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. ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesThanks Todd,
Please explain what do you mean by patterns in this context. Oleg. ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesGuru,
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@... > Unsubscribe ................ http://www.ixda.org/unsubscribe > List Guidelines ............ http://www.ixda.org/guidelines > List Help .................. http://www.ixda.org/help ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesThanks 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. ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesOn 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@... AIM: twarfel@... Blog: http://toddwarfel.com Twitter: zakiwarfel ---------------------------------- In theory, theory and practice are the same. In practice, they are not. ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesHi Oleg,
On 5/30/08, Oleg Krupnov <oleg.krupnov@...> 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 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of Wireframeshi,
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@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesFred,
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: 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? I am just curious where designer folks usually take those data and in what form. Thanks! |
|
|
Re: Managing Complexity of WireframesHi Oleg,
On 5/30/08, Oleg Krupnov <oleg.krupnov@...> 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. ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
|
|
Re: Managing Complexity of WireframesBurak 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 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... discuss@... Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |