<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Comments on Wizards and Guides</title>
    <link>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2</link>
    <pubDate>Fri, 26 Jan 2007 14:51:52 GMT</pubDate>
    <description>In part one of this article the discussion was one of views, forms, and the manner in which they could be combined into a task structure known as a hub. This installment expands on those themes by exploring two other types of task structures commonly employed in web applications--wizards and guides.</description>
    <item>
      <description>&lt;p&gt;Che&amp;#8230;you are of course, absolutely correct. Support for conditional workflows is one of the fundamental differences between the two structures.&lt;/p&gt;

	&lt;p&gt;Thanks for pointing out the omission and apologies for my near-total brain cramp 8^)&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1909</link>
      <guid>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1909</guid>
      <pubDate>Fri, 26 Jan 2007 14:51:52 GMT</pubDate>
      <author>Bob Baxley</author>
    </item>
    <item>
      <description>&lt;p&gt;The discussion of Wizards versus Guides in these comments ignores the situations where a wizard is applicable, but a guide is not: linear workflows with conditional branches based on user input.&lt;/p&gt;

	&lt;p&gt;In this case, a Wizard serves an important function: hiding complexity that is not required for all users. In this sense, a wizard is much more than a single form broken up into tranches&amp;#8230; And a guide would not enhance the experience, unless the &amp;#8220;hub&amp;#8221;-style map changes its shape based on user selections.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1908</link>
      <guid>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1908</guid>
      <pubDate>Fri, 26 Jan 2007 14:51:52 GMT</pubDate>
      <author>Che</author>
    </item>
    <item>
      <description>&lt;p&gt;Jim: Thanks for both the kind words and substantive comments. I understand your point about the &amp;#8220;Start Again&amp;#8221; navigation on my diagram and how it breaks with traditional wizards. I agree that the additional navigation is unusual but it is easily defensible, and certainly useful, for wizards that result in complex transactions rather than non-reversible operations. Such &amp;#8220;start again&amp;#8221; options don&amp;#8217;t appear in &amp;#8220;traditional&amp;#8221; wizards because they simply aren&amp;#8217;t applicable for operations like software installation, disk formatting, or account creation&amp;#8212;the procedures typically handled by such wizards. Again, it depends on the specifics of the situation but there are certainly cases where a &amp;#8220;start again&amp;#8221; option can be useful and so I chose to add it to the diagram.&lt;/p&gt;

	&lt;p&gt;In terms of your final point, I agree that the distinction between wizards and guides is a subtle one. However, I chose to differentiate the two because I wanted to enforce the point that the strict, linear wizards are too often used in situations where they are not required. My hope was that by referring to guides as a separate type of workflow it would inspire readers to seek out solutions that supported the additional navigational flexibility characteristic of guides.&lt;/p&gt;

	&lt;p&gt;Thanks again for your comments and I&amp;#8217;ll try to make sure that it&amp;#8217;s not quite another full year before my next article.  8^)&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1907</link>
      <guid>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1907</guid>
      <pubDate>Fri, 26 Jan 2007 14:51:52 GMT</pubDate>
      <author>Bob Baxley</author>
    </item>
    <item>
      <description>&lt;p&gt;Another year; another fine Bob Baxley article. Thanks!&lt;/p&gt;

	&lt;p&gt;I do have a few nits to pick, however&amp;#8230;&lt;/p&gt;

	&lt;p&gt;1) Terminology: yes, the term &amp;#8220;Wizard&amp;#8221; sounds like techno-obscurantism. However, many users coming from a mainstream &lt;span class="caps"&gt;GUI&lt;/span&gt; background (i.e., Windows) tend, in my experience, to already be familiar with both the term and (roughly) the concept. So using it lessens the learning curve and the need for having to explain the flow of that (wizard) UI. This is a win, though not necessarily a big one.&lt;/p&gt;

	&lt;p&gt;2) Both the diagram and the example screenshot of a Wizard show a &amp;#8216;Start Again&amp;#8217; navigation path. While I think that is a defensible addition the normal navigation paths in a wizard, it *is* a quite unusual one! So, I would change the diagram so that there were just left/right arrows between adjacent bubbles on the diagram&amp;#8212;that would much more closely correspond to a &amp;#8216;traditional&amp;#8217; wizard.&lt;/p&gt;

	&lt;p&gt;3) Finally, it is not clear to me that the distinction between a &amp;#8216;wizard&amp;#8217; UI and a &amp;#8216;guide&amp;#8217; UI is a useful one. They _both_ look like wizard UIs to me, except that the latter one has some (what I call) non-linear navigation paths added.&lt;br /&gt;Furthermore, if you think about it, the BA.COM screenshot example (and the wizard diagram) could be considered as using a &amp;#8216;guide&amp;#8217; UI design, albeit a degenerate one where the only non-linear path support is the &amp;#8216;back to start&amp;#8217; one.&lt;br /&gt;So I would refer to the two UI designs as: a &amp;#8216;traditional&amp;#8217; wizard vs. a wizard with non-linear navigation added.&lt;br /&gt;I&amp;#8217;ve seen implementations of the latter in both &lt;span class="caps"&gt;GUI&lt;/span&gt; (Windows) applications and in Weblications. For an example of the latter, go to: &lt;a href="http://www.sonexis.com" rel="nofollow"&gt;http://www.sonexis.com&lt;/a&gt; and then click on the button entitled (&amp;#8220;See the Power of the Sonexis Conferenceing Solution&amp;#8221;), in the middle of the home page. When you see the UI entitled &amp;#8220;Schedule Conference For Later&amp;#8221;, notice the captions over in the left &amp;#8216;sign post&amp;#8217; area&amp;#8212;these are actually hyperlinks and, thereby, support non-linear navigation of the wizard.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1906</link>
      <guid>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1906</guid>
      <pubDate>Fri, 26 Jan 2007 14:51:52 GMT</pubDate>
      <author>Jim Abbott</author>
    </item>
    <item>
      <description>&lt;p&gt;Thanks for the comments and kind words. Ji, if you can provide a bit more context around your question I might be able to offer a few ideas. And Max, couldn&amp;#8217;t agree more with your frustration over the terminology. In my maturity however, I&amp;#8217;ve learned to pick my battles and I fear that that one is not only unwinable, but also long since concluded.&lt;/p&gt;

	&lt;p&gt;On a more abstract note, there&amp;#8217;s something interesting going on in Ben and Liam&amp;#8217;s comments. My goal with these articles is not so much to break new ground but rather to describe the workings of proven interaction design mechanisms so that less experienced designers can make more appropriate use of them. To my eye there is no shortage of poor design that could easily be fixed by a better understanding of these basics pattern.&lt;/p&gt;

	&lt;p&gt;This approach stems from my philosophical position that design in general, and certainly interaction design in particular, is fundamentally a craft&amp;#8212;a craft that is both easy to learn and difficult to perfect. The implicit disappointment in Ben&amp;#8217;s comment however points to a different, competing philosophy, a philosophy that sees interface design as a type of science that is constantly evolving new knowledge and new techniques.&lt;/p&gt;

	&lt;p&gt;I suspect the truth is somewhere in between those two positions but would be interested in hearing what others think.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1905</link>
      <guid>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1905</guid>
      <pubDate>Fri, 26 Jan 2007 14:51:52 GMT</pubDate>
      <author>Bob Baxley</author>
    </item>
    <item>
      <description>&lt;p&gt;Alfred North Whitehead said &amp;#8220;It requires a very unusual mind to make an analysis of the obvious&amp;#8221;.&lt;/p&gt;

	&lt;p&gt;Let&amp;#8217;s face it though, much of the boxes and arrows conent is &lt;span class="caps"&gt;NOT&lt;/span&gt; ground breaking. Many of the topics have been covered 5, 10, 15, &amp;#38; more years ago.  Look at design history, early &lt;span class="caps"&gt;HCI&lt;/span&gt; literature, work in data visualization, Dreyfuss&amp;#8217;s book on Designing for People, etc, etc&amp;#8230;&lt;/p&gt;

	&lt;p&gt;Good article I thought. Well written &amp;#38; thought out.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1904</link>
      <guid>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1904</guid>
      <pubDate>Fri, 26 Jan 2007 14:51:52 GMT</pubDate>
      <author>liam friedland</author>
    </item>
    <item>
      <description>&lt;p&gt;This is a fine article, except that  &amp;#8220;wizard&amp;#8221; is a stupid word that I wish we&amp;#8217;d stop using. It&amp;#8217;s lost it&amp;#8217;s &amp;#8220;magic,&amp;#8221; don&amp;#8217;t you think?&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1903</link>
      <guid>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1903</guid>
      <pubDate>Fri, 26 Jan 2007 14:51:52 GMT</pubDate>
      <author>Max</author>
    </item>
    <item>
      <description>&lt;p&gt;Bob, thanks for another great article.&lt;/p&gt;

	&lt;p&gt;Do you have any recommendations or comments on designing for dynamic wizards (where number of steps in the wizard is determined by the user)?&lt;/p&gt;

	&lt;p&gt;The problems that I ran into with designing dynamic wizards are: &lt;br /&gt;can&amp;#8217;t tell the user how many steps it would take to finish the wizard, and displaying correct status indicator.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1902</link>
      <guid>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1902</guid>
      <pubDate>Fri, 26 Jan 2007 14:51:52 GMT</pubDate>
      <author>ji kim</author>
    </item>
    <item>
      <description>&lt;p&gt;I don&amp;#8217;t find that there is anything ground breaking in this article, and it&amp;#8217;s predecessor.  Hubs have been around since the dawn of computers in the form of configuration screens.  Wizards haven&amp;#8217;t been around for as long, but they have been out there for the last several releases of the Microsoft OS&amp;#8217;.  The guide is a fairly logical extension of the Wizard, that I have been using for a couple years and have seen around.&lt;/p&gt;

	&lt;p&gt;That said it was nice to see them all compared to each other in a clear and concise manner.  It&amp;#8217;s a little analysis I never bothered to do, and will probably be useful down the road.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1901</link>
      <guid>http://www.boxesandarrows.com/view/wizards_and_guides_principles_of_task_flow_for_web_applications_part_2#content_1901</guid>
      <pubDate>Fri, 26 Jan 2007 14:51:52 GMT</pubDate>
      <author>Ben Liyanage</author>
    </item>
  </channel>
</rss>
