Prototyping Drag and Drop

26 Apr 2007 - 9:40am
7 years ago
22 replies
1549 reads
Mitchell Gass
2004

I'm curious what people are doing to prototype drag and drop
interactions. Do any of the currently available prototyping tools,
such iRise and Axure, provide drag and drop? Is using HTML and
JavaScript the best option? Is Scriptaculous

http://script.aculo.us/

worth a look?

Thanks!

Mitchell Gass
uLab | PDA: Learning from Users | Designing with Users
Berkeley, CA 94707 USA
+1 510 525-6864 office
+1 415 637-6552 mobile
+1 510 525-4246 fax
http://www.participatorydesign.com/

Comments

26 Apr 2007 - 9:46am
russwilson
2005

I use Flash/Flex (and now Apollo).

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Mitchell Gass
Sent: Thursday, April 26, 2007 9:41 AM
To: discuss at ixda.org
Subject: [IxDA Discuss] Prototyping Drag and Drop

I'm curious what people are doing to prototype drag and drop
interactions. Do any of the currently available prototyping tools,
such iRise and Axure, provide drag and drop? Is using HTML and
JavaScript the best option? Is Scriptaculous

http://script.aculo.us/

worth a look?

Thanks!

Mitchell Gass
uLab | PDA: Learning from Users | Designing with Users
Berkeley, CA 94707 USA
+1 510 525-6864 office
+1 415 637-6552 mobile
+1 510 525-4246 fax
http://www.participatorydesign.com/

________________________________________________________________
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

26 Apr 2007 - 10:37am
.pauric
2006

re: scriptaculous. Unless I'm mistaken, which happens more often than
not these days... you need the backend (RoR) for the prototype to
function with any sort of interactivity.

Otherwise things spring back to their original placement.

26 Apr 2007 - 10:48am
jstrande
2007

I've been doing a LOT of JavaScript lately to demonstrate interactivity. It
has drawbacks:

1.) longer prototyping cycles
2.) loss of state if you browse away from the page
3.) Etc.

Despite the drawbacks, you really can't beat the demonstration capability of
showing what happens on the page when people are clicking links. Also, there
is less ambiguity when the design is handed over to developers. I think it's
worth the time!

BTW: We use Dojo for a JS library. It's nice, but sparse documentation.

Jon

P.S. Pauric, no backend is required with JavaScript.

On 4/26/07, pauric <radiorental at gmail.com> wrote:
>
> re: scriptaculous. Unless I'm mistaken, which happens more often than
> not these days... you need the backend (RoR) for the prototype to
> function with any sort of interactivity.
>
> Otherwise things spring back to their original placement.
> ________________________________________________________________
> 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
>

26 Apr 2007 - 11:12am
.pauric
2006

Jon "P.S. Pauric, no backend is required with JavaScript. "

Very true, but I think in this case where states need to be changed within a
page, its not possible in js alone.
e.g. <http://demo.script.aculo.us/shop>

Granted I'm a clueless chuck when it comes to code, but I havent been able
to get the droppables to stick without a write.

If its possible I'll pay to know how - thanks!

On 4/26/07, Jon Strande <jstrande at gmail.com> wrote:
>
> I've been doing a LOT of JavaScript lately to demonstrate interactivity.
> It has drawbacks:
>
> 1.) longer prototyping cycles
> 2.) loss of state if you browse away from the page
> 3.) Etc.
>
> Despite the drawbacks, you really can't beat the demonstration capability
> of showing what happens on the page when people are clicking links. Also,
> there is less ambiguity when the design is handed over to developers. I
> think it's worth the time!
>
> BTW: We use Dojo for a JS library. It's nice, but sparse documentation.
>
> Jon
>
> P.S. Pauric, no backend is required with JavaScript.
>
>
> On 4/26/07, pauric <radiorental at gmail.com> wrote:
>
> > re: scriptaculous. Unless I'm mistaken, which happens more often than
> > not these days... you need the backend (RoR) for the prototype to
> > function with any sort of interactivity.
> >
> > Otherwise things spring back to their original placement.
> > ________________________________________________________________
> > 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
> >
>
>

26 Apr 2007 - 11:19am
jstrande
2007

Pauric,

Yeah, you are correct - you can't easily save state without a backend server
call.

The only way to really do it on the client is by using cookies... which I
have done for demonstration purposes. Not great, but it does work. ;-)

Jon

On 4/26/07, pauric <radiorental at gmail.com> wrote:
>
> Jon "P.S. Pauric, no backend is required with JavaScript. "
>
> Very true, but I think in this case where states need to be changed within
> a
> page, its not possible in js alone.
> e.g. <http://demo.script.aculo.us/shop>
>
> Granted I'm a clueless chuck when it comes to code, but I havent been able
> to get the droppables to stick without a write.
>
> If its possible I'll pay to know how - thanks!
>
> On 4/26/07, Jon Strande <jstrande at gmail.com> wrote:
> >
> > I've been doing a LOT of JavaScript lately to demonstrate interactivity.
> > It has drawbacks:
> >
> > 1.) longer prototyping cycles
> > 2.) loss of state if you browse away from the page
> > 3.) Etc.
> >
> > Despite the drawbacks, you really can't beat the demonstration
> capability
> > of showing what happens on the page when people are clicking links.
> Also,
> > there is less ambiguity when the design is handed over to developers. I
> > think it's worth the time!
> >
> > BTW: We use Dojo for a JS library. It's nice, but sparse documentation.
> >
> > Jon
> >
> > P.S. Pauric, no backend is required with JavaScript.
> >
> >
> > On 4/26/07, pauric <radiorental at gmail.com> wrote:
> >
> > > re: scriptaculous. Unless I'm mistaken, which happens more often than
> > > not these days... you need the backend (RoR) for the prototype to
> > > function with any sort of interactivity.
> > >
> > > Otherwise things spring back to their original placement.
> > > ________________________________________________________________
> > > 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
> > >
> >
> >
> ________________________________________________________________
> 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
>

26 Apr 2007 - 11:40am
Eric DeLabar
2007

We regularly use Script.aculo.us to prototype drag-and-drop interactions; we
don't use a back-end, so it is stateless, but it usually does enough to
demonstrate the interaction to a client.

Script.aculo.us has a nice, more-or-less pre-built, drag-and-drop feature
called "sortables." With a little practice you can make a nice demo of some
pretty advanced features in an hour or so.

Eric DeLabar
System Architect
Trifecta Technologies, Inc.
http://www.trifecta.com

On 4/26/07, Jon Strande <jstrande at gmail.com> wrote:
>
> Pauric,
>
> Yeah, you are correct - you can't easily save state without a backend
> server
> call.
>
> The only way to really do it on the client is by using cookies... which I
> have done for demonstration purposes. Not great, but it does work. ;-)
>
> Jon
>
> On 4/26/07, pauric <radiorental at gmail.com> wrote:
> >
> > Jon "P.S. Pauric, no backend is required with JavaScript. "
> >
> > Very true, but I think in this case where states need to be changed
> within
> > a
> > page, its not possible in js alone.
> > e.g. <http://demo.script.aculo.us/shop>
> >
> > Granted I'm a clueless chuck when it comes to code, but I havent been
> able
> > to get the droppables to stick without a write.
> >
> > If its possible I'll pay to know how - thanks!
> >
> > On 4/26/07, Jon Strande <jstrande at gmail.com> wrote:
> > >
> > > I've been doing a LOT of JavaScript lately to demonstrate
> interactivity.
> > > It has drawbacks:
> > >
> > > 1.) longer prototyping cycles
> > > 2.) loss of state if you browse away from the page
> > > 3.) Etc.
> > >
> > > Despite the drawbacks, you really can't beat the demonstration
> > capability
> > > of showing what happens on the page when people are clicking links.
> > Also,
> > > there is less ambiguity when the design is handed over to developers.
> I
> > > think it's worth the time!
> > >
> > > BTW: We use Dojo for a JS library. It's nice, but sparse
> documentation.
> > >
> > > Jon
> > >
> > > P.S. Pauric, no backend is required with JavaScript.
> > >
> > >
> > > On 4/26/07, pauric <radiorental at gmail.com> wrote:
> > >
> > > > re: scriptaculous. Unless I'm mistaken, which happens more often
> than
> > > > not these days... you need the backend (RoR) for the prototype to
> > > > function with any sort of interactivity.
> > > >
> > > > Otherwise things spring back to their original placement.
> > > > ________________________________________________________________
> > > > 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
> > > >
> > >
> > >
> > ________________________________________________________________
> > 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
> >
> ________________________________________________________________
> 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
>

26 Apr 2007 - 12:46pm
Sean Voisen
2006

On Apr 26, 2007, at 7:40 AM, Mitchell Gass wrote:

> I'm curious what people are doing to prototype drag and drop
> interactions.

I like using Flash, or better yet, Flex. Prototyping drag and drop in
FlexBuilder, even using the visual design mode, can be done very
quickly and easily.

Sean Voisen
Interaction Design Technologist
http://seanvoisen.com

26 Apr 2007 - 1:24pm
Henrik Olsen
2006

Try paper. It does all kinds of fancy stuff. Very powerful and the
most flexible and capable prototyping tool on the market. ;)

Henrik Olsen
www.guuui.com - The Interaction Designer's Coffee Break

On 4/26/07, Mitchell Gass <mitchell at participatorydesign.com> wrote:
> I'm curious what people are doing to prototype drag and drop
> interactions. Do any of the currently available prototyping tools,
> such iRise and Axure, provide drag and drop? Is using HTML and
> JavaScript the best option? Is Scriptaculous

26 Apr 2007 - 1:36pm
russwilson
2005

Except for interactivity... Unless you wave the paper around... :-)

----- Original Message -----
From: discuss-bounces at lists.interactiondesigners.com <discuss-bounces at lists.interactiondesigners.com>
To: discuss at ixda.org <discuss at ixda.org>
Sent: Thu Apr 26 13:24:49 2007
Subject: Re: [IxDA Discuss] Prototyping Drag and Drop

Try paper. It does all kinds of fancy stuff. Very powerful and the
most flexible and capable prototyping tool on the market. ;)

Henrik Olsen
www.guuui.com - The Interaction Designer's Coffee Break

On 4/26/07, Mitchell Gass <mitchell at participatorydesign.com> wrote:
> I'm curious what people are doing to prototype drag and drop
> interactions. Do any of the currently available prototyping tools,
> such iRise and Axure, provide drag and drop? Is using HTML and
> JavaScript the best option? Is Scriptaculous
________________________________________________________________
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

26 Apr 2007 - 1:52pm
Todd Warfel
2003

Ah, the naivety. Well, young grasshopper, you'd be surprised at what
kind of interactivity you can get with paper. Let's see...

I've prototyped a voice mail player that has a working scrubber with
paper. You simply cut a slit for the scrubber, attach it to a piece
of flat dental tape, and when the person presses play, you play a
voicemail from an iPod w/speakers and drag the scrubber across the
player w/the dental tape. The participants were so enamored, many of
the hit the rewind button and played it again.

I've simulated scrolling a window by having the window cut out of a
piece of poster board. Print the screens on 11x17, which allows some
overhang on the right side, which extends past the browser window's
right side. Let the participants slide the "content window" up and
down by grabbing the extended paper on the right side. Works like a
charm (just did this last week).

I've done drag and drop with placing tiles on a screen with some
double sided sticky tape on the back. They can pick them up and move
them around. Warning, use index cards for this, as paper tears much
easier.

I've done scrolling text boxes. Cut a slit in the paper. Place the
index card with a string attached to the back behind it. When the
participant scrolls, pull the index card up behind it.

Oh, how what about an AJAX update to a widget after sign-in? Say,
they have a particular content area that's general when non-
authenticated, and provides personalized content when authenticated.
No problem. Use the same method as the index card above. Have the
AJAXified screen as the base. Cut slits for the non-authenticated
tile. Slide the non-authenticated model through the slits. Once the
participant signs in, pull the non-authenticated tile up, revealing
the AJAXified model underneath - viola.

Now, about that waving paper around stuff.... :).

(this is good stuff... should make it's way into my book - shameless
plug:) )

On Apr 26, 2007, at 2:36 PM, Wilson, Russell wrote:

> Except for interactivity... Unless you wave the paper around... :-)
>
> ----- Original Message -----
> From: discuss-bounces at lists.interactiondesigners.com <discuss-
> bounces at lists.interactiondesigners.com>
> To: discuss at ixda.org <discuss at ixda.org>
> Sent: Thu Apr 26 13:24:49 2007
> Subject: Re: [IxDA Discuss] Prototyping Drag and Drop
>
> Try paper. It does all kinds of fancy stuff. Very powerful and the
> most flexible and capable prototyping tool on the market. ;)
>
> Henrik Olsen
> www.guuui.com - The Interaction Designer's Coffee Break

Cheers!

Todd Zaki Warfel
Partner, Design & Usability Specialist
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
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.

26 Apr 2007 - 2:23pm
Dave Malouf
2005

I definitely appreciate the paper prototyping people's zeal for the
method. It is cheap and quick and definitely seems to work for those
that use it.

I have even taken Todd's very good workshop on paper-prototyping.

For me though and I would imagine others who don't "like" paper
prototyping, it feels like too much of an abstraction from real
interaction with software for me to like to use it. I know it will get
me some results, but for barely any more investment I can do HTML or
Flash at the same level of fidelity + I get to use the REAL I/O
materials that my users will encounter and test them with.

But I imagine very much so that there is a lot about preference, and
ability to suspend disbelief in both prototype creator and tester a
like. I just can't get past the human as machine aspect of paper
prototyping when I've been tested with it. Always makes me laugh which
is a bit distracting. ;)

-- dave

26 Apr 2007 - 2:07pm
Henrik Olsen
2006

Well, it's not true that paper isn't good for interactivity. Paper,
pen, scissor and glue stick are the tools of choice if you want to
rapidly model advanced interactivity. And yes, the trick is to "wave
the paper around."

I can recommend this introduction to paper prototyping over at ALA:
http://www.alistapart.com/articles/paperprototyping

And I have a few post on paper prototyping at guuui.com:
http://www.guuui.com/search.php?q=%22paper+prototyping%22

I do courses in paper prototyping and it's great fun to see how
surprised people are of its capabilities after having tried it.

---
Henrik Olsen
www.guuui.com - The Interaction Designer's Coffee Break

On 4/26/07, Wilson, Russell <Russell.Wilson at netqos.com> wrote:
> Except for interactivity... Unless you wave the paper around... :-)
>
>
> Try paper. It does all kinds of fancy stuff. Very powerful and the
> most flexible and capable prototyping tool on the market. ;)
>
> Henrik Olsen
> www.guuui.com - The Interaction Designer's Coffee Break
>

26 Apr 2007 - 2:45pm
russwilson
2005

Ha ha... awesome creativity!

Yes (as demonstrated), I'm sure you can simulate interactivity

with a variety of mediums including paper, wood, cardboard,
raisin-bread, etc.

But why would you WANT to? I could have simulated (closer to reality)

the same interactions below in a fraction of the time it took you to
create

the tangible mockups...

With that said, I can't wait to try some of your ideas out for fun!! J

(what does that say?)

From: Todd Zaki Warfel [mailto:lists at toddwarfel.com]
Sent: Thursday, April 26, 2007 1:53 PM
To: Wilson, Russell
Cc: henrik.olsen at guuui.com; discuss at ixda.org
Subject: Re: [IxDA Discuss] Prototyping Drag and Drop

Ah, the naivety. Well, young grasshopper, you'd be surprised at what
kind of interactivity you can get with paper. Let's see...

I've prototyped a voice mail player that has a working scrubber with
paper. You simply cut a slit for the scrubber, attach it to a piece of
flat dental tape, and when the person presses play, you play a voicemail
from an iPod w/speakers and drag the scrubber across the player w/the
dental tape. The participants were so enamored, many of the hit the
rewind button and played it again.

I've simulated scrolling a window by having the window cut out of a
piece of poster board. Print the screens on 11x17, which allows some
overhang on the right side, which extends past the browser window's
right side. Let the participants slide the "content window" up and down
by grabbing the extended paper on the right side. Works like a charm
(just did this last week).

I've done drag and drop with placing tiles on a screen with some double
sided sticky tape on the back. They can pick them up and move them
around. Warning, use index cards for this, as paper tears much easier.

I've done scrolling text boxes. Cut a slit in the paper. Place the index
card with a string attached to the back behind it. When the participant
scrolls, pull the index card up behind it.

Oh, how what about an AJAX update to a widget after sign-in? Say, they
have a particular content area that's general when non-authenticated,
and provides personalized content when authenticated. No problem. Use
the same method as the index card above. Have the AJAXified screen as
the base. Cut slits for the non-authenticated tile. Slide the
non-authenticated model through the slits. Once the participant signs
in, pull the non-authenticated tile up, revealing the AJAXified model
underneath - viola.

Now, about that waving paper around stuff.... :).

(this is good stuff... should make it's way into my book - shameless
plug:) )

On Apr 26, 2007, at 2:36 PM, Wilson, Russell wrote:

Except for interactivity... Unless you wave the paper around...
:-)

----- Original Message -----

From: discuss-bounces at lists.interactiondesigners.com
<discuss-bounces at lists.interactiondesigners.com>

To: discuss at ixda.org <discuss at ixda.org>

Sent: Thu Apr 26 13:24:49 2007

Subject: Re: [IxDA Discuss] Prototyping Drag and Drop

Try paper. It does all kinds of fancy stuff. Very powerful and
the

most flexible and capable prototyping tool on the market. ;)

Henrik Olsen

www.guuui.com - The Interaction Designer's Coffee Break

Cheers!

Todd Zaki Warfel

Partner, Design & Usability Specialist

Messagefirst | Designing Information. Beautifully.

----------------------------------

Contact Info

Voice: (215) 825-7423

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.

26 Apr 2007 - 2:46pm
Mark Schraad
2006

Todd is right... there is a lot of interactivity that you can simulate with paper. The only thing I have not been able to replicate well is motion and dynamic data serves.But in both of those cases some level of scripting can help you to muddle through it. Paper is way more powerful than most give it credit for. Its so easy to get caught up in the tool - or the lack of it.

On Thursday, April 26, 2007, at 02:53PM, "Todd Zaki Warfel" <lists at toddwarfel.com> wrote:
>Ah, the naivety. Well, young grasshopper, you'd be surprised at what
>kind of interactivity you can get with paper. Let's see...
>
>I've prototyped a voice mail player that has a working scrubber with
>paper. You simply cut a slit for the scrubber, attach it to a piece
>of flat dental tape, and when the person presses play, you play a
>voicemail from an iPod w/speakers and drag the scrubber across the
>player w/the dental tape. The participants were so enamored, many of
>the hit the rewind button and played it again.
>
>I've simulated scrolling a window by having the window cut out of a
>piece of poster board. Print the screens on 11x17, which allows some
>overhang on the right side, which extends past the browser window's
>right side. Let the participants slide the "content window" up and
>down by grabbing the extended paper on the right side. Works like a
>charm (just did this last week).
>
>I've done drag and drop with placing tiles on a screen with some
>double sided sticky tape on the back. They can pick them up and move
>them around. Warning, use index cards for this, as paper tears much
>easier.
>
>I've done scrolling text boxes. Cut a slit in the paper. Place the
>index card with a string attached to the back behind it. When the
>participant scrolls, pull the index card up behind it.
>
>Oh, how what about an AJAX update to a widget after sign-in? Say,
>they have a particular content area that's general when non-
>authenticated, and provides personalized content when authenticated.
>No problem. Use the same method as the index card above. Have the
>AJAXified screen as the base. Cut slits for the non-authenticated
>tile. Slide the non-authenticated model through the slits. Once the
>participant signs in, pull the non-authenticated tile up, revealing
>the AJAXified model underneath - viola.
>
>Now, about that waving paper around stuff.... :).
>
>(this is good stuff... should make it's way into my book - shameless
>plug:) )
>
>On Apr 26, 2007, at 2:36 PM, Wilson, Russell wrote:
>
>> Except for interactivity... Unless you wave the paper around... :-)
>>

26 Apr 2007 - 3:03pm
Dave Malouf
2005

On 4/26/07, Mark Schraad <mschraad at mac.com> wrote:
> Its so easy to get caught up in the tool - or the lack of it.

hmm? I can't help but respond to this.
To me I just jumped and said, of course that is true, but tools "don't
matter" when I'm sketching, NOT when I'm prototyping.

I suggest people look at the great dichotomy that Bill Buxton
expresses as the different intentions and thus different manners of
using and doing sketches as compared to prototypes.
http://tinyurl.com/tgcxf

In my mind, paper is great for sketching, but b/c of the nature of
prototypes as a test as opposed to a suggestion, paper doesn't cut it.
It doesn't include the aspect of "proof of concept" that I would want
and expect from a prototype.

Yes, I might be able to get some information from users (I have used
them) with paper, but I won't get the right information. Paper doesn't
have the tangibility required to be sure you are getting at real
results. It is abstractly testing something that is already an
abstraction. It is like the loss of quality made using a copying
machine. It is just too distanced and b/c tools are too easy to use
today I find that paper prototyping is more of a throw back to a
bygone era when it was too difficult to use existing digital
prototyping tools.

The ONLY advantage I see in paper is that you can make changes in real
time fairly easily.
"Oh! did you mean this?" ... cut, glue, wave paper(s).

But again, what else is lost from that seems too important to me.

In this day in age, why aren't you doing anything short of building
instead of documenting or wireframing. Sketch > Build = F the
documentation!
Ruby, Flash, XHTML, Expression, Etc.

And no, I don't buy the whole ... designing for the tool thing
anymore. Why? b/c I did my REAL designing on paper and pencil w/
sketching. This is just defining, framing and proofing.

-- dave

--
David Malouf
http://synapticburn.com/
http://ixda.org/
http://motorola.com/

26 Apr 2007 - 3:15pm
Todd Warfel
2003

On Apr 26, 2007, at 3:45 PM, Wilson, Russell wrote:

> [...] But why would you WANT to? I could have simulated (closer to
> reality) the same interactions below in a fraction of the time it
> took you to create the tangible mockups…
Actually, that's not true. Paper almost always takes less time than
coding. In fact, it's very rare, statistically insignificant, that
coding is faster and has a lower investment than paper. Not to
mention, that with paper, changes can be made on the fly - we do it
all the time w/o the need for a developer.

Paper does take more imagination. That can be hard for some people to
deal with. But with a good moderator, that's really easy to get past.
And in my experience, honestly, I've never had a participant have
trouble with that. But it is a factor to consider.

Finally, context and constraints. If you have an existing set of
wireframes built, then it's much faster, easier, and can often be
just as effective to use them for paper prototype testing than it is
to invest 2 weeks to build a functional prototype.

That being said, paper is great for high-level concept testing. It is
not as effective for testing things like system response time, or
some visual techniques like the JavaScript fade technique.

Pick your goal. Then pick your method.
> With that said, I can’t wait to try some of your ideas out for
> fun!! J
>
> (what does that say?)
Good to hear.

Cheers!

Todd Zaki Warfel
Partner, Design & Usability Specialist
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
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.

26 Apr 2007 - 3:54pm
russwilson
2005

I wouldn't say "it's not true", I would be willing to accept "it
depends."

I'm sure that there are cases where each method is faster. And of
course

(as we've mentioned in a thread some time ago), if a tool works for you,
use it.

What I like most about Flash/Flex (or similar) is being closer to the
actual final

medium to be used. But that's a personal preference.

From: Todd Zaki Warfel [mailto:lists at toddwarfel.com]
Sent: Thursday, April 26, 2007 3:16 PM
To: Wilson, Russell
Cc: henrik.olsen at guuui.com; discuss at ixda.org
Subject: Re: [IxDA Discuss] Prototyping Drag and Drop

On Apr 26, 2007, at 3:45 PM, Wilson, Russell wrote:

[...] But why would you WANT to? I could have simulated (closer
to reality) the same interactions below in a fraction of the time it
took you to create the tangible mockups...

Actually, that's not true. Paper almost always takes less time than
coding. In fact, it's very rare, statistically insignificant, that
coding is faster and has a lower investment than paper. Not to mention,
that with paper, changes can be made on the fly - we do it all the time
w/o the need for a developer.

Paper does take more imagination. That can be hard for some people to
deal with. But with a good moderator, that's really easy to get past.
And in my experience, honestly, I've never had a participant have
trouble with that. But it is a factor to consider.

Finally, context and constraints. If you have an existing set of
wireframes built, then it's much faster, easier, and can often be just
as effective to use them for paper prototype testing than it is to
invest 2 weeks to build a functional prototype.

That being said, paper is great for high-level concept testing. It is
not as effective for testing things like system response time, or some
visual techniques like the JavaScript fade technique.

Pick your goal. Then pick your method.

With that said, I can't wait to try some of your ideas out for fun!! J

(what does that say?)

Good to hear.

Cheers!

Todd Zaki Warfel

Partner, Design & Usability Specialist

Messagefirst | Designing Information. Beautifully.

----------------------------------

Contact Info

Voice: (215) 825-7423

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.

26 Apr 2007 - 3:33pm
Eric DeLabar
2007

Although I've never had the opportunity to bring a paper prototype into a
design meeting, I can see the benefits. One of the biggest problems we have
is separating the visual design from the functionality in the customers
mind. For example, while trying to explain how a "lightbox" pop-up works I
have customers complaining that the spacing between the logo and body copy
is two big, and the logo should be 3 pixels to the left, and until we
address these "issues" with them they're too distracted to listen to what
I'm saying. In the paper prototype case the visual design is completely
removed and I can demonstrate my lightbox with a post-it and some
saran-wrap, and then wave it all around. ;)

But I could still probably prototype drag-and-drop with script.aculo.us in
as much time as it would take me to make a functioning paper prototype.

Eric DeLabar
System Engineer
Trifecta Technologies, Inc.
http://www.trifecta.com

On 4/26/07, Todd Zaki Warfel <lists at toddwarfel.com> wrote:
>
>
> On Apr 26, 2007, at 3:45 PM, Wilson, Russell wrote:
>
> > [...] But why would you WANT to? I could have simulated (closer to
> > reality) the same interactions below in a fraction of the time it
> > took you to create the tangible mockups…
> Actually, that's not true. Paper almost always takes less time than
> coding. In fact, it's very rare, statistically insignificant, that
> coding is faster and has a lower investment than paper. Not to
> mention, that with paper, changes can be made on the fly - we do it
> all the time w/o the need for a developer.
>
> Paper does take more imagination. That can be hard for some people to
> deal with. But with a good moderator, that's really easy to get past.
> And in my experience, honestly, I've never had a participant have
> trouble with that. But it is a factor to consider.
>
> Finally, context and constraints. If you have an existing set of
> wireframes built, then it's much faster, easier, and can often be
> just as effective to use them for paper prototype testing than it is
> to invest 2 weeks to build a functional prototype.
>
> That being said, paper is great for high-level concept testing. It is
> not as effective for testing things like system response time, or
> some visual techniques like the JavaScript fade technique.
>
> Pick your goal. Then pick your method.
> > With that said, I can't wait to try some of your ideas out for
> > fun!! J
> >
> > (what does that say?)
> Good to hear.
>
>
> Cheers!
>
> Todd Zaki Warfel
> Partner, Design & Usability Specialist
> Messagefirst | Designing Information. Beautifully.
> ----------------------------------
> Contact Info
> Voice: (215) 825-7423
> 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
>

27 Apr 2007 - 3:27am
Jonas Löwgren
2003

In my experience, the most significant difference between paper
"prototypes" and screen "prototypes" is that

- most users can learn the paper "prototyping" techniques quickly
enough to start expressing their own ideas during a participatory
session, in the officially approved expressive medium of the session.

- most users cannot and will not learn screen-based tools to the
level where they can contribute to a participatory session by
expressing their ideas in the approved medium.

Whether this difference is important or not depends on your
development methodology and, in particular, how important it is for
you to empower the users.

In traditional participatory design out of Scandinavia, this used to
be crucial since the design processes were essentially about
empowering workers in the political struggle against employers.

In contemporary design processes, user empowerment becomes important
in two main cases: (a) when you are planning a continuing-design-in-
use process of tinkering, modification, mashing among users after
"delivery", and (b) when you need to create seeds for a new
community. In such cases, I would strongly consider paper
"prototyping" as part of a participatory design process.

In most other cases, I would tend to think that the benefits of
screenbased "prototyping" shadows the empowerment issue.

The same kind of reasoning can be applied to the design of products
with significant physical form, where physical mockups using simple
materials can be compared with physical-computing "prototypes" using,
e.g., phidgets or Arduino.

Regards,
Jonas Löwgren

----
Arts and Communication
Malmö University, SE-205 06 Malmö, Sweden

phone +46 7039 17854
web http://webzone.k3.mah.se/k3jolo

27 Apr 2007 - 9:34am
Dave Malouf
2005

Jonas,

I totally agree w/ the usefulness of physical modeling materials
during participatory design sessions, but this to me is completely
different than prototyping for validation purposes. I'm not even sure
I would want to use the word "prototype" while thinking of
participatory design. In this case it totally falls into th sketching
world in my mind. I realize that often we use words to mean different
things when in context, but the thread seemed to be in a different
context and then you jumped in with PD, telling me that the semantics
of "prototype" are being misused.

As to Todd's assertion that digital tools aren't as fast as paper. I
know I never claimed they are. What I claimed was that they are fast
enough to make the outcome more valuable due to the higher fidelity
than what you'd get from paper.

Ok, that wasn't clear, basically, they are now soooo much faster to
use that doing paper in my mind doesn't make sense anymore. The win
you get w/ the speed of paper just isn't there if you just take the
time to learn the tools that are out there.

if I'm just testing concepts, then I don't need to wave paper around.
i can just show people stuff on a screen that is non-interactive (why
kill the tree). If I'm really testing interaction, then I should be
testing it in the medium in which it will be used.

last point from a different thread. In an age where "pauric" rightly
suggest that we should be reducing our in person research interactions
for carbon foot print and other ecological impact reasons, shouldn't
paper prototyping be phased out b/c it can really only be done in
person AND well requires us to use non-renewable resources such as
paper and ink?

yes, a computer screen requires burning fossil fuels (for now) to
create the electrons that make the color for us, but I have to do that
anyway for a paper prototype to create the printouts.

-- dave

27 Apr 2007 - 10:40am
Todd Warfel
2003

On Apr 27, 2007, at 10:34 AM, David Malouf wrote:

> Ok, that wasn't clear, basically, they are now soooo much faster to
> use that doing paper in my mind doesn't make sense anymore. The win
> you get w/ the speed of paper just isn't there if you just take the
> time to learn the tools that are out there.

Depends on your resources and situation. One of the things many of us
often forget is that "our" environment isn't always the same as
"everyone" else's.

I recall having a discussion with a colleague a year ago where this
came up. In the environment he was in, as an internal person where
all the designers knew HTML/CSS, it made more sense to do HTML
wireframes - the Visio, OmniGraffle, InDesign, Illustrator models
didn't make sense. And rightfully so. However, if that's not your
environment, then you'll have to consider a different option. In the
environment I'm in, most of the designers we deal with don't know
HTML/CSS, so we can't depend on that model. It has a number of
advantages, but if we can't support it, then we have to look at
alternatives.

If we are in control of the design/development process, then often
advocate interactive prototypes. However, when we come into a project
in mid-stream, which happens more than I'd like, and a wireframe deck
is already established, there's a tight timeline and no budget or
resources to build an interactive prototype, then we'll advocate
paper (if we can accomplish the goals of the test with paper). If
paper won't get the answers we need, then we'll strongly advocate an
interactive prototype and push out the timeline two weeks (that's
pretty standard for the time to get an interactive prototype built in
my experience). We've seen some take months (really hi-fidelity), but
more often than not, it's two weeks to get it built, tweaked, and
polished enough for testing.

My point is keep your options open. Have a plan B. Know your options
and depending on your goals, timeline, resources, etc. pick the
appropriate method. It's not always going to be interactive (like it
or not) and it's not always going to be paper.

Cheers!

Todd Zaki Warfel
Partner, Design & Usability Specialist
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
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.

30 Apr 2007 - 2:41am
Jonas Löwgren
2003

> I totally agree w/ the usefulness of physical modeling materials
> during participatory design sessions, but this to me is completely
> different than prototyping for validation purposes.

Right. My comments about participatory design and its expressive
materials did not make very much sense in the context of prototype
validation.

I guess the bigger issue is to what extent it still makes sense to
think in terms of validation and delivery. With many signs pointing
in the direction of tinkering and mashing-up, I wonder if there isn't
a growing demand in the next few years for viable business models
covering continuing-design-in-use.

That would change the game to a certain extent, I believe.

/Jonas Löwgren

----
Arts and Communication
Malmö University, SE-205 06 Malmö, Sweden

phone +46 7039 17854
web http://webzone.k3.mah.se/k3jolo

Syndicate content Get the feed