nested, multi-step progress bars

30 Nov 2007 - 11:02am
6 years ago
15 replies
2380 reads
Meredith Noble
2010

Hi all,

I'm looking for some ideas on how to design progress bars for some
nested flows.

In the application I'm designing right now, we have two flows for two
related tasks, task A and task B. Task A has 3 steps, and Task B has 4
steps. Task B can be done independently, without task A, but MUST be
completed before Task A can be completed.

The trick is that we allow people to enter the flow for Task A, and then
jump out to Task B if they need/wish to.

In other words, instead of just doing A1 -> A2 -> A3, some users instead
go through the steps: A1 -> B1 -> B2 -> B3 -> B4 -> A2 -> A3.

Has anyone ever designed progress bars for something like this before?
We can't predict in advance whether or not a user will want to jump out
to Task B from Task A, so we can't simply include those steps in our
progress bar off the bat. The other solutions I can envision are:

a) Dynamically updating the progress bar to include 7 steps after
the user can indicated a desire to go to Task B (maybe visually
indicating that some are substeps, so as not to overwhelm the user)

b) Simply replacing the Task A progress bar with the Task B
progress bar until Task B is finished, then going back to the Task A
progress bar afterward

Phew, I hope I've been clear here. It's hard to explain without a
concrete example!

I can see shortcomings in both of these solutions so I'm hoping someone
might have a suggestion for something else elegant that I've missed...

Thanks all,

Meredith

-----------------------------------------------------------------------
Meredith Noble
Information Architect, Usability Matters Inc.
416-598-7770, ext. 6
meredith at usabilitymatters.com <mailto:meredith at usabilitymatters.com>

Comments

30 Nov 2007 - 11:21am
.pauric
2006

Suggestion: Create a split progress bar once the user jumps from one
task to another.

User some form of colour coding (green = a, blue =b) to allow the
user to connect each bar with its corresponding task.

This is a little half-baked and would need a lot of testing...
http://web.mac.com/pauric_ocallaghan/progresseses.jpg

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://gamma.ixda.org/discuss?post=23155

30 Nov 2007 - 11:59am
lachica
2006

Could you do Task B in a pop up? Or the appearance of a pop up- gray out the
Task A screen and only return to it after the highlighted Task B screen is
completed. Task B would appear in a smaller window highlighted in the center
but would not be an actual separate window.

Cheers,
Julie

On Nov 30, 2007 10:02 AM, Meredith Noble <meredith at usabilitymatters.com>
wrote:

> Hi all,
>
>
>
> I'm looking for some ideas on how to design progress bars for some
> nested flows.
>
>
>
> In the application I'm designing right now, we have two flows for two
> related tasks, task A and task B. Task A has 3 steps, and Task B has 4
> steps. Task B can be done independently, without task A, but MUST be
> completed before Task A can be completed.
>
>
>
> The trick is that we allow people to enter the flow for Task A, and then
> jump out to Task B if they need/wish to.
>
>
>
> In other words, instead of just doing A1 -> A2 -> A3, some users instead
> go through the steps: A1 -> B1 -> B2 -> B3 -> B4 -> A2 -> A3.
>
>
>
> Has anyone ever designed progress bars for something like this before?
> We can't predict in advance whether or not a user will want to jump out
> to Task B from Task A, so we can't simply include those steps in our
> progress bar off the bat. The other solutions I can envision are:
>
>
>
> a) Dynamically updating the progress bar to include 7 steps after
> the user can indicated a desire to go to Task B (maybe visually
> indicating that some are substeps, so as not to overwhelm the user)
>
>
>
> b) Simply replacing the Task A progress bar with the Task B
> progress bar until Task B is finished, then going back to the Task A
> progress bar afterward
>
>
>
> Phew, I hope I've been clear here. It's hard to explain without a
> concrete example!
>
>
>
> I can see shortcomings in both of these solutions so I'm hoping someone
> might have a suggestion for something else elegant that I've missed...
>
>
>
> Thanks all,
>
> Meredith
>
>
>
> -----------------------------------------------------------------------
> Meredith Noble
> Information Architect, Usability Matters Inc.
> 416-598-7770, ext. 6
> meredith at usabilitymatters.com <mailto:meredith at usabilitymatters.com>
>
>
>
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah*
> February 8-10, 2008 in Savannah, GA, USA
> Register today: http://interaction08.ixda.org/
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

30 Nov 2007 - 12:38pm
Meredith Noble
2010

Hey Pauric,

Love the filename ;)

It's an interesting idea, though it does seem like it could get
confusing. As you say, maybe with some more refinement it could go
somewhere.

I'm leaning towards my description of option (a) at the moment. I've
sketched it out here:

http://www.usabilitymatters.com/work/nested_progress_bars.gif

I'm thinking that after Task B is finished and those details no longer
matter, we might be able to do away with those steps on the progress bar
entirely. Then again, if they choose to step backwards in the process to
change some information they've edited, it *could* get confusing.

That would lead more to a design like this:

http://www.usabilitymatters.com/work/nested_progress_bars_keep_steps.gif

I keep thinking there MUST be examples out there of other people who
have done this. I have managed to actively avoid this situation up to
this point, but there are some situations where you just can't get
around it.

Meredith

> Suggestion: Create a split progress bar once the user jumps from one
> task to another.
>
> User some form of colour coding (green = a, blue =b) to allow the
> user to connect each bar with its corresponding task.
>
> This is a little half-baked and would need a lot of testing...
> http://web.mac.com/pauric_ocallaghan/progresseses.jpg

30 Nov 2007 - 1:09pm
Oleh Kovalchuke
2006

Here is one possible solution for the progress bar.

Progress bar in the beginning of the wizard:

✓ A step1✓
A step2
B step1
B step2
B step3
B step4
A step3
Progress bar at the branching point (B path has been completed):
Replace dash (-) with "done" check mark.

✓A step1
✓ A step2✓
-B step1
-B step2
-B step3
-B step4
A step3

Progress bar at the branching point (B path has not been completed):

✓A step1
✓ A step2✓
B step1
B step2
B step3
B step4
A step3

Progress bar past the branching point (working on B path):

✓A step1
✓✓✓A step2
✓B step1
✓B step2✓
B step3
B step4
A step3

This progress bar keeps users informed about future steps at all times as
well as educates them about the connection between pathways A and B (builds
the conceptual model of the workflow) for the future similar tasks.

Oleh

30 Nov 2007 - 1:12pm
.pauric
2006

Meredith, I have to ask about the value of displaying all the labels
in your example. Obviously you have insight to the application . Do
you feel this detail is critical for a user's understanding of
progress, especially when balanced with the cognitive load this may
induce.

>From your initial post I took the key design directive 'how to
design progress bars for some nested flows' to translate roughly in
to; 'A method of displaying overall progress when a user has the
ability to change between two work flows'

-If- completion of the wizards is a requirement and the progress bars
cannot be used as a navigation tool. Is it necessary to have such
detailed labels on the bars?? In my mind, progress bars are
arbitrary, they have no basis in work load or time.

If, for some reason, a user needs to know they've complete Step A.2
when they're on B.5 then I think you need something more
sophisticated, the progress bar pattern wont help.

Either way - fascinating design problem. Thanks for sharing!

-pauric

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://gamma.ixda.org/discuss?post=23155

30 Nov 2007 - 1:47pm
Meredith Noble
2010

Pauric, I'm not sure I understand your point about the labels. It's hard
to get the message across with generic steps! I do think you have
slightly misunderstood my general problem though.

I'm trying to say that people can do Task B at any time, and without
having to do Task A. They might do Task B on Tuesday, and then later use
the products of that task to complete Task A on Friday.

For example, let's say Task B is defining everything about some widget.
You can store information on a bunch of widgets in advance. Then, at
some point in the future, you might want to send information on one of
those widgets to a customer.

If you hit the "Send Widget to Customer" button, you'll be taken into
the Send Widget flow. Great, but if you don't yet have any widgets
defined, you'll need to be sent into the "Define Widget" flow before you
can finish sending your widget.

Am I making sense? Basically, you can start task A (send widget), but
you may need to go off into task B (define widget) before you can
complete task A.

It's not quite as complex as you make it out to be; people don't need to
go back and forth at will. People would never go B -> A -> B. They would
only ever go A -> B -> A. BUT, sometimes, if they've done B in the past,
they might only need to do A. So sometimes the flow is 3 steps long, and
other times, if they haven't defined their widget, it might be 7 steps
long. We don't know until the first step of A whether there will be 3 or
7 steps (the user tells us whether they want to use an existing widget,
or define a new one).

I don't see my labels as being any different from the labels on, say,
Amazon's progress bar: Sign In, Shipping & Payment, Gift Wrap, Place
Order. They let users know where they are in the process. I don't see it
as a great cognitive load (understanding my generic labels of A1, B1,
B2, etc. is though, I know!).

Do you see the labeling issue differently, or am I misunderstanding?
Perhaps you could elaborate on that point.

Meredith

> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com [mailto:discuss-
> bounces at lists.interactiondesigners.com] On Behalf Of pauric
> Sent: Friday, November 30, 2007 1:15 PM
> To: discuss at ixda.org
> Subject: Re: [IxDA Discuss] nested, multi-step progress bars
>
> Meredith, I have to ask about the value of displaying all the labels
> in your example. Obviously you have insight to the application . Do
> you feel this detail is critical for a user's understanding of
> progress, especially when balanced with the cognitive load this may
> induce.
>
> >From your initial post I took the key design directive 'how to
> design progress bars for some nested flows' to translate roughly in
> to; 'A method of displaying overall progress when a user has the
> ability to change between two work flows'
>
> -If- completion of the wizards is a requirement and the progress bars
> cannot be used as a navigation tool. Is it necessary to have such
> detailed labels on the bars?? In my mind, progress bars are
> arbitrary, they have no basis in work load or time.
>
> If, for some reason, a user needs to know they've complete Step A.2
> when they're on B.5 then I think you need something more
> sophisticated, the progress bar pattern wont help.
>
> Either way - fascinating design problem. Thanks for sharing!
>
> -pauric

30 Nov 2007 - 1:55pm
Meredith Noble
2010

Thanks for this, Oleh.

This would work well if Task B was a complete once and only once sort of
thing. What I don't think I managed to get across was that it's fully up
to the user each time whether they want to go through Task B again or
not.

If they've never done Task B before, they are *forced* into Task B to
create a widget to work with.

However, even if they *have* done Task B before, and have widgets to
work with, they may still choose to define a new widget to work with -
one that's not already in their list.

Unfortunately (I think) your great design only allows for completing
Task B once and only once. Am I right?

Sorry for leaving that important detail out!

Meredith

30 Nov 2007 - 2:25pm
Oleh Kovalchuke
2006

The check marks for the B path ar provisional, they serve as a reminder
that the work has been done already. If user choses to proceed with another
round along path B, the check marks for that path are cleared, and the user
proceeds on her merry way along the path B one more time).

Oleh

On Nov 30, 2007 11:55 AM, Meredith Noble <meredith at usabilitymatters.com>
wrote:

> Thanks for this, Oleh.
>
> This would work well if Task B was a complete once and only once sort of
> thing. What I don't think I managed to get across was that it's fully up to
> the user each time whether they want to go through Task B again or not.
>
> If they've never done Task B before, they are *forced* into Task B to
> create a widget to work with.
>
> However, even if they *have* done Task B before, and have widgets to work
> with, they may still choose to define a new widget to work with – one that's
> not already in their list.
>
> Unfortunately (I think) your great design only allows for completing Task
> B once and only once. Am I right?
>
> Sorry for leaving that important detail out!
>
> Meredith
>
> ------------------------------
> *From:* Oleh Kovalchuke [mailto:tangospring at gmail.com]
> *Sent:* Friday, November 30, 2007 1:15 PM
> *To:* Meredith Noble
> *Cc:* discuss at ixda.org
> *Subject:* Re: [IxDA Discuss] nested, multi-step progress bars
>
> Here is one possible solution for the progress bar.
>
> Progress bar in the beginning of the wizard:
>
> * A step1*
> A step2
> B step1
> B step2
> B step3
> B step4
> A step3
>
> Progress bar at the branching point (B path has been completed):
> Replace star (*) with "done" check mark.
>
> *A step1
> * A step2*
> *B step1
> *B step2
> *B step3
> *B step4
> A step3
>
> Progress bar at the branching point (B path has not been completed):
>
> *A step1
> * A step2*
> B step1
> B step2
> B step3
> B step4
> A step3
>
> Progress bar past the branching point (working on B path):
>
> *A step1
> ***A step2
> *B step1
> *B step2*
> B step3
> B step4
> A step3
>
> This progress bar keeps users informed about future steps at all times as
> well as educates them about the connection between pathways A and B (builds
> the conceptual model of the workflow) for the future similar tasks.
>
> Oleh
> On Nov 30, 2007 9:02 AM, Meredith Noble <meredith at usabilitymatters.com>
> wrote:
> Hi all,
> I'm looking for some ideas on how to design progress bars for some
> nested flows.
> In the application I'm designing right now, we have two flows for two
> related tasks, task A and task B. Task A has 3 steps, and Task B has 4
> steps. Task B can be done independently, without task A, but MUST be
> completed before Task A can be completed.
> The trick is that we allow people to enter the flow for Task A, and then
> jump out to Task B if they need/wish to.
> In other words, instead of just doing A1 -> A2 -> A3, some users instead
>
> go through the steps: A1 -> B1 -> B2 -> B3 -> B4 -> A2 -> A3.
> Has anyone ever designed progress bars for something like this before?
> We can't predict in advance whether or not a user will want to jump out
> to Task B from Task A, so we can't simply include those steps in our
> progress bar off the bat. The other solutions I can envision are:
> a) Dynamically updating the progress bar to include 7 steps after
> the user can indicated a desire to go to Task B (maybe visually
> indicating that some are substeps, so as not to overwhelm the user)
> b) Simply replacing the Task A progress bar with the Task B
> progress bar until Task B is finished, then going back to the Task A
> progress bar afterward
> Phew, I hope I've been clear here. It's hard to explain without a
> concrete example!
> I can see shortcomings in both of these solutions so I'm hoping someone
> might have a suggestion for something else elegant that I've missed...
> Thanks all,
> Meredith
> -----------------------------------------------------------------------
> Meredith Noble
> Information Architect, Usability Matters Inc.
> 416-598-7770, ext. 6
> meredith at usabilitymatters.com <mailto:meredith at usabilitymatters.com >
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah* February 8-10, 2008 in Savannah,
> GA, USA
> Register today: http://interaction08.ixda.org/
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
> --
> Oleh Kovalchuke
> Interaction Design is the Design of Time
> http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm
>
--
Oleh Kovalchuke
Interaction Design is the Design of Time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

30 Nov 2007 - 2:37pm
.pauric
2006

I didnt read your description carefully.. apologies. Point taken on
the labels, Amazon is an excellent example

I guess this boils down to my belief that progress meters are an
illusion. A little trick designers can employ to comfort users in to
thinking things aren't stuck. Borne out of the flaws of slow systems
- where user's needed feedback.

I do see a fundamental difference between a 'progress bar' (extreme
example - but fundamentally this is what they are)
http://www.dynamicdrive.com/dynamicindex11/xpprogressbar.htm
and a stage indicator
http://www.webreference.com/programming/xul/amazon.png

I didnt realize before that your process can be stopped and picked up
over a number of days. In that case I'd point towards some of the Tax
applications (TaxAct, Turbo tax etc). I dont believe they use
progress meters - stand to be corrected on that.

If this was a straight forward flow I'd buy the requirement. But I
still have the question - why would users need a graphic to indicate
'progress' when the user is the dependency in terms of the time they
spend in your flows and the subroutines they may (or may not) choose.

Again, I may (hell.. probably) have misunderstood things but it sounds
like you need a navigation system that indicates the stages. I have
in the past used a series of tabbed mini wizards... my aprroach here
would be to build the 'progress' in to the navigation.

regards- pauric

30 Nov 2007 - 2:44pm
Oleh Kovalchuke
2006

Let me rephrase what you are describing, Meredith: in the workflow diagram
for this wizard, you have two "if" statements in the row: "Was the path B
completed before?", "Does user want to make another round of the path B?".

The provisional completion check marks along the path B answer "yes" to the
first question and can be cleared or made permanent in the answer to the
second question. I would recommend to make the provisional check slightly
desaturated to indicate that they are conditional, only suggest one of the
two possible paths.

Oleh
On Nov 30, 2007 12:25 PM, Oleh Kovalchuke <tangospring at gmail.com> wrote:

> The check marks for the B path ar provisional, they serve as a reminder
> that the work has been done already. If user choses to proceed with another
> round along path B, the check marks for that path are cleared, and the user
> proceeds on her merry way along the path B one more time).
>
> Oleh
>
>
> On Nov 30, 2007 11:55 AM, Meredith Noble <meredith at usabilitymatters.com>
> wrote:
>
> > Thanks for this, Oleh.
> >
> > This would work well if Task B was a complete once and only once sort of
> > thing. What I don't think I managed to get across was that it's fully up to
> > the user each time whether they want to go through Task B again or not.
> >
> > If they've never done Task B before, they are *forced* into Task B to
> > create a widget to work with.
> >
> > However, even if they *have* done Task B before, and have widgets to
> > work with, they may still choose to define a new widget to work with – one
> > that's not already in their list.
> >
> > Unfortunately (I think) your great design only allows for completing
> > Task B once and only once. Am I right?
> >
> > Sorry for leaving that important detail out!
> >
> > Meredith
> >
> > ------------------------------
> > *From:* Oleh Kovalchuke [mailto: tangospring at gmail.com]
> > *Sent:* Friday, November 30, 2007 1:15 PM
> > *To:* Meredith Noble
> > *Cc:* discuss at ixda.org
> > *Subject:* Re: [IxDA Discuss] nested, multi-step progress bars
> >
> > Here is one possible solution for the progress bar.
> >
> > Progress bar in the beginning of the wizard:
> >
> > * A step1*
> > A step2
> > B step1
> > B step2
> > B step3
> > B step4
> > A step3
> >
> > Progress bar at the branching point (B path has been completed):
> > Replace star (*) with "done" check mark.
> >
> > *A step1
> > * A step2*
> > *B step1
> > *B step2
> > *B step3
> > *B step4
> > A step3
> >
> > Progress bar at the branching point (B path has not been completed):
> >
> > *A step1
> > * A step2*
> > B step1
> > B step2
> > B step3
> > B step4
> > A step3
> >
> > Progress bar past the branching point (working on B path):
> >
> > *A step1
> > *** A step2
> > *B step1
> > *B step2*
> > B step3
> > B step4
> > A step3
> >
>
> This progress bar keeps users informed about future steps at all times as
> well as educates them about the connection between pathways A and B (builds
> the conceptual model of the workflow) for the future similar tasks.
>
> Oleh
> On Nov 30, 2007 9:02 AM, Meredith Noble <meredith at usabilitymatters.com>
> wrote:
> Hi all,
> I'm looking for some ideas on how to design progress bars for some
> nested flows.
> In the application I'm designing right now, we have two flows for two
> related tasks, task A and task B. Task A has 3 steps, and Task B has 4
> steps. Task B can be done independently, without task A, but MUST be
> completed before Task A can be completed.
> The trick is that we allow people to enter the flow for Task A, and then
> jump out to Task B if they need/wish to.
> In other words, instead of just doing A1 -> A2 -> A3, some users instead
>
> go through the steps: A1 -> B1 -> B2 -> B3 -> B4 -> A2 -> A3.
> Has anyone ever designed progress bars for something like this before?
> We can't predict in advance whether or not a user will want to jump out
> to Task B from Task A, so we can't simply include those steps in our
> progress bar off the bat. The other solutions I can envision are:
> a) Dynamically updating the progress bar to include 7 steps after
> the user can indicated a desire to go to Task B (maybe visually
> indicating that some are substeps, so as not to overwhelm the user)
> b) Simply replacing the Task A progress bar with the Task B
> progress bar until Task B is finished, then going back to the Task A
> progress bar afterward
> Phew, I hope I've been clear here. It's hard to explain without a
> concrete example!
> I can see shortcomings in both of these solutions so I'm hoping someone
> might have a suggestion for something else elegant that I've missed...
> Thanks all,
> Meredith
> -----------------------------------------------------------------------
> Meredith Noble
> Information Architect, Usability Matters Inc.
> 416-598-7770, ext. 6
> meredith at usabilitymatters.com <mailto:meredith at usabilitymatters.com >
> ________________________________________________________________
> *Come to IxDA Interaction08 | Savannah* February 8-10, 2008 in Savannah,
> GA, USA
> Register today: http://interaction08.ixda.org/
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
> --
> Oleh Kovalchuke
> Interaction Design is the Design of Time
> http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm
> --
> Oleh Kovalchuke
> Interaction Design is the Design of Time
> http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm
>

--
Oleh Kovalchuke
Interaction Design is the Design of Time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

30 Nov 2007 - 3:03pm
Parth Upadhye
2007

Meredith, I would not use a progress bar to solve this design problem
(of the widgets). I would instead state the completion status or
rather the "not complete" status of the widget definition [B].
Basically you can't continue with [A] without having completed [B].
Simple instructions or indicators at start and through the process
can serve the purpose. It's very similar to the "* required field"
device.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://gamma.ixda.org/discuss?post=23155

30 Nov 2007 - 3:26pm
Meredith Noble
2010

Pauric, perhaps all our difficulty is about terminology. I am actually
talking about a stage indicator, but for some reason the term didn't
come to mind when I was first posting. Apologies for the confusion! It
is a web app, so there is no concept of subroutine processing, etc. They
walk through different pages with forms, and work their way to the end
of the process. I want them to understand what step they and on, and how
many more steps they have to complete before they accomplish their goal.

It's exactly like Amazon, except pretend that in certain circumstances,
from the "Shipping & Payment" step, you might need to launch into
another 3 step process before you're able to get to the Gift Wrap step.

Unfortunately I'm so far down the path that I can't really get away from
the stage indicator at this point, and due to other requirements I can't
change the indicator into an active navigation item, so I am probably
stuck with a variation of what I have right now. I appreciate all your
thoughts though -- they've definitely made me think!

Meredith

> -----Original Message-----
> From: pauric [mailto:radiorental at gmail.com]
> Sent: Friday, November 30, 2007 2:46 PM
> To: Meredith Noble
> Cc: discuss at ixda.org
> Subject: Re: [IxDA Discuss] nested, multi-step progress bars
>
> I didnt read your description carefully.. apologies. Point taken on
> the labels, Amazon is an excellent example
>
> I guess this boils down to my belief that progress meters are an
> illusion. A little trick designers can employ to comfort users in to
> thinking things aren't stuck. Borne out of the flaws of slow systems
> - where user's needed feedback.
>
> I do see a fundamental difference between a 'progress bar' (extreme
> example - but fundamentally this is what they are)
> http://www.dynamicdrive.com/dynamicindex11/xpprogressbar.htm
> and a stage indicator
> http://www.webreference.com/programming/xul/amazon.png
>
> I didnt realize before that your process can be stopped and picked up
> over a number of days. In that case I'd point towards some of the Tax
> applications (TaxAct, Turbo tax etc). I dont believe they use
> progress meters - stand to be corrected on that.
>
> If this was a straight forward flow I'd buy the requirement. But I
> still have the question - why would users need a graphic to indicate
> 'progress' when the user is the dependency in terms of the time they
> spend in your flows and the subroutines they may (or may not) choose.
>
> Again, I may (hell.. probably) have misunderstood things but it sounds
> like you need a navigation system that indicates the stages. I have
> in the past used a series of tabbed mini wizards... my aprroach here
> would be to build the 'progress' in to the navigation.
>
> regards- pauric
>

30 Nov 2007 - 3:55pm
Meredith Noble
2010

> Meredith, I would not use a progress bar to solve this design problem
> (of the widgets). I would instead state the completion status or
> rather the "not complete" status of the widget definition [B].
> Basically you can't continue with [A] without having completed [B].
> Simple instructions or indicators at start and through the process
> can serve the purpose. It's very similar to the "* required field"
> device.

Parth, are you suggesting that I not let them into the A flow if they
haven't already done B? I'm not sure I follow.

Meredith

1 Dec 2007 - 1:52pm
Oleh Kovalchuke
2006

Here is how the graphic would look like:
http://farm3.static.flickr.com/2107/2078725918_3a307ecebc_o.gif
Oleh

PS The workflow would be even more interesting, if the branching point for
the path B were placed after the first step. Then you would need to consider
if the person is habitual or infrequent user of the workflow, to build
personas etc.

On Nov 30, 2007 12:44 PM, Oleh Kovalchuke <tangospring at gmail.com> wrote:

> Let me rephrase what you are describing, Meredith: in the workflow diagram
> for this wizard, you have two "if" statements in the row: "Was the path B
> completed before?", "Does user want to make another round of the path B?".
>
> The provisional completion check marks along the path B answer "yes" to
> the first question and can be cleared or made permanent in the answer to the
> second question. I would recommend to make the provisional check slightly
> desaturated to indicate that they are conditional, only suggest one of the
> two possible paths.
>
> Oleh
> On Nov 30, 2007 12:25 PM, Oleh Kovalchuke <tangospring at gmail.com> wrote:
>
> > The check marks for the B path ar provisional, they serve as a reminder
> > that the work has been done already. If user choses to proceed with another
> > round along path B, the check marks for that path are cleared, and the user
> > proceeds on her merry way along the path B one more time).
> >
> > Oleh
> >
> >
> >
>

3 Dec 2007 - 10:26am
Parth Upadhye
2007

Say I have completed Flow A to the point that I need to have completed
Flow B before continuing, display a message ONLY when the user wants
to go the next step of Flow A.

Example:
User presses "Purchase" or "Payment Options" buttons [Flow A].
Display Message to complete [Flow B]: "Login or Register to
purchase"

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://gamma.ixda.org/discuss?post=23155

Syndicate content Get the feed