What do these prototyping tools give me? (RE: Axure RP Pro prototyping tool)

10 May 2006 - 10:22pm
8 years ago
9 replies
1796 reads
Dave Malouf
2005

If people concede the point about these tools not working well as a
conversion prototype > word platform (which is what I'm hearing), and then
it is just about prototyping, then ... Why these tools?
What do they offer that another development environment doesn't? I mean
iRise and Serena have pretty heft licensing costs. That is pretty hard to
justify when I can great prototypes in Dreamweaver or Flash or Flex 2.0 or
the upcoming tools in the Expression Suite from MS, just as easily.

What am I missing here? Seriously, I'm about to head into a HUGE hosted
enterprise application re-design, and I'd really like to know what I'm
missing out on. I've looked at these tools, but a separate Wiki for
gathering requirements + Dreamweaver seem to be working fine. So I'm really
curious about this. $10k for a $5m project doesn't seem like a lot to ask
for, but it is still $10k .. But compare that to $5k for 5 licenses of
Studio 8 by Adobe, and I just don't see the cost benefit analysis. Help me!

Aspects that people didn't talk about are:
Maintainable objects
Sharing across teams, and within a team
Annotating (was sorta mentioned)
Converting prototypes to something consumable by other teams (Dev & QC jump
to mind).

I think Jay hit one requirement on the head and that is being able to create
data sets to be used for usability testing.

-- dave

Comments

11 May 2006 - 6:26am
Todd Warfel
2003

I think another thing that's missing is when these are appropriate.
For instance, in Dave's case if he's got 5 Designers that are
familiar w/Adobe and MM tools, then why switch to something like
Axure or iRise? There's the initial expense. Then the learning curve
and downtime (soft costs).

Who's going to use or consume the output? There's a mention of a
"free reader," but frankly, I don't want or need another free reader
and don't want to make our clients download a free reader. If it
isn't in something like PDF, HTML, SWF, or DOC, then I can't be
bothered with it.

From all that I've gathered so far, these are decent requirements
gathering tools, but you'd be better off prototyping on paper or with
Flash/HTML.

What about ongoing maintenance? Some of our projects have been
running for 1.5 years or more. There's been some changes. Maintenance
is a big issue for us.

On May 10, 2006, at 11:22 PM, David Heller wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> If people concede the point about these tools not working well as a
> conversion prototype > word platform (which is what I'm hearing),
> and then
> it is just about prototyping, then ... Why these tools?
> What do they offer that another development environment doesn't? I
> mean
> iRise and Serena have pretty heft licensing costs. That is pretty
> hard to
> justify when I can great prototypes in Dreamweaver or Flash or Flex
> 2.0 or
> the upcoming tools in the Expression Suite from MS, just as easily.
>
> What am I missing here? Seriously, I'm about to head into a HUGE
> hosted
> enterprise application re-design, and I'd really like to know what I'm
> missing out on. I've looked at these tools, but a separate Wiki for
> gathering requirements + Dreamweaver seem to be working fine. So
> I'm really
> curious about this. $10k for a $5m project doesn't seem like a lot
> to ask
> for, but it is still $10k .. But compare that to $5k for 5 licenses of
> Studio 8 by Adobe, and I just don't see the cost benefit analysis.
> Help me!
>
> Aspects that people didn't talk about are:
> Maintainable objects
> Sharing across teams, and within a team
> Annotating (was sorta mentioned)
> Converting prototypes to something consumable by other teams (Dev &
> QC jump
> to mind).
>
> I think Jay hit one requirement on the head and that is being able
> to create
> data sets to be used for usability testing.
>
> -- dave
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>
>

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | designing and usability consulting
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

13 May 2006 - 10:30pm
Jay Morgan
2006

[Long]
Dave & Todd,

What are you missing:
I think you're missing the environment in which the need for a tool like
this arises. Todd points at this with "when these are appropriate". When
and where. I don't know if you've ever worked in place where it's
relevant. Our company is a huge ecommerce retailer. We have projects that
support our ecommerce strategy, pet projects, maintenance needs,
multichannel projects, and a few large initiatives with outside vendors.
Our ecommerce team who works on these projects: We have 7 web project
managers, none of whom have web experience. (One of them has done technical
writing.) We have one user experience person who does functional specs,
wireframes, usability testing. We have one designer who has a background in
graphic design & advertising, but not web or interaction design. Our
company is a textbook case for iRise. We have so little definition,
conceptualization, and so many useless text documents, that we end up buried
in rework. We have a few more than nine managers, executives, and product
owners who want work done all the time.

Prototyping tool:
iRise has a 'server' (read, engine, as it's software) that sits on a
networked computer or an actual server. It has licenses for 'Studio' that
sit on the users' local machines. It has another 'Manager' piece for
requirements management. It has two ways for non-studio users to view it:
'Reader' is a license for internal people who will use it regularly;
and 'iDoc' is the free reader that let's people view it for free inside or
out of your company - onshore or off. Reader & iDoc let you view the entire
simulation and give feedback on it. Reader & iDoc simply present the
simulation in your browser. iDoc is also the name of the file that you send
out for others to view.

Maintainable objects:
The Studio has Scenarios, Pages, Templates (for pages), Masters (sorta
like templates for elements & objects), Decisions, and Datasheets. You
start by building scenarios in a whiteboard. Scenarios consist of Pages and
Decisions. Pages are built with elements - design elements, functional
elements, and data elements. Templates typically have design & functional
elements, usually in a specific array/layout. Masters are good for
functional elements, as you can reuse them on different templates.
Decisions help you make choices for navigation, user validation or
segmentation, calculations, and a few other things that depend on your
ability to imagine contingent relationships. Datasheets let you store,
access, update, delete records. Putting Decisions and Datasheets together
is where iRise really excels. That's where data elements come into play.
iDocs also become the currency for archiving and sharing objects with
others. For instance, like a developer could share lines of code in
NotePad, I can save Decisions & Datasheets that solve a particular problem
with another user.

Sharing & Annotating:
Studio users can share things via the server, shared projects, or by sending
someone a private project. Shared projects live on the shared server.
Private projects live on your local machine (with studio). Designers can
share projects with non-studio users by (clicking a button to) produce an
iDoc. The iDoc goes out by email (it's in the hundred KB range for big
simulations) or on shareable media or drives. The recipient opens the iDoc
in with either a Reader license or with the free download iDoc Reader. Just
to repeat an important point: The viewer goes through the simulation - the
whole simulation - with the iDoc. The iDoc has the simulation and the
document mentioned before. The viewer can make comments (a la PowerPoint or
Adobe Acrobat) in the Simulation or document.
[I laughed after reading: *If it isn't in something like PDF, HTML, SWF, or
DOC, then I can't be bothered with it. *Is it that four is your limit?
What about MP3, JPG, GIF, or EXE? How is not *something like* those, if
they're all extensions for filetypes?]
Special Example: For usability testing, we simply open the simulation in a
browser using a Reader license on the test machine. We run Morae to record
the test session.

Converting prototypes to something useful (by Dev & QC):
So, these are simulations (iRise dogma), not simply prototypes. One
potential distinction, we could build a simulation for a new checkout webapp
that works as the live site could, including data operations. A difference
in the recipient is that they have more technical prowess and interest than
some others. Does this simulation supply code? No. It does let them see
and use and do what you want the user to see and use and do. Maybe QC would
use it for forecasting or preliminary analysis, but not for rigorous
systems-based evaluations. (I don't know the role of your QC group. I'm
thinking about load-testing and running this on beta servers for extended
evaluation concurrent to other system changes and data pushes.)

Requirements gathering:
Maybe I don't understand what you use and need for requirements gathering.
For us, the requirements gathering method is heavy text documentation. That
doesn't work as well as prototypes. We noticed that iRise simulations work
far better than the text documents, and are faster, easier, better than the
prototypes we can build with current resource supply & demand.
Requirements "gathering" to me means 'figure out what to build, given what's
possible, what you're capable of, and how much time & money are on the
table'. It's not 'describe in detail what happens when user clicks
<widget>'.

Maintenance:
Maintaining iRise? Or, maintaining projects that take a long time?
Maintaining iRise is based on the basic question of maintaining any
prototyping tool. For example, how long will this company last? How many
updates will they make? What is their R&D budget? Do they listen to the
requests & comments I make. We evaluated those and chose iRise. Visio's
not going anywhere fast. Axure doesn't meet our needs for data transactions
and doesn't' intend to (based on their rep's comments at the time). Serena
wants to sell us other stuff, tells us we shouldn't use the tool to do
certain things with data, and didn't want to discuss future development with
us. It'd take me longer to learn Adobe/MM tools to the desired level of
proficiency than it would take me to learn iRise.
Maintaining projects begs the question that you'd be working on this
project as long with iRise as you have with your current tools. Ha! Sorry,
it was open, had to take it. It actually isn't clear to me if the project
you mention suffers from scope creep, poor conceptual framework, or you mean
it's a system that needs long term maintenance. If it's scope creep or poor
concepts, then iRise could help you by letting you work things out in more
detail and faster. If it's a system you're maintaining, then I think of
something like using the Templates & Masters I mentioned earlier. Those can
be saved and reused across projects. For instance, I can just as easily
save a set of Templates in an iDoc and send them to a colleague, as I can
save a full simulation. Also, projects can be archived - both private and
shared - for later use.

I hope this helps clear things up. If I see you at another summit or
conference, I'm happy to show it to you.
Jay

On 5/11/06, Todd Warfel <lists at toddwarfel.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> I think another thing that's missing is when these are appropriate.
> For instance, in Dave's case if he's got 5 Designers that are
> familiar w/Adobe and MM tools, then why switch to something like
> Axure or iRise? There's the initial expense. Then the learning curve
> and downtime (soft costs).
>
> Who's going to use or consume the output? There's a mention of a
> "free reader," but frankly, I don't want or need another free reader
> and don't want to make our clients download a free reader. If it
> isn't in something like PDF, HTML, SWF, or DOC, then I can't be
> bothered with it.
>
> From all that I've gathered so far, these are decent requirements
> gathering tools, but you'd be better off prototyping on paper or with
> Flash/HTML.
>
> What about ongoing maintenance? Some of our projects have been
> running for 1.5 years or more. There's been some changes. Maintenance
> is a big issue for us.
>
> On May 10, 2006, at 11:22 PM, David Heller wrote:
>
> > [Please voluntarily trim replies to include only relevant quoted
> > material.]
> >
> > If people concede the point about these tools not working well as a
> > conversion prototype > word platform (which is what I'm hearing),
> > and then
> > it is just about prototyping, then ... Why these tools?
> > What do they offer that another development environment doesn't? I
> > mean
> > iRise and Serena have pretty heft licensing costs. That is pretty
> > hard to
> > justify when I can great prototypes in Dreamweaver or Flash or Flex
> > 2.0 or
> > the upcoming tools in the Expression Suite from MS, just as easily.
> >
> > What am I missing here? Seriously, I'm about to head into a HUGE
> > hosted
> > enterprise application re-design, and I'd really like to know what I'm
> > missing out on. I've looked at these tools, but a separate Wiki for
> > gathering requirements + Dreamweaver seem to be working fine. So
> > I'm really
> > curious about this. $10k for a $5m project doesn't seem like a lot
> > to ask
> > for, but it is still $10k .. But compare that to $5k for 5 licenses of
> > Studio 8 by Adobe, and I just don't see the cost benefit analysis.
> > Help me!
> >
> > Aspects that people didn't talk about are:
> > Maintainable objects
> > Sharing across teams, and within a team
> > Annotating (was sorta mentioned)
> > Converting prototypes to something consumable by other teams (Dev &
> > QC jump
> > to mind).
> >
> > I think Jay hit one requirement on the head and that is being able
> > to create
> > data sets to be used for usability testing.
> >
> > -- dave
> >
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://listguide.ixda.org/
> > List Help .................. http://listhelp.ixda.org/
> > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists at ixda.org
> > Home ....................... http://ixda.org/
> > Resource Library ........... http://resources.ixda.org
> >
> >
>
>
> Cheers!
>
> Todd R. Warfel
> Partner, Design & Usability Specialist
> Messagefirst | designing and usability consulting
> --------------------------------------
> Contact Info
> Voice: (607) 339-9640
> Email: todd at messagefirst.com
> AIM: twarfel at mac.com
> Blog: http://toddwarfel.com
> --------------------------------------
> 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 at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
_________________________________
Jay A. Morgan
jayamorgan at gmail.com

14 May 2006 - 12:29am
Robert Hoekman, Jr.
2005

The question of maintenance is interesting.

In my case, using Axure, when I wireframe and/or protoype something
for the first time for an app that already exists, I take screenshots
of the app and plug them into a new Axure doc. I make modifications as
needed, export the new JPGs or prototype (with annotations) and hand
those off for review and/or implementation. When it's a new app, I
create the interface from scratch or from pieces of other apps (we
have a lot of apps that share common UI elements) and go from there.

Every time a new feature is implemented or a new app is created, I'm
the guy who does the design work for it. For existing apps, I just
update the original Axure doc and make new deliverables.

What's tough about maintenance in your environment?

-r-

On 5/11/06, Todd Warfel <lists at toddwarfel.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> I think another thing that's missing is when these are appropriate.
> For instance, in Dave's case if he's got 5 Designers that are
> familiar w/Adobe and MM tools, then why switch to something like
> Axure or iRise? There's the initial expense. Then the learning curve
> and downtime (soft costs).
>
> Who's going to use or consume the output? There's a mention of a
> "free reader," but frankly, I don't want or need another free reader
> and don't want to make our clients download a free reader. If it
> isn't in something like PDF, HTML, SWF, or DOC, then I can't be
> bothered with it.
>
> From all that I've gathered so far, these are decent requirements
> gathering tools, but you'd be better off prototyping on paper or with
> Flash/HTML.
>
> What about ongoing maintenance? Some of our projects have been
> running for 1.5 years or more. There's been some changes. Maintenance
> is a big issue for us.
>
> On May 10, 2006, at 11:22 PM, David Heller wrote:
>
> > [Please voluntarily trim replies to include only relevant quoted
> > material.]
> >
> > If people concede the point about these tools not working well as a
> > conversion prototype > word platform (which is what I'm hearing),
> > and then
> > it is just about prototyping, then ... Why these tools?
> > What do they offer that another development environment doesn't? I
> > mean
> > iRise and Serena have pretty heft licensing costs. That is pretty
> > hard to
> > justify when I can great prototypes in Dreamweaver or Flash or Flex
> > 2.0 or
> > the upcoming tools in the Expression Suite from MS, just as easily.
> >
> > What am I missing here? Seriously, I'm about to head into a HUGE
> > hosted
> > enterprise application re-design, and I'd really like to know what I'm
> > missing out on. I've looked at these tools, but a separate Wiki for
> > gathering requirements + Dreamweaver seem to be working fine. So
> > I'm really
> > curious about this. $10k for a $5m project doesn't seem like a lot
> > to ask
> > for, but it is still $10k .. But compare that to $5k for 5 licenses of
> > Studio 8 by Adobe, and I just don't see the cost benefit analysis.
> > Help me!
> >
> > Aspects that people didn't talk about are:
> > Maintainable objects
> > Sharing across teams, and within a team
> > Annotating (was sorta mentioned)
> > Converting prototypes to something consumable by other teams (Dev &
> > QC jump
> > to mind).
> >
> > I think Jay hit one requirement on the head and that is being able
> > to create
> > data sets to be used for usability testing.
> >
> > -- dave
> >
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://listguide.ixda.org/
> > List Help .................. http://listhelp.ixda.org/
> > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists at ixda.org
> > Home ....................... http://ixda.org/
> > Resource Library ........... http://resources.ixda.org
> >
> >
>
>
> Cheers!
>
> Todd R. Warfel
> Partner, Design & Usability Specialist
> Messagefirst | designing and usability consulting
> --------------------------------------
> Contact Info
> Voice: (607) 339-9640
> Email: todd at messagefirst.com
> AIM: twarfel at mac.com
> Blog: http://toddwarfel.com
> --------------------------------------
> 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 at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

14 May 2006 - 5:36pm
Todd Warfel
2003

Jay,

So, I'm reading your response, or started to and then started
thinking... "If it takes three particularly large paragraphs to
describe what this thing does, then it's too complicated." Powerful ­
complicated.

I'm dreaming of the day when we can have a powerful tool that
provides prototyping, annotated behaviors and is maintainable that
doesn't take this much work to describe.

Granted, I've never used iRise, but from what I've read and gathered
from those who have used it, it seems like there has to be a better,
simpler method. Perhaps it hasn't been invented yet. And that's fine,
cause I love those kind of challenges ;).

On May 13, 2006, at 11:30 PM, Jay Morgan wrote:

> Prototyping tool:
> iRise has a 'server' (read, engine, as it's software) that sits on a
> networked computer or an actual server. It has licenses for
> 'Studio' that
> sit on the users' local machines. It has another 'Manager' piece for
> requirements management. It has two ways for non-studio users to
> view it:
> 'Reader' is a license for internal people who will use it regularly;
> and 'iDoc' is the free reader that let's people view it for free
> inside or
> out of your company - onshore or off. Reader & iDoc let you view
> the entire
> simulation and give feedback on it. Reader & iDoc simply present the
> simulation in your browser. iDoc is also the name of the file that
> you send
> out for others to view.
>
> Maintainable objects:
> The Studio has Scenarios, Pages, Templates (for pages), Masters (sorta
> like templates for elements & objects), Decisions, and Datasheets.
> You
> start by building scenarios in a whiteboard. Scenarios consist of
> Pages and
> Decisions. Pages are built with elements - design elements,
> functional
> elements, and data elements. Templates typically have design &
> functional
> elements, usually in a specific array/layout. Masters are good for
> functional elements, as you can reuse them on different templates.
> Decisions help you make choices for navigation, user validation or
> segmentation, calculations, and a few other things that depend on your
> ability to imagine contingent relationships. Datasheets let you
> store,
> access, update, delete records. Putting Decisions and Datasheets
> together
> is where iRise really excels. That's where data elements come into
> play.
> iDocs also become the currency for archiving and sharing objects with
> others. For instance, like a developer could share lines of code in
> NotePad, I can save Decisions & Datasheets that solve a particular
> problem
> with another user.
>
> Sharing & Annotating:
> Studio users can share things via the server, shared projects, or
> by sending
> someone a private project. Shared projects live on the shared server.
> Private projects live on your local machine (with studio).
> Designers can
> share projects with non-studio users by (clicking a button to)
> produce an
> iDoc. The iDoc goes out by email (it's in the hundred KB range for
> big
> simulations) or on shareable media or drives. The recipient opens
> the iDoc
> in with either a Reader license or with the free download iDoc
> Reader. Just
> to repeat an important point: The viewer goes through the
> simulation - the
> whole simulation - with the iDoc. The iDoc has the simulation and the
> document mentioned before. The viewer can make comments (a la
> PowerPoint or
> Adobe Acrobat) in the Simulation or document.
> [I laughed after reading: *If it isn't in something like PDF, HTML,
> SWF, or
> DOC, then I can't be bothered with it. *Is it that four is your
> limit?
> What about MP3, JPG, GIF, or EXE? How is not *something like*
> those, if
> they're all extensions for filetypes?]
> Special Example: For usability testing, we simply open the
> simulation in a
> browser using a Reader license on the test machine. We run Morae
> to record
> the test session.

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | designing and usability consulting
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

14 May 2006 - 5:46pm
Todd Warfel
2003

On May 13, 2006, at 11:30 PM, Jay Morgan wrote:

> [I laughed after reading: *If it isn't in something like PDF, HTML,
> SWF, or DOC, then I can't be bothered with it. *Is it that four is
> your limit? What about MP3, JPG, GIF, or EXE? How is not
> *something like* those, if they're all extensions for filetypes?]
> Special Example: For usability testing, we simply open the
> simulation in a browser using a Reader license on the test
> machine. We run Morae to record the test session.

Why those four? Well, we don't have any clients who don't have a web
browser. We don't have any clients who can't read a Word document (we
do have a Web 2.0 client who is Linux-based and uses OpenOffice. They
use OpenDoc internally, but pass things as .doc to externals like
us). We don't have a single client who doesn't have Adobe's Acrobat
Reader or the Flash plug-in.

See, the biggest difference is that all of our clients and the people
we interact with already have these tools. As for JPG and GIF, well,
those are assumed with HTML. We don't deliver images by themselves.
We deliver images w/notes, which typically means a PDF. They already
have these. I don't have a reason to tell them to download another
plug-in, and quite frankly don't want to when there's already
existing "standards" out there that we're all already using.

And nope, .exe won't work. See, we're a Mac shop and many of our
clients work in a mixed environment. So, a .exe is rather worthless
to us ;). And an .mp3? Well, not likely. We'll deliver a DVD with our
usability vignettes. We may incorporate screens with audio, but that
would be delivered as a .swf typically. Last time I checked, .mp3 was
just audio ;).

Seriously, though. When we're evaluating a tool, or help our clients
evaluate tools, one of the biggest criteria is "Will it work w/our
existing environment?" And it doesn't sound like iRise will.

Case in point. We have a client who has another vendor using Test
Director for keeping track of bugs. That's a big problem, because TD
only works on Win/IE (there's a plug-in for Win/Firefox, but it
blows). So, every time we want to look at one of the bugs, or
respond, we have to fire up Win/IE to do it. Major hassle. Their
internal designers don't even use it, because they can't be bothered
with using a web-based app that won't work on Mac. And there's
nothing TD does that really needs ActiveX. It's just a case of poor
planning and implementation.

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | designing and usability consulting
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

14 May 2006 - 5:53pm
Todd Warfel
2003

On May 13, 2006, at 11:30 PM, Jay Morgan wrote:

> Maintaining projects begs the question that you'd be working on
> this project as long with iRise as you have with your current
> tools. Ha! Sorry, it was open, had to take it.

Cute, Jay.

> It actually isn't clear to me if the project you mention suffers
> from scope creep, poor conceptual framework, or you mean
> it's a system that needs long term maintenance. If it's scope
> creep or poor concepts, then iRise could help you by letting you
> work things out in more detail and faster.

Not the case. It's called, deliver then do the next iteration. So,
we're on v3.0 now. It's the third release in 18 months. Deliver early
and often, I think it's called ;).

> If it's a system you're maintaining, then I think of something like
> using the Templates & Masters I mentioned earlier. Those can
> be saved and reused across projects. For instance, I can just as
> easily save a set of Templates in an iDoc and send them to a
> colleague, as I can save a full simulation. Also, projects can be
> archived - both private and shared - for later use.

We're using InDesign and Illustrator. We have a template system w/
multiple master pages. Each element on the master can be individually
edited on the screen w/o destruction of the original on the master if
desired (e.g. you have a placement object for "Page Title," but on
the individual screen, you edit it to "My Account Preferences" w/o
destruction of the "Page Title" on the master.).

We also implement a pattern library, which is recycled, when
appropriate, across projects.

> I hope this helps clear things up. If I see you at another summit
> or conference, I'm happy to show it to you.
> Jay

Clear as mud. Again, seriously, I'd love to see it in action next
time we're at the same place. For now, it just seems like there are
better ways, or they need to make some changes to iRise to make it
work for us. And I'm still waiting for, and working on a proper IA
tool that doesn't have the disadvantages of iRise and Axure.

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | designing and usability consulting
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

14 May 2006 - 6:01pm
Todd Warfel
2003

On May 14, 2006, at 1:29 AM, Robert Hoekman, Jr. wrote:
> What's tough about maintenance in your environment?

This is one of the biggest conversations we've had over and over
again w/other industry vets.

First, we rarely work on one-off projects. Typically, we'll get
called in for a one-off, or quick fix, which leads to ongoing
production of future releases. And since they're fairly large
projects, it's inevitable that somewhere along the line, some
changes. A deal falls through w/a third party provider and a feature
has to be cut, which impacts the entire product. Or IT finds out they
can't do something they thought they could, so it slips and we go to
Plan B.

You make a change. How is that change communicated to those who are
consumers of the artifact (e.g. visual designers and development
team)? How do you track that? How often are you updating the releases?

For us, we release almost weekly. So, it's not unusual that our teams
need to know what the changes have been in the last 2-3 releases
(they're not always developing as fast as we're releasing updates to
the interactions).

We've actually taken the time to sit down with the visual designers
and developers to see how they're (trying) to use the various
artifacts. We've noticed a few things (like they keep the last 2-3
releases at their desk w/notes on them). So, we've implemented a
version history that keeps track of the last 3 versions with the most
recent changes hi-lighted.

We also maintain a document index - not a TOC. A toc is just a list
of headings w/page numbers. Ours is more useful. We have the
functional area (e.g. patterns, home, products, preferences), the
figure number (each illustration has a fig #), the page number and a
detailed description of what each item is. You don't get that in a
TOC. And we've done some testing and observation and noticed that
both in person and over the phone, it's increased productivity and
efficiency of using the wireframe decks several 100%. It's not
unusual that trying to find a screen in an 80 page deck took 2-3
minutes of shuffling around. Now, it's typically found in a matter of
10-15 seconds.

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | designing and usability consulting
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

14 May 2006 - 7:31pm
Dave Malouf
2005

I was wondering if people can speak to using these more formal tools in a
more agile environment?

-- dave

David (Heller) Malouf
http://synapticburn.com/
http://ixdg.org/
dave (at) ixdg (dot) org
dave (at) synapticburn (dot) com
AIM: bolinhanyc || Y!: dave_ux || MSN: hippiefunk(at)hotmail.com || GTalk:
dave.ixd(at)gmail.com

14 May 2006 - 9:34pm
Jay Morgan
2006

Thanks for the thorough responses to the thorough description.
What's good about iRise, which is true of most tools, is that I don't have
to describe it every time i use it. So, this protracted discussion is
another case for why we work in context, rather than in text, so to speak.

See, I thought that I'd be working in a place like you described. Then, I
woke up where I am now. It's ugly most days. iRise makes a huge
difference. (You could even say that clear as mud is an improvement for
us.)

During our reference calls, we talked to other companies who use iRise. All
of them use it for the multi-version system support you mentioned, which is
something I will be using it for, too. The references had staff that can
work a lot like you and Dave can. The major cases for iRise in their
already-productive environments were standardizing work formats among
different UX teams, and that completing these projects in iRise was faster
than with standard tools. Two of the teams tracked projects in the hands of
different teams, comparing who was faster with iRise, and how iRise compared
to the other tools. Both companies said iRise sped up delivery (as in,
start to release of product) by 60 and 66%. It's looking higher than that
for us.

I will now go an entire week without discussing or mentioning iRise.
take care,
Jay

On 5/14/06, Todd Warfel <lists at toddwarfel.com> wrote:
>
>
> On May 13, 2006, at 11:30 PM, Jay Morgan wrote:
>
> Maintaining projects begs the question that you'd be working on this project
> as long with iRise as you have with your current tools. Ha! Sorry, it
> was open, had to take it.
>
>
>
> Cute, Jay.
>
> It actually isn't clear to me if the project you mention suffers from
> scope creep, poor conceptual framework, or you mean
>
> it's a system that needs long term maintenance. If it's scope creep or
> poor concepts, then iRise could help you by letting you work things out in
> more detail and faster.
>
>
>
> Not the case. It's called, deliver then do the next iteration. So, we're
> on v3.0 now. It's the third release in 18 months. Deliver early and often,
> I think it's called ;).
>
> If it's a system you're maintaining, then I think of something like using
> the Templates & Masters I mentioned earlier. Those can
>
> be saved and reused across projects. For instance, I can just as easily save
> a set of Templates in an iDoc and send them to a colleague, as I can save
> a full simulation. Also, projects can be archived - both private and shared
> - for later use.
>
>
>
> We're using InDesign and Illustrator. We have a template system w/multiple
> master pages. Each element on the master can be individually edited on the
> screen w/o destruction of the original on the master if desired (e.g. you
> have a placement object for "Page Title," but on the individual screen, you
> edit it to "My Account Preferences" w/o destruction of the "Page Title" on
> the master.).
>
>
> We also implement a pattern library, which is recycled, when appropriate,
> across projects.
>
>
>
> I hope this helps clear things up. If I see you at another summit or conference,
> I'm happy to show it to you.
>
> Jay
>
>
>
> Clear as mud. Again, seriously, I'd love to see it in action next time
> we're at the same place. For now, it just seems like there are better ways,
> or they need to make some changes to iRise to make it work for us. And I'm
> still waiting for, and working on a proper IA tool that doesn't have the
> disadvantages of iRise and Axure.
>
>
>
> Cheers!
>
> Todd R. Warfel
> Partner, Design & Usability Specialist
> Messagefirst | designing and usability consulting
> --------------------------------------
> *Contact Info*
> Voice: (607) 339-9640 Email: todd at messagefirst.com
> AIM: twarfel at mac.com
> Blog: http://toddwarfel.com
> --------------------------------------
> In theory, theory and practice are the same.
> In practice, they are not.
>
>
>

--
_________________________________
Jay A. Morgan
jayamorgan at gmail.com

Syndicate content Get the feed