"Intuitive" designs can be cumbersome

12 Aug 2004 - 2:00pm
10 years ago
15 replies
631 reads
sandeepblues
2003

I am transitioning from one thread re. "Hierarchical
gui and multiselection" to this one.

There are so many cases in IxD where a certain design
would be
(a) far more easy to use in the long run,
(b) require far less interaction and work on the part
of the user, and
(c)be far less "in the face"

but that design is either non-intuitive or
unconventional.

As a very geeky but pertinent example, consider the
process of finding out the IP address on your client
machine on Windows. One way is to open up the shell
window, and do what UI designers frequently pooh-pooh
Unix for. Use the command line and type ipconfig.
Now, try doing that via the Windows GUI. Yet, one can
give a strong case for the non-system administrator
user, that the GUI method is better. But, will that
user ever learn "ipconfig"? If not, then isn't that a
failure of IxD? Perhaps, it is a failure of MS GUI
design?? What GUI could compete with ipconfig
command-line?

Moral of story:

Going back to a topic many months ago, how does one
balance simplicity for the simpleton and mediocrity
for the majority of user? I am constantly hounded by
this dilemma, in my designs. How can IxD transition a
beginner UI to a intermediate UI? Doesn't the
beginner UI train the user in bad habits, that will
prevent the user from increasing skills?

Please give examples of UIs that have succeeded in
solving this problem. Thanks.

The second question: how to convince management to
allow a functionality to be designed in 2 modes:
"beginner" and "intermediate", when the "simple",
"intuitive", "beginner" but "mediocre" UI is so darn
"appealing", "conventional", and "safe".

Sandeep

--- "Svoboda, Eric" <Eric.Svoboda at maritz.com> wrote:

> Sandeep-
>
> I know you're trying to limit server trips, but is
> it really so
> important to do so? If you could concede a little on
> this goal, it seems
> that the easiest thing for a user to model would be
> the standard
> drill-down menu with a breadcrumbs, with the final
> selection pages using
> checkboxes. It's so widely used on the web that
> users will "get it"
> instantly. I realize they'll also be getting a
> little latency as they
> traverse this kind of menu, but it might be a good
> trade off to make for
> keeping the experience simple.
>
> Eric
>
> -----Original Message-----
> From:
>
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
>
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
> ers.com] On Behalf Of Sandeep Jain
> Sent: Thursday, August 12, 2004 12:49 PM
> To: id-discuss
> Subject: RE: [ID Discuss] Hierarchical gui and
> multiselection
>
> Precisely. This is a file-browsing style operation.
>
> However, I have not seen that style of operation
> represented in HTML
> design. My proposed solution is the the Open dialog
> design, but inside
> a webpage.
>
> My question is whether I am stepping on or ignoring
> alternate web
> conventions by doing so. Instead of icons for the
> folders, I was
> thinking of adding a "..." to the end of items that
> a folders..since the
> selectbox doesn't allow images.
>
> Every time I come up with a novel idea, I get burnt
> by marketing for not
> following conventions. This isn't a "novel" idea,
> except in the context
> of web design for this style of operation, I have
> not seen reasonable
> alternatives.
>
> Sandeep
>
> --- Mark Canlas <mark at htmlism.com> wrote:
>
> > It just sounds like a regular file-browsing type
> operation. Maybe you
> > should try looking at the Open/Save dialog used in
> Mac OS X (or
> > Windows maybe?). I think it uses a combination of
> breadcrumb trails
> > and columns to browse through multiple folders
> (levels), leaving the
> > user only able to select from the children of the
> current parent.
> >
> > By the way, as for making round trips to the
> server, you could always
> > store the entire tree in a portable format and
> generate the menu on
> > the fly, using DHTML or whatever rendering engine.
> So, for a web
> > interface, the time to display the menu would be
> as fast as the
> > client's computer (unlike a PHP-based solution,
> which to me seems a
> > bit too kludgy).
> >
> > Mark Canlas
> > http://www.htmlism.com/mark/
> > -----Original Message-----
> > From:
> >
>
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
> >
>
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
> ers.
> > com] On Behalf Of Sandeep Jain
> > Sent: Tuesday, August 10, 2004 5:51 PM
> > To: id-discuss
> > Subject: [ID Discuss] Hierarchical gui and
> multiselection
> >
> > What would be a reasonable web-based design for
> the problem below,
> > that doesn't assume Flash?
> >
> > (1)Suppose that there is an N-level hierarchical
> set of items, and you
>
> > want the user to navigate through the hierarchy
> till there are a set
> > of children items that the user wants.
> >
> > (2)At this point, the user would like to
> multi-select items at that
> > level.
> >
> > (3)However, the domain is such that the user
> should not be allowed to
> > select items from multiple parents.
> >
> > (4) It's probably not very useful to have many
> roundtrips to the
> > server, each time a parent item is opened.
> >
> > I came up with a Javascript design which is
> conventional in Windows,
> > but unconventional in HTML, as follows.
> >
> > The design is essentially an icon-less, Windows
> Explorer, without any
> > treeview on the left, and the itemview would be in
> list view.
> >
> > Details -> There would be a combo-box listing the
> parents going up to
> > the root of the tree, and a selection box, below
> it, which shows the
> > children for the current parent. The combo-box
> will always display
> > the current parent. Any item in the selection box
> which is also a
> > parent would have an ellipsis (...) next to its
> name. Also, to the
> > right of the combo box would be 2 buttons with an
> "Up" icon and text,
> > and to the right of the selection box, there would
> be a "Down" icon
> > and text to step through the hierarchy.
> >
> > Bad design? Is there something more conventional
> that could be used?
> >
> > If I were to remove constraint (4), would your
> design change? Would
> > you design be different if N(levels)=5?
> >
> > Sandeep
> > _______________________________________________
> > Interaction Design Discussion List
> > discuss at ixdg.org
> > --
> > to change your options (unsubscribe or set
> digest):
> > http://discuss.ixdg.org/
> > --
> > Questions: lists at ixdg.org
> > --
> > Announcement Online List (discussion list members
> get announcements
> > already) http://subscribe-announce.ixdg.org/
> > --
> > http://ixdg.org/
> >
> >
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members
> get announcements
> already) http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>
>
> Confidentiality Warning: This e-mail contains
> information intended only for the use of the
> individual or entity named above. If the reader of
> this e-mail is not the intended recipient or the
> employee or agent responsible for delivering it to
> the intended recipient, any dissemination,
> publication or copying of this e-mail is strictly
> prohibited. The sender does not accept any
> responsibility for any loss, disruption or damage to
> your data or computer system that may occur while
> using data contained in, or transmitted with, this
> e-mail. If you have received this e-mail in error,
> please immediately notify us by return e-mail.
> Thank you.
>
>
=== message truncated ===

Comments

12 Aug 2004 - 2:59pm
Mark Canlas
2003

I tried to meditate on this for a minute or two and this is the best that I
could come up with.

Let's start with power users. Power users are powered because they get to
say or do as much as they want in as little effort/words as possible.
Example, I get to find out the IP address and network configuration info of
my localhost by typing in ipconfig. That's it, I'm done. You're right, maybe
in the long run, that is the preferred mode.

But the problem is new users, who basically don't know how to speak such a
terse language. Since they might know only points and clicks, you might have
to explain to them the concept of obtaining an IP address using only points
and clicks.

So, the habits that new users learn aren't necessarily bad ones... They just
become less appropriate or less efficient over time (provided these users
are being directly converted into power users over time).

So, I guess the challenge, as I see it, is to find that sweet spot that
meets the advanced users and the beginners, all in one interface. That's
being able to let powers say what they want in as few words as possible, and
still carry out that same message to new users.

The thing that has always bugged me is this quest for two different
interfaces... I don't really see the need, or how it would work. Two
different interfaces just adds another choice for the user to make. While
one might think it's easy to differentiate between novice and advanced, what
about mediocre users? Where do they fall in? Will using the simple interface
make them feel bad? And two interfaces is just more work for you, the
implementer...

Examples... I dunno, Google? Google is simple, powerful, and user-friendly,
no? AutoCAD had this keyboard/graphical hybrid I've always been fond of...

Keep it simple, I guess.

Mark Canlas
http://www.htmlism.com/mark/

> -----Original Message-----
> From: discuss-interactiondesigners.com-
> bounces at lists.interactiondesigners.com [mailto:discuss-
> interactiondesigners.com-bounces at lists.interactiondesigners.com] On Behalf
> Of Sandeep Jain
> Sent: Thursday, August 12, 2004 3:01 PM
> To: Svoboda, Eric; id-discuss
> Subject: [ID Discuss] "Intuitive" designs can be cumbersome
>
> I am transitioning from one thread re. "Hierarchical
> gui and multiselection" to this one.
>
> There are so many cases in IxD where a certain design
> would be
> (a) far more easy to use in the long run,
> (b) require far less interaction and work on the part
> of the user, and
> (c)be far less "in the face"
>
> but that design is either non-intuitive or
> unconventional.
>
> As a very geeky but pertinent example, consider the
> process of finding out the IP address on your client
> machine on Windows. One way is to open up the shell
> window, and do what UI designers frequently pooh-pooh
> Unix for. Use the command line and type ipconfig.
> Now, try doing that via the Windows GUI. Yet, one can
> give a strong case for the non-system administrator
> user, that the GUI method is better. But, will that
> user ever learn "ipconfig"? If not, then isn't that a
> failure of IxD? Perhaps, it is a failure of MS GUI
> design?? What GUI could compete with ipconfig
> command-line?
>
> Moral of story:
>
> Going back to a topic many months ago, how does one
> balance simplicity for the simpleton and mediocrity
> for the majority of user? I am constantly hounded by
> this dilemma, in my designs. How can IxD transition a
> beginner UI to a intermediate UI? Doesn't the
> beginner UI train the user in bad habits, that will
> prevent the user from increasing skills?
>
> Please give examples of UIs that have succeeded in
> solving this problem. Thanks.
>
> The second question: how to convince management to
> allow a functionality to be designed in 2 modes:
> "beginner" and "intermediate", when the "simple",
> "intuitive", "beginner" but "mediocre" UI is so darn
> "appealing", "conventional", and "safe".
>
> Sandeep
>
> --- "Svoboda, Eric" <Eric.Svoboda at maritz.com> wrote:
>
> > Sandeep-
> >
> > I know you're trying to limit server trips, but is
> > it really so
> > important to do so? If you could concede a little on
> > this goal, it seems
> > that the easiest thing for a user to model would be
> > the standard
> > drill-down menu with a breadcrumbs, with the final
> > selection pages using
> > checkboxes. It's so widely used on the web that
> > users will "get it"
> > instantly. I realize they'll also be getting a
> > little latency as they
> > traverse this kind of menu, but it might be a good
> > trade off to make for
> > keeping the experience simple.
> >
> > Eric
> >
> > -----Original Message-----
> > From:
> >
> discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
> >
> [mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
> > ers.com] On Behalf Of Sandeep Jain
> > Sent: Thursday, August 12, 2004 12:49 PM
> > To: id-discuss
> > Subject: RE: [ID Discuss] Hierarchical gui and
> > multiselection
> >
> > Precisely. This is a file-browsing style operation.
> >
> > However, I have not seen that style of operation
> > represented in HTML
> > design. My proposed solution is the the Open dialog
> > design, but inside
> > a webpage.
> >
> > My question is whether I am stepping on or ignoring
> > alternate web
> > conventions by doing so. Instead of icons for the
> > folders, I was
> > thinking of adding a "..." to the end of items that
> > a folders..since the
> > selectbox doesn't allow images.
> >
> > Every time I come up with a novel idea, I get burnt
> > by marketing for not
> > following conventions. This isn't a "novel" idea,
> > except in the context
> > of web design for this style of operation, I have
> > not seen reasonable
> > alternatives.
> >
> > Sandeep
> >
> > --- Mark Canlas <mark at htmlism.com> wrote:
> >
> > > It just sounds like a regular file-browsing type
> > operation. Maybe you
> > > should try looking at the Open/Save dialog used in
> > Mac OS X (or
> > > Windows maybe?). I think it uses a combination of
> > breadcrumb trails
> > > and columns to browse through multiple folders
> > (levels), leaving the
> > > user only able to select from the children of the
> > current parent.
> > >
> > > By the way, as for making round trips to the
> > server, you could always
> > > store the entire tree in a portable format and
> > generate the menu on
> > > the fly, using DHTML or whatever rendering engine.
> > So, for a web
> > > interface, the time to display the menu would be
> > as fast as the
> > > client's computer (unlike a PHP-based solution,
> > which to me seems a
> > > bit too kludgy).
> > >
> > > Mark Canlas
> > > http://www.htmlism.com/mark/
> > > -----Original Message-----
> > > From:
> > >
> >
> discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
> > >
> >
> [mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
> > ers.
> > > com] On Behalf Of Sandeep Jain
> > > Sent: Tuesday, August 10, 2004 5:51 PM
> > > To: id-discuss
> > > Subject: [ID Discuss] Hierarchical gui and
> > multiselection
> > >
> > > What would be a reasonable web-based design for
> > the problem below,
> > > that doesn't assume Flash?
> > >
> > > (1)Suppose that there is an N-level hierarchical
> > set of items, and you
> >
> > > want the user to navigate through the hierarchy
> > till there are a set
> > > of children items that the user wants.
> > >
> > > (2)At this point, the user would like to
> > multi-select items at that
> > > level.
> > >
> > > (3)However, the domain is such that the user
> > should not be allowed to
> > > select items from multiple parents.
> > >
> > > (4) It's probably not very useful to have many
> > roundtrips to the
> > > server, each time a parent item is opened.
> > >
> > > I came up with a Javascript design which is
> > conventional in Windows,
> > > but unconventional in HTML, as follows.
> > >
> > > The design is essentially an icon-less, Windows
> > Explorer, without any
> > > treeview on the left, and the itemview would be in
> > list view.
> > >
> > > Details -> There would be a combo-box listing the
> > parents going up to
> > > the root of the tree, and a selection box, below
> > it, which shows the
> > > children for the current parent. The combo-box
> > will always display
> > > the current parent. Any item in the selection box
> > which is also a
> > > parent would have an ellipsis (...) next to its
> > name. Also, to the
> > > right of the combo box would be 2 buttons with an
> > "Up" icon and text,
> > > and to the right of the selection box, there would
> > be a "Down" icon
> > > and text to step through the hierarchy.
> > >
> > > Bad design? Is there something more conventional
> > that could be used?
> > >
> > > If I were to remove constraint (4), would your
> > design change? Would
> > > you design be different if N(levels)=5?
> > >
> > > Sandeep
> > > _______________________________________________
> > > Interaction Design Discussion List
> > > discuss at ixdg.org
> > > --
> > > to change your options (unsubscribe or set
> > digest):
> > > http://discuss.ixdg.org/
> > > --
> > > Questions: lists at ixdg.org
> > > --
> > > Announcement Online List (discussion list members
> > get announcements
> > > already) http://subscribe-announce.ixdg.org/
> > > --
> > > http://ixdg.org/
> > >
> > >
> >
> > _______________________________________________
> > Interaction Design Discussion List
> > discuss at ixdg.org
> > --
> > to change your options (unsubscribe or set digest):
> > http://discuss.ixdg.org/
> > --
> > Questions: lists at ixdg.org
> > --
> > Announcement Online List (discussion list members
> > get announcements
> > already) http://subscribe-announce.ixdg.org/
> > --
> > http://ixdg.org/
> >
> >
> > Confidentiality Warning: This e-mail contains
> > information intended only for the use of the
> > individual or entity named above. If the reader of
> > this e-mail is not the intended recipient or the
> > employee or agent responsible for delivering it to
> > the intended recipient, any dissemination,
> > publication or copying of this e-mail is strictly
> > prohibited. The sender does not accept any
> > responsibility for any loss, disruption or damage to
> > your data or computer system that may occur while
> > using data contained in, or transmitted with, this
> > e-mail. If you have received this e-mail in error,
> > please immediately notify us by return e-mail.
> > Thank you.
> >
> >
> === message truncated ===
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/

12 Aug 2004 - 3:38pm
Jonathan Grubb
2004

RE: ...how does one balance simplicity for the simpleton and mediocrity for
the majority of users...

I think Windows actually does a decent job at this.

If I want to save the email I'm typing, I can use a variety of methods:
Keyboard:
Control-s
Alt-f s
Alt-f c enter

Mouse
File > Save
File > Save As > Enter
File > Close > Save
Click on "Save" icon

If I were designing an interface from scratch I probably wouldn't create six
different methods to save a file, but I actually use each of these methods
for different situations.

As Microsoft added features for new users (mouse, iconic navigation, etc)
they kept the less intuitive but more powerful features in the interface
(control keys, alt-tab, etc). Many users will never know or care why some
letters are underlined in Windows menus, but those who do know find them
extremely useful.

For a user who can memorize commands and create a mental model of a file
structure, Unix is a great interface. The user types a command and the
computer does exactly the right thing; what could be better? For the rest of
us, there's windows.

- - - - - - - - - - - - -
Jonathan Grubb
Yahoo! Mobile GUI
Office: 408-349-6122
Mobile: 415-722-9449
- - - - - - - - - - - - -

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Sandeep Jain
Sent: Thursday, August 12, 2004 12:01 PM
To: Svoboda, Eric; id-discuss
Subject: [ID Discuss] "Intuitive" designs can be cumbersome

I am transitioning from one thread re. "Hierarchical
gui and multiselection" to this one.

There are so many cases in IxD where a certain design
would be
(a) far more easy to use in the long run,
(b) require far less interaction and work on the part
of the user, and
(c)be far less "in the face"

but that design is either non-intuitive or
unconventional.

As a very geeky but pertinent example, consider the
process of finding out the IP address on your client
machine on Windows. One way is to open up the shell
window, and do what UI designers frequently pooh-pooh
Unix for. Use the command line and type ipconfig.
Now, try doing that via the Windows GUI. Yet, one can
give a strong case for the non-system administrator
user, that the GUI method is better. But, will that
user ever learn "ipconfig"? If not, then isn't that a
failure of IxD? Perhaps, it is a failure of MS GUI
design?? What GUI could compete with ipconfig
command-line?

Moral of story:

Going back to a topic many months ago, how does one
balance simplicity for the simpleton and mediocrity
for the majority of user? I am constantly hounded by
this dilemma, in my designs. How can IxD transition a
beginner UI to a intermediate UI? Doesn't the
beginner UI train the user in bad habits, that will
prevent the user from increasing skills?

Please give examples of UIs that have succeeded in
solving this problem. Thanks.

The second question: how to convince management to
allow a functionality to be designed in 2 modes:
"beginner" and "intermediate", when the "simple",
"intuitive", "beginner" but "mediocre" UI is so darn
"appealing", "conventional", and "safe".

Sandeep

--- "Svoboda, Eric" <Eric.Svoboda at maritz.com> wrote:

> Sandeep-
>
> I know you're trying to limit server trips, but is
> it really so
> important to do so? If you could concede a little on
> this goal, it seems
> that the easiest thing for a user to model would be
> the standard
> drill-down menu with a breadcrumbs, with the final
> selection pages using
> checkboxes. It's so widely used on the web that
> users will "get it"
> instantly. I realize they'll also be getting a
> little latency as they
> traverse this kind of menu, but it might be a good
> trade off to make for
> keeping the experience simple.
>
> Eric
>
> -----Original Message-----
> From:
>
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
>
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
> ers.com] On Behalf Of Sandeep Jain
> Sent: Thursday, August 12, 2004 12:49 PM
> To: id-discuss
> Subject: RE: [ID Discuss] Hierarchical gui and
> multiselection
>
> Precisely. This is a file-browsing style operation.
>
> However, I have not seen that style of operation
> represented in HTML
> design. My proposed solution is the the Open dialog
> design, but inside
> a webpage.
>
> My question is whether I am stepping on or ignoring
> alternate web
> conventions by doing so. Instead of icons for the
> folders, I was
> thinking of adding a "..." to the end of items that
> a folders..since the
> selectbox doesn't allow images.
>
> Every time I come up with a novel idea, I get burnt
> by marketing for not
> following conventions. This isn't a "novel" idea,
> except in the context
> of web design for this style of operation, I have
> not seen reasonable
> alternatives.
>
> Sandeep
>
> --- Mark Canlas <mark at htmlism.com> wrote:
>
> > It just sounds like a regular file-browsing type
> operation. Maybe you
> > should try looking at the Open/Save dialog used in
> Mac OS X (or
> > Windows maybe?). I think it uses a combination of
> breadcrumb trails
> > and columns to browse through multiple folders
> (levels), leaving the
> > user only able to select from the children of the
> current parent.
> >
> > By the way, as for making round trips to the
> server, you could always
> > store the entire tree in a portable format and
> generate the menu on
> > the fly, using DHTML or whatever rendering engine.
> So, for a web
> > interface, the time to display the menu would be
> as fast as the
> > client's computer (unlike a PHP-based solution,
> which to me seems a
> > bit too kludgy).
> >
> > Mark Canlas
> > http://www.htmlism.com/mark/
> > -----Original Message-----
> > From:
> >
>
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
> >
>
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
> ers.
> > com] On Behalf Of Sandeep Jain
> > Sent: Tuesday, August 10, 2004 5:51 PM
> > To: id-discuss
> > Subject: [ID Discuss] Hierarchical gui and
> multiselection
> >
> > What would be a reasonable web-based design for
> the problem below,
> > that doesn't assume Flash?
> >
> > (1)Suppose that there is an N-level hierarchical
> set of items, and you
>
> > want the user to navigate through the hierarchy
> till there are a set
> > of children items that the user wants.
> >
> > (2)At this point, the user would like to
> multi-select items at that
> > level.
> >
> > (3)However, the domain is such that the user
> should not be allowed to
> > select items from multiple parents.
> >
> > (4) It's probably not very useful to have many
> roundtrips to the
> > server, each time a parent item is opened.
> >
> > I came up with a Javascript design which is
> conventional in Windows,
> > but unconventional in HTML, as follows.
> >
> > The design is essentially an icon-less, Windows
> Explorer, without any
> > treeview on the left, and the itemview would be in
> list view.
> >
> > Details -> There would be a combo-box listing the
> parents going up to
> > the root of the tree, and a selection box, below
> it, which shows the
> > children for the current parent. The combo-box
> will always display
> > the current parent. Any item in the selection box
> which is also a
> > parent would have an ellipsis (...) next to its
> name. Also, to the
> > right of the combo box would be 2 buttons with an
> "Up" icon and text,
> > and to the right of the selection box, there would
> be a "Down" icon
> > and text to step through the hierarchy.
> >
> > Bad design? Is there something more conventional
> that could be used?
> >
> > If I were to remove constraint (4), would your
> design change? Would
> > you design be different if N(levels)=5?
> >
> > Sandeep
> > _______________________________________________
> > Interaction Design Discussion List
> > discuss at ixdg.org
> > --
> > to change your options (unsubscribe or set
> digest):
> > http://discuss.ixdg.org/
> > --
> > Questions: lists at ixdg.org
> > --
> > Announcement Online List (discussion list members
> get announcements
> > already) http://subscribe-announce.ixdg.org/
> > --
> > http://ixdg.org/
> >
> >
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members
> get announcements
> already) http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>
>
> Confidentiality Warning: This e-mail contains
> information intended only for the use of the
> individual or entity named above. If the reader of
> this e-mail is not the intended recipient or the
> employee or agent responsible for delivering it to
> the intended recipient, any dissemination,
> publication or copying of this e-mail is strictly
> prohibited. The sender does not accept any
> responsibility for any loss, disruption or damage to
> your data or computer system that may occur while
> using data contained in, or transmitted with, this
> e-mail. If you have received this e-mail in error,
> please immediately notify us by return e-mail.
> Thank you.
>
>
=== message truncated ===

_______________________________________________
Interaction Design Discussion List
discuss at ixdg.org
--
to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
--
Questions: lists at ixdg.org
--
Announcement Online List (discussion list members get announcements already)
http://subscribe-announce.ixdg.org/
--
http://ixdg.org/

12 Aug 2004 - 3:46pm
sandeepblues
2003

Google is a very simple app. It does Internet
searches, and it is hard to find fault with its
results, since the content on the web is
unconstrained. I have heard of the AutoCad feature,
but isn't that a 2-interfaces design?

Studies have shown that user skill-levels fall in a
bell-curve. Majority of the users stay in the
intermediate levels of skill. So, I am a little less
concerned with "experts", but more with frequent users
of a product who are stuck with a beginner's user
experience, and they don't know that things could be
better.

A frequent problem is that beginner IxD of 10 years
ago have become conventions that hold back new designs
for the "new" computer-savvy users. To what extent
can one rely on a user to explore and discover new
interactions/designs? Marketing would respond that it
is too dangerous. Familiarity is key to acceptance.
Simplicity of yesteryears seems mediocre today.

Sandeep

--- Mark Canlas <mark at htmlism.com> wrote:

> I tried to meditate on this for a minute or two and
> this is the best that I
> could come up with.
>
> Let's start with power users. Power users are
> powered because they get to
> say or do as much as they want in as little
> effort/words as possible.
> Example, I get to find out the IP address and
> network configuration info of
> my localhost by typing in ipconfig. That's it, I'm
> done. You're right, maybe
> in the long run, that is the preferred mode.
>
> But the problem is new users, who basically don't
> know how to speak such a
> terse language. Since they might know only points
> and clicks, you might have
> to explain to them the concept of obtaining an IP
> address using only points
> and clicks.
>
> So, the habits that new users learn aren't
> necessarily bad ones... They just
> become less appropriate or less efficient over time
> (provided these users
> are being directly converted into power users over
> time).
>
> So, I guess the challenge, as I see it, is to find
> that sweet spot that
> meets the advanced users and the beginners, all in
> one interface. That's
> being able to let powers say what they want in as
> few words as possible, and
> still carry out that same message to new users.
>
> The thing that has always bugged me is this quest
> for two different
> interfaces... I don't really see the need, or how it
> would work. Two
> different interfaces just adds another choice for
> the user to make. While
> one might think it's easy to differentiate between
> novice and advanced, what
> about mediocre users? Where do they fall in? Will
> using the simple interface
> make them feel bad? And two interfaces is just more
> work for you, the
> implementer...
>
> Examples... I dunno, Google? Google is simple,
> powerful, and user-friendly,
> no? AutoCAD had this keyboard/graphical hybrid I've
> always been fond of...
>
> Keep it simple, I guess.
>
> Mark Canlas
> http://www.htmlism.com/mark/
>
> > -----Original Message-----
> > From: discuss-interactiondesigners.com-
> > bounces at lists.interactiondesigners.com
> [mailto:discuss-
> >
>
interactiondesigners.com-bounces at lists.interactiondesigners.com]
> On Behalf
> > Of Sandeep Jain
> > Sent: Thursday, August 12, 2004 3:01 PM
> > To: Svoboda, Eric; id-discuss
> > Subject: [ID Discuss] "Intuitive" designs can be
> cumbersome
> >
> > I am transitioning from one thread re.
> "Hierarchical
> > gui and multiselection" to this one.
> >
> > There are so many cases in IxD where a certain
> design
> > would be
> > (a) far more easy to use in the long run,
> > (b) require far less interaction and work on the
> part
> > of the user, and
> > (c)be far less "in the face"
> >
> > but that design is either non-intuitive or
> > unconventional.
> >
> > As a very geeky but pertinent example, consider
> the
> > process of finding out the IP address on your
> client
> > machine on Windows. One way is to open up the
> shell
> > window, and do what UI designers frequently
> pooh-pooh
> > Unix for. Use the command line and type ipconfig.
> > Now, try doing that via the Windows GUI. Yet, one
> can
> > give a strong case for the non-system
> administrator
> > user, that the GUI method is better. But, will
> that
> > user ever learn "ipconfig"? If not, then isn't
> that a
> > failure of IxD? Perhaps, it is a failure of MS GUI
> > design?? What GUI could compete with ipconfig
> > command-line?
> >
> > Moral of story:
> >
> > Going back to a topic many months ago, how does
> one
> > balance simplicity for the simpleton and
> mediocrity
> > for the majority of user? I am constantly hounded
> by
> > this dilemma, in my designs. How can IxD
> transition a
> > beginner UI to a intermediate UI? Doesn't the
> > beginner UI train the user in bad habits, that
> will
> > prevent the user from increasing skills?
> >
> > Please give examples of UIs that have succeeded in
> > solving this problem. Thanks.
> >
> > The second question: how to convince management to
> > allow a functionality to be designed in 2 modes:
> > "beginner" and "intermediate", when the "simple",
> > "intuitive", "beginner" but "mediocre" UI is so
> darn
> > "appealing", "conventional", and "safe".
> >
> > Sandeep
> >
> > --- "Svoboda, Eric" <Eric.Svoboda at maritz.com>
> wrote:
> >
> > > Sandeep-
> > >
> > > I know you're trying to limit server trips, but
> is
> > > it really so
> > > important to do so? If you could concede a
> little on
> > > this goal, it seems
> > > that the easiest thing for a user to model would
> be
> > > the standard
> > > drill-down menu with a breadcrumbs, with the
> final
> > > selection pages using
> > > checkboxes. It's so widely used on the web that
> > > users will "get it"
> > > instantly. I realize they'll also be getting a
> > > little latency as they
> > > traverse this kind of menu, but it might be a
> good
> > > trade off to make for
> > > keeping the experience simple.
> > >
> > > Eric
> > >
> > > -----Original Message-----
> > > From:
> > >
> >
>
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
> > >
> >
>
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
> > > ers.com] On Behalf Of Sandeep Jain
> > > Sent: Thursday, August 12, 2004 12:49 PM
> > > To: id-discuss
> > > Subject: RE: [ID Discuss] Hierarchical gui and
> > > multiselection
> > >
> > > Precisely. This is a file-browsing style
> operation.
> > >
> > > However, I have not seen that style of operation
> > > represented in HTML
> > > design. My proposed solution is the the Open
> dialog
> > > design, but inside
> > > a webpage.
> > >
> > > My question is whether I am stepping on or
> ignoring
> > > alternate web
> > > conventions by doing so. Instead of icons for
> the
> > > folders, I was
> > > thinking of adding a "..." to the end of items
> that
> > > a folders..since the
> > > selectbox doesn't allow images.
> > >
>
=== message truncated ===

12 Aug 2004 - 4:07pm
sandeepblues
2003

Agreed. Shortcuts and mnemonics are quite useful.

I also agree that memorizing commands is not for
everyone (and not for most). Perhaps, a problem is the
names of commands.

Perhaps, there should be a search limited to things
about one's machine...So, someone types "ip address",
"ip config" or whatever, and pop comes the ipaddress
of the machine, and perhaps a link to related
info...or pop comes the window which the user would
typically navigate to.

As far as windows doing a good job...mnemonics etc
have been around for a gazillion years in products
before MS Office. As usual, they copied well. But
try this...show a user how to get the ip address via
GUI (it will take a while for them to find it
themselves), and then show them how to use ipconfig.
Then, ask them to find the ip address on some Windows
machine. Guess which way they will go.

Sandeep

--- Jonathan Grubb <jgrubb at yahoo-inc.com> wrote:

> RE: ...how does one balance simplicity for the
> simpleton and mediocrity for
> the majority of users...
>
> I think Windows actually does a decent job at this.
>
> If I want to save the email I'm typing, I can use a
> variety of methods:
> Keyboard:
> Control-s
> Alt-f s
> Alt-f c enter
>
> Mouse
> File > Save
> File > Save As > Enter
> File > Close > Save
> Click on "Save" icon
>
> If I were designing an interface from scratch I
> probably wouldn't create six
> different methods to save a file, but I actually use
> each of these methods
> for different situations.
>
> As Microsoft added features for new users (mouse,
> iconic navigation, etc)
> they kept the less intuitive but more powerful
> features in the interface
> (control keys, alt-tab, etc). Many users will never
> know or care why some
> letters are underlined in Windows menus, but those
> who do know find them
> extremely useful.
>
> For a user who can memorize commands and create a
> mental model of a file
> structure, Unix is a great interface. The user types
> a command and the
> computer does exactly the right thing; what could be
> better? For the rest of
> us, there's windows.
>
> - - - - - - - - - - - - -
> Jonathan Grubb
> Yahoo! Mobile GUI
> Office: 408-349-6122
> Mobile: 415-722-9449
> - - - - - - - - - - - - -
>
>
> -----Original Message-----
> From:
>
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
>
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
> com] On Behalf Of Sandeep Jain
> Sent: Thursday, August 12, 2004 12:01 PM
> To: Svoboda, Eric; id-discuss
> Subject: [ID Discuss] "Intuitive" designs can be
> cumbersome
>
> I am transitioning from one thread re. "Hierarchical
> gui and multiselection" to this one.
>
> There are so many cases in IxD where a certain
> design
> would be
> (a) far more easy to use in the long run,
> (b) require far less interaction and work on the
> part
> of the user, and
> (c)be far less "in the face"
>
> but that design is either non-intuitive or
> unconventional.
>
> As a very geeky but pertinent example, consider the
> process of finding out the IP address on your client
> machine on Windows. One way is to open up the shell
> window, and do what UI designers frequently
> pooh-pooh
> Unix for. Use the command line and type ipconfig.
> Now, try doing that via the Windows GUI. Yet, one
> can
> give a strong case for the non-system administrator
> user, that the GUI method is better. But, will that
> user ever learn "ipconfig"? If not, then isn't that
> a
> failure of IxD? Perhaps, it is a failure of MS GUI
> design?? What GUI could compete with ipconfig
> command-line?
>
> Moral of story:
>
> Going back to a topic many months ago, how does one
> balance simplicity for the simpleton and mediocrity
> for the majority of user? I am constantly hounded by
> this dilemma, in my designs. How can IxD transition
> a
> beginner UI to a intermediate UI? Doesn't the
> beginner UI train the user in bad habits, that will
> prevent the user from increasing skills?
>
> Please give examples of UIs that have succeeded in
> solving this problem. Thanks.
>
> The second question: how to convince management to
> allow a functionality to be designed in 2 modes:
> "beginner" and "intermediate", when the "simple",
> "intuitive", "beginner" but "mediocre" UI is so darn
> "appealing", "conventional", and "safe".
>
> Sandeep
>
> --- "Svoboda, Eric" <Eric.Svoboda at maritz.com> wrote:
>
> > Sandeep-
> >
> > I know you're trying to limit server trips, but is
> > it really so
> > important to do so? If you could concede a little
> on
> > this goal, it seems
> > that the easiest thing for a user to model would
> be
> > the standard
> > drill-down menu with a breadcrumbs, with the final
> > selection pages using
> > checkboxes. It's so widely used on the web that
> > users will "get it"
> > instantly. I realize they'll also be getting a
> > little latency as they
> > traverse this kind of menu, but it might be a good
> > trade off to make for
> > keeping the experience simple.
> >
> > Eric
> >
> > -----Original Message-----
> > From:
> >
>
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
> >
>
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
> > ers.com] On Behalf Of Sandeep Jain
> > Sent: Thursday, August 12, 2004 12:49 PM
> > To: id-discuss
> > Subject: RE: [ID Discuss] Hierarchical gui and
> > multiselection
> >
> > Precisely. This is a file-browsing style
> operation.
> >
> > However, I have not seen that style of operation
> > represented in HTML
> > design. My proposed solution is the the Open
> dialog
> > design, but inside
> > a webpage.
> >
> > My question is whether I am stepping on or
> ignoring
> > alternate web
> > conventions by doing so. Instead of icons for the
> > folders, I was
> > thinking of adding a "..." to the end of items
> that
> > a folders..since the
> > selectbox doesn't allow images.
> >
> > Every time I come up with a novel idea, I get
> burnt
> > by marketing for not
> > following conventions. This isn't a "novel" idea,
> > except in the context
> > of web design for this style of operation, I have
> > not seen reasonable
> > alternatives.
> >
> > Sandeep
> >
> > --- Mark Canlas <mark at htmlism.com> wrote:
> >
> > > It just sounds like a regular file-browsing type
> > operation. Maybe you
> > > should try looking at the Open/Save dialog used
> in
> > Mac OS X (or
> > > Windows maybe?). I think it uses a combination
> of
> > breadcrumb trails
> > > and columns to browse through multiple folders
> > (levels), leaving the
> > > user only able to select from the children of
> the
> > current parent.
> > >
> > > By the way, as for making round trips to the
> > server, you could always
> > > store the entire tree in a portable format and
> > generate the menu on
>
=== message truncated ===

12 Aug 2004 - 4:46pm
Jim McCusker
2004

Jonathan Grubb wrote:

>For a user who can memorize commands and create a mental model of a file
>structure, Unix is a great interface. The user types a command and the
>computer does exactly the right thing; what could be better? For the rest of
>us, there's windows.
>
>
I just have to take issue with your assumptions about Unix. While yes,
historically, command line interfaces have been difficult to learn,
there have been many strides. Take tab-completion for example. Tab
completion is like IntelliSense (except years older) for the command
line. Today, modern CLI shells like Bash have very sophisticated
completion. Hit tab twice, and you get a full list of available
commands. Or start typing, and hit tab, and you'll get a list of the
commands that match up to that point. If there's only one, then you get
a finished name. You can do the same for files as well as commands. I
hardly use 'ls' anymore, because I just tab-complete on whatever I'm
looking at. There are even plugins for tab-completion for flags and
other non-file options to command line programs. I used to detest using
a command line, until I discoverd how to use a modern one.

Tab completion makes the command line far more learnable than it used
to be, which means that I can go to a new system (with bash installed)
like OS X and be able to use it as well as I use linux or solaris,
without having to figure out up front what the differences are (there
are differences). I know that the command line has gotten a bad rap in
the interaction design community, but I think it was more of a bad start
than anything else. The command line on Unix today is nothing like the
one on Windows or DOS. I think that one reason it hasn't fared better is
because no one has yet figured out how to apply it to non-textual
interfaces, or how to spruce it up, since it does look utilitarian.

Jim

12 Aug 2004 - 4:56pm
Mike Beltzner
2004

Sandeep Jain wrote:

> There are so many cases in IxD where a certain design
> would be
> (a) far more easy to use in the long run,
> (b) require far less interaction and work on the part
> of the user, and
> (c)be far less "in the face"
>
> but that design is either non-intuitive or
> unconventional.

Totally agreed, and this is a point of frustration that many prominent
interaction designers have hit upon. Bill Buxton (formerly of Alias
Wavefront) and Jef Raskin both often rant about how -- aside from some
polish and far richer graphics -- we're still all stuck with a computing
metaphor that was created over a quarter of a century ago. Desktop,
folders, files, windows ... the primary metaphor, or convention, is
unaltered.

And there's plenty of interactions which would be far easier to use but
fall outside of that metaphor, or worse yet, interactions that could be
simpler if they weren't shoe-horned into that metaphor.

> As a very geeky but pertinent example, consider the
> process of finding out the IP address on your client
> machine on Windows. One way is to open up the shell

I'm not sure I agree that this is a pertinent example. After lamenting
the crappi GUI support for determining a machine's IP information, you say:

> But, will that user ever learn "ipconfig"?
> If not, then isn't that a failure of IxD?
> Perhaps, it is a failure of MS GUI

I think it's more likely that it's "as-designed" as far as MS GUI goes.
Why should the user ever need to know this information other than in
cases of reporting something to a more advanced user? Details like IP
addresses shouldn't be in the user's cognitive space. And any advanced
user would likely shun a fancy GUI for the command-line.

Regardless, you should check out XP. They've done some nice stuff for IP
addresses, including: listing the IP address in the "About.." box of any
program (like NetMeeting) where it might be useful to have it;
displaying the IP address of an adapter when that adapter is selected in
"Network Connections"; showing all IP details when you dig into the
properties of a connection either through the system tray icon or the
control panel.

> design?? What GUI could compete with ipconfig
> command-line?

Compete on what criteria? I would argue that the above listed GUIs can
compete in terms of visual aesthetic and ease of discovery, while the
command line tool would kick ass in terms of speed and efficiency.

Beginners and intermediates have some goals in common, such as the
completion of the task, but beginners are sometimes also looking to
learn, and intermediates are looking to become more efficient and
speedy. Thus, beginner UIs need to be easy to discover and informative,
wheras intermediate UIs need to be efficient and minimalist.

Others have commented on accelerator keys as an example of succesful
blendings of begginer and intermediate UIs, and I'd actually list
Windows XP's support of determining IP configuration as another
successful blend. There are several ways to do so, inefficiently, using
the GUI methods for digging into system properties, and there's a single
way for the people who want to be speedy and already know what they're
doing.

> this dilemma, in my designs. How can IxD transition a
> beginner UI to a intermediate UI? Doesn't the

The transition is the hard part, and the source of one researcher's
entire work. Check out Joanna McGrenere's work on adaptive user
interfaces: http://www.cs.ubc.ca/~joanna/

Essentially, there are lots of ways to do it, but almost all of them
imply breaking a cardinal rule of IxD, in that they alter the user's
workspace without asking permission, either by revealing or hiding
function in order to tailor the interface to the user.

My gut feeling is that interfaces which support accelerators (either
mnemonics or other forms of accelerators, like context-menus, mouse
gestures, etc) that can be learned are the best way to support both
beginners and advanced users.

> Please give examples of UIs that have succeeded in
> solving this problem. Thanks.

A lot of games do this well, actually, too, but usually in the form of
introducing the user to progressively more complicated use cases. Most
other forms of software don't get the luxury of this explicit "training
phase".

> The second question: how to convince management to
> allow a functionality to be designed in 2 modes:

In my experience, it's best to design primary interaction paths for
beginners, and then convince management that you can build a loyal
market by adding secondary (accelerator) interaction paths that speed up
someone's interaction with the product. Point to examples like Ctrl+V
... everyone knows it means paste, but the primary way of getting to
paste is Edit > Paste. Still, nobody would buy a product that doesn't
support the secondary method, too.

> Perhaps, there should be a search limited to things
> about one's machine...So, someone types "ip address",
> "ip config" or whatever, and pop comes the ipaddress
> of the machine, and perhaps a link to related
> info...or pop comes the window which the user would
> typically navigate to.

I copied this in here because I also agree that this would be a
fantastic improvement in our UI metaphors ... UIs that try to figure out
what information a user is attempting to interact with. The Ximian
"Dashboard" project is a great example of how this could work.

cheers,
mike

12 Aug 2004 - 5:14pm
Schomer, Todd
2004

It's always a challenge to design for multiple user-levels, but it can
be done.

My thinking is that you can design something in such a way that a basic
user can navigate through each UI element, and get through it. There is
enough content in each dialog, for example, to understand the
capabilites of the program.

When the basic user has figured that much out, they can start to use
hotkeys for jumping through the UI faster.

For the power-user, I try to reduce the steps involved in getting from
point A to point B by adding things like presets for dialogs, which
configure all the settings with one menu choice, or preferences that
allow dialogs to be configured their way when they open them next time.
Or even modifier keys, which bypass steps - such as holding down the
Option key when deleting something and bypassing the warning message
that would normally appear.

Another thing I do with my designs is have all the defaults be the most
likely choices for the basic user, so if they forget to set something
up, or don't understand something, the product will most likely work for
them. (This is probably a "duh" but should still be mentioned, as I miss
this all too often in other people's products). It's like having a
setting for audio quality in iTunes. I shouldn't have to understand what
that means in order to rip a CD to MP3, so the setting should be set for
the most common choice and deliver me positive results without changing
the settings.

Last idea... To hide more advanced settings behind buttons, or in parts
of dialogs that expand when the user clicks an Advanced button or
twist-down control. Keep the basics in the main part of the dialog, and
let the user expand into more advanced controls.

Schomer

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com] On Behalf Of Mark Canlas
Sent: Thursday, August 12, 2004 12:59 PM
To: 'Sandeep Jain'; 'Svoboda, Eric'; 'id-discuss'
Subject: RE: [ID Discuss] "Intuitive" designs can be cumbersome

I tried to meditate on this for a minute or two and this is the best
that I could come up with.

Let's start with power users. Power users are powered because they get
to say or do as much as they want in as little effort/words as possible.
Example, I get to find out the IP address and network configuration info
of my localhost by typing in ipconfig. That's it, I'm done. You're
right, maybe in the long run, that is the preferred mode.

But the problem is new users, who basically don't know how to speak such
a terse language. Since they might know only points and clicks, you
might have to explain to them the concept of obtaining an IP address
using only points and clicks.

So, the habits that new users learn aren't necessarily bad ones... They
just become less appropriate or less efficient over time (provided these
users are being directly converted into power users over time).

So, I guess the challenge, as I see it, is to find that sweet spot that
meets the advanced users and the beginners, all in one interface. That's
being able to let powers say what they want in as few words as possible,
and still carry out that same message to new users.

The thing that has always bugged me is this quest for two different
interfaces... I don't really see the need, or how it would work. Two
different interfaces just adds another choice for the user to make.
While one might think it's easy to differentiate between novice and
advanced, what about mediocre users? Where do they fall in? Will using
the simple interface make them feel bad? And two interfaces is just more
work for you, the implementer...

Examples... I dunno, Google? Google is simple, powerful, and
user-friendly, no? AutoCAD had this keyboard/graphical hybrid I've
always been fond of...

Keep it simple, I guess.

Mark Canlas
http://www.htmlism.com/mark/

> -----Original Message-----
> From: discuss-interactiondesigners.com-
> bounces at lists.interactiondesigners.com [mailto:discuss-
> interactiondesigners.com-bounces at lists.interactiondesigners.com] On
> Behalf Of Sandeep Jain
> Sent: Thursday, August 12, 2004 3:01 PM
> To: Svoboda, Eric; id-discuss
> Subject: [ID Discuss] "Intuitive" designs can be cumbersome
>
> I am transitioning from one thread re. "Hierarchical gui and
> multiselection" to this one.
>
> There are so many cases in IxD where a certain design would be
> (a) far more easy to use in the long run,
> (b) require far less interaction and work on the part of the user, and

> (c)be far less "in the face"
>
> but that design is either non-intuitive or unconventional.
>
> As a very geeky but pertinent example, consider the process of finding

> out the IP address on your client machine on Windows. One way is to
> open up the shell window, and do what UI designers frequently
> pooh-pooh Unix for. Use the command line and type ipconfig.
> Now, try doing that via the Windows GUI. Yet, one can give a strong
> case for the non-system administrator user, that the GUI method is
> better. But, will that user ever learn "ipconfig"? If not, then isn't

> that a failure of IxD? Perhaps, it is a failure of MS GUI design??
> What GUI could compete with ipconfig command-line?
>
> Moral of story:
>
> Going back to a topic many months ago, how does one balance simplicity

> for the simpleton and mediocrity for the majority of user? I am
> constantly hounded by this dilemma, in my designs. How can IxD
> transition a beginner UI to a intermediate UI? Doesn't the beginner
> UI train the user in bad habits, that will prevent the user from
> increasing skills?
>
> Please give examples of UIs that have succeeded in solving this
> problem. Thanks.
>
> The second question: how to convince management to allow a
> functionality to be designed in 2 modes:
> "beginner" and "intermediate", when the "simple", "intuitive",
> "beginner" but "mediocre" UI is so darn "appealing", "conventional",
> and "safe".
>
> Sandeep
>
> --- "Svoboda, Eric" <Eric.Svoboda at maritz.com> wrote:
>
> > Sandeep-
> >
> > I know you're trying to limit server trips, but is it really so
> > important to do so? If you could concede a little on this goal, it
> > seems that the easiest thing for a user to model would be the
> > standard drill-down menu with a breadcrumbs, with the final
> > selection pages using checkboxes. It's so widely used on the web
> > that users will "get it"
> > instantly. I realize they'll also be getting a little latency as
> > they traverse this kind of menu, but it might be a good trade off to

> > make for keeping the experience simple.
> >
> > Eric
> >
> > -----Original Message-----
> > From:
> >
> discuss-interactiondesigners.com-bounces at lists.interactiondesigners.co
> m
> >
> [mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesi
> gn
> > ers.com] On Behalf Of Sandeep Jain
> > Sent: Thursday, August 12, 2004 12:49 PM
> > To: id-discuss
> > Subject: RE: [ID Discuss] Hierarchical gui and multiselection
> >
> > Precisely. This is a file-browsing style operation.
> >
> > However, I have not seen that style of operation represented in HTML

> > design. My proposed solution is the the Open dialog design, but
> > inside a webpage.
> >
> > My question is whether I am stepping on or ignoring alternate web
> > conventions by doing so. Instead of icons for the folders, I was
> > thinking of adding a "..." to the end of items that a folders..since

> > the selectbox doesn't allow images.
> >
> > Every time I come up with a novel idea, I get burnt by marketing for

> > not following conventions. This isn't a "novel" idea, except in the

> > context of web design for this style of operation, I have not seen
> > reasonable alternatives.
> >
> > Sandeep
> >
> > --- Mark Canlas <mark at htmlism.com> wrote:
> >
> > > It just sounds like a regular file-browsing type
> > operation. Maybe you
> > > should try looking at the Open/Save dialog used in
> > Mac OS X (or
> > > Windows maybe?). I think it uses a combination of
> > breadcrumb trails
> > > and columns to browse through multiple folders
> > (levels), leaving the
> > > user only able to select from the children of the
> > current parent.
> > >
> > > By the way, as for making round trips to the
> > server, you could always
> > > store the entire tree in a portable format and
> > generate the menu on
> > > the fly, using DHTML or whatever rendering engine.
> > So, for a web
> > > interface, the time to display the menu would be
> > as fast as the
> > > client's computer (unlike a PHP-based solution,
> > which to me seems a
> > > bit too kludgy).
> > >
> > > Mark Canlas
> > > http://www.htmlism.com/mark/
> > > -----Original Message-----
> > > From:
> > >
> >
> discuss-interactiondesigners.com-bounces at lists.interactiondesigners.co
> m
> > >
> >
> [mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesi
> gn
> > ers.
> > > com] On Behalf Of Sandeep Jain
> > > Sent: Tuesday, August 10, 2004 5:51 PM
> > > To: id-discuss
> > > Subject: [ID Discuss] Hierarchical gui and
> > multiselection
> > >
> > > What would be a reasonable web-based design for
> > the problem below,
> > > that doesn't assume Flash?
> > >
> > > (1)Suppose that there is an N-level hierarchical
> > set of items, and you
> >
> > > want the user to navigate through the hierarchy
> > till there are a set
> > > of children items that the user wants.
> > >
> > > (2)At this point, the user would like to
> > multi-select items at that
> > > level.
> > >
> > > (3)However, the domain is such that the user
> > should not be allowed to
> > > select items from multiple parents.
> > >
> > > (4) It's probably not very useful to have many
> > roundtrips to the
> > > server, each time a parent item is opened.
> > >
> > > I came up with a Javascript design which is
> > conventional in Windows,
> > > but unconventional in HTML, as follows.
> > >
> > > The design is essentially an icon-less, Windows
> > Explorer, without any
> > > treeview on the left, and the itemview would be in
> > list view.
> > >
> > > Details -> There would be a combo-box listing the
> > parents going up to
> > > the root of the tree, and a selection box, below
> > it, which shows the
> > > children for the current parent. The combo-box
> > will always display
> > > the current parent. Any item in the selection box
> > which is also a
> > > parent would have an ellipsis (...) next to its
> > name. Also, to the
> > > right of the combo box would be 2 buttons with an
> > "Up" icon and text,
> > > and to the right of the selection box, there would
> > be a "Down" icon
> > > and text to step through the hierarchy.
> > >
> > > Bad design? Is there something more conventional
> > that could be used?
> > >
> > > If I were to remove constraint (4), would your
> > design change? Would
> > > you design be different if N(levels)=5?
> > >
> > > Sandeep
> > > _______________________________________________
> > > Interaction Design Discussion List discuss at ixdg.org
> > > --
> > > to change your options (unsubscribe or set
> > digest):
> > > http://discuss.ixdg.org/
> > > --
> > > Questions: lists at ixdg.org
> > > --
> > > Announcement Online List (discussion list members
> > get announcements
> > > already) http://subscribe-announce.ixdg.org/
> > > --
> > > http://ixdg.org/
> > >
> > >
> >
> > _______________________________________________
> > Interaction Design Discussion List
> > discuss at ixdg.org
> > --
> > to change your options (unsubscribe or set digest):
> > http://discuss.ixdg.org/
> > --
> > Questions: lists at ixdg.org
> > --
> > Announcement Online List (discussion list members get announcements
> > already) http://subscribe-announce.ixdg.org/
> > --
> > http://ixdg.org/
> >
> >
> > Confidentiality Warning: This e-mail contains information intended
> > only for the use of the individual or entity named above. If the
> > reader of this e-mail is not the intended recipient or the employee
> > or agent responsible for delivering it to the intended recipient,
> > any dissemination, publication or copying of this e-mail is strictly

> > prohibited. The sender does not accept any responsibility for any
> > loss, disruption or damage to your data or computer system that may
> > occur while using data contained in, or transmitted with, this
> > e-mail. If you have received this e-mail in error,
> > please immediately notify us by return e-mail.
> > Thank you.
> >
> >
> === message truncated ===
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/

_______________________________________________
Interaction Design Discussion List
discuss at ixdg.org
--
to change your options (unsubscribe or set digest):
http://discuss.ixdg.org/
--
Questions: lists at ixdg.org
--
Announcement Online List (discussion list members get announcements
already) http://subscribe-announce.ixdg.org/
--
http://ixdg.org/

12 Aug 2004 - 5:41pm
sandeepblues
2003

In the WIMP world, there seem to be lots of
conventions for the "onion" model. Technical
constraints make an onion model in the web world quite
cumbersome.

I would be interested in moving this discussion to web
application design (without Flash), where frequently
the limitations of widgets/technology, and the power
of interpretive UI tech. mean that innovative, varied,
and unconventional designs are possible.

In other thread running currently (hierarchy and
multiselection), there is a discussion about how one
should achieve an "Open File Dialog" UI on the
web...in short how to navigate through a hierarchical
data set and multiselect children (not necessarily
leaves) under a single parent.

The intuitive web convention will be to have multiple
roundtrips to the server when the user clicks on
parent links to open them, and have checkboxes next to
each list of children. Very intuitive. Very
cumbersome.

Sandeep

--- "Schomer, Todd" <Schomer at extensis.com> wrote:

> It's always a challenge to design for multiple
> user-levels, but it can
> be done.
>
> My thinking is that you can design something in such
> a way that a basic
> user can navigate through each UI element, and get
> through it. There is
> enough content in each dialog, for example, to
> understand the
> capabilites of the program.
>
> When the basic user has figured that much out, they
> can start to use
> hotkeys for jumping through the UI faster.
>
> For the power-user, I try to reduce the steps
> involved in getting from
> point A to point B by adding things like presets for
> dialogs, which
> configure all the settings with one menu choice, or
> preferences that
> allow dialogs to be configured their way when they
> open them next time.
> Or even modifier keys, which bypass steps - such as
> holding down the
> Option key when deleting something and bypassing the
> warning message
> that would normally appear.
>
> Another thing I do with my designs is have all the
> defaults be the most
> likely choices for the basic user, so if they forget
> to set something
> up, or don't understand something, the product will
> most likely work for
> them. (This is probably a "duh" but should still be
> mentioned, as I miss
> this all too often in other people's products). It's
> like having a
> setting for audio quality in iTunes. I shouldn't
> have to understand what
> that means in order to rip a CD to MP3, so the
> setting should be set for
> the most common choice and deliver me positive
> results without changing
> the settings.
>
> Last idea... To hide more advanced settings behind
> buttons, or in parts
> of dialogs that expand when the user clicks an
> Advanced button or
> twist-down control. Keep the basics in the main part
> of the dialog, and
> let the user expand into more advanced controls.
>
> Schomer

12 Aug 2004 - 6:19pm
Simon King
2004

> The thing that has always bugged me is this quest for two different
> interfaces... I don't really see the need, or how it would work.

Two fully different interfaces are usually too much, but I like the idea of
including shortcuts and key commands for power users. I like the "tips"
feature some applications have which comes up when the program loads. Those
tips expose shortcuts to teach novice users, hopefully converting them to
power users. Usually they can be easily turned off once the user has learned
enough.

This happens less on the web, but 37 Signals has built a similar feature
into their Basecamp help system:
http://www.37signals.com/svn/archives/000608.php

Simon King

12 Aug 2004 - 6:48pm
Adlin, Tamara
2004

I like what Don Norman says: there is no such thing as an 'intuitive' design for the Web. Humans weren't wired to intuit things related to technology. The question is how quickly they can learn it. "Intuitive" really means (in this context) that it's super duper easy to learn (or that it's like you've already learned it). It's a nice way to change the discussion--what do you need to help novices learn, and what can you assume more experienced users already know. This can help direct design decisions better (in my experience) than trying to create something that's 'intuitive.'

Tamara

-----Original Message-----
From: discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com [mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com] On Behalf Of Schomer, Todd
Sent: Thursday, August 12, 2004 3:14 PM
To: id-discuss
Subject: RE: [ID Discuss] "Intuitive" designs can be cumbersome

It's always a challenge to design for multiple user-levels, but it can be done.

My thinking is that you can design something in such a way that a basic user can navigate through each UI element, and get through it. There is enough content in each dialog, for example, to understand the capabilites of the program.

When the basic user has figured that much out, they can start to use hotkeys for jumping through the UI faster.

For the power-user, I try to reduce the steps involved in getting from point A to point B by adding things like presets for dialogs, which configure all the settings with one menu choice, or preferences that allow dialogs to be configured their way when they open them next time.
Or even modifier keys, which bypass steps - such as holding down the Option key when deleting something and bypassing the warning message that would normally appear.

Another thing I do with my designs is have all the defaults be the most likely choices for the basic user, so if they forget to set something up, or don't understand something, the product will most likely work for them. (This is probably a "duh" but should still be mentioned, as I miss this all too often in other people's products). It's like having a setting for audio quality in iTunes. I shouldn't have to understand what that means in order to rip a CD to MP3, so the setting should be set for the most common choice and deliver me positive results without changing the settings.

Last idea... To hide more advanced settings behind buttons, or in parts of dialogs that expand when the user clicks an Advanced button or twist-down control. Keep the basics in the main part of the dialog, and let the user expand into more advanced controls.

Schomer

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com] On Behalf Of Mark Canlas
Sent: Thursday, August 12, 2004 12:59 PM
To: 'Sandeep Jain'; 'Svoboda, Eric'; 'id-discuss'
Subject: RE: [ID Discuss] "Intuitive" designs can be cumbersome

I tried to meditate on this for a minute or two and this is the best that I could come up with.

Let's start with power users. Power users are powered because they get to say or do as much as they want in as little effort/words as possible.
Example, I get to find out the IP address and network configuration info of my localhost by typing in ipconfig. That's it, I'm done. You're right, maybe in the long run, that is the preferred mode.

But the problem is new users, who basically don't know how to speak such a terse language. Since they might know only points and clicks, you might have to explain to them the concept of obtaining an IP address using only points and clicks.

So, the habits that new users learn aren't necessarily bad ones... They just become less appropriate or less efficient over time (provided these users are being directly converted into power users over time).

So, I guess the challenge, as I see it, is to find that sweet spot that meets the advanced users and the beginners, all in one interface. That's being able to let powers say what they want in as few words as possible, and still carry out that same message to new users.

The thing that has always bugged me is this quest for two different interfaces... I don't really see the need, or how it would work. Two different interfaces just adds another choice for the user to make.
While one might think it's easy to differentiate between novice and advanced, what about mediocre users? Where do they fall in? Will using the simple interface make them feel bad? And two interfaces is just more work for you, the implementer...

Examples... I dunno, Google? Google is simple, powerful, and user-friendly, no? AutoCAD had this keyboard/graphical hybrid I've always been fond of...

Keep it simple, I guess.

Mark Canlas
http://www.htmlism.com/mark/

> -----Original Message-----
> From: discuss-interactiondesigners.com-
> bounces at lists.interactiondesigners.com [mailto:discuss-
> interactiondesigners.com-bounces at lists.interactiondesigners.com] On
> Behalf Of Sandeep Jain
> Sent: Thursday, August 12, 2004 3:01 PM
> To: Svoboda, Eric; id-discuss
> Subject: [ID Discuss] "Intuitive" designs can be cumbersome
>
> I am transitioning from one thread re. "Hierarchical gui and
> multiselection" to this one.
>
> There are so many cases in IxD where a certain design would be
> (a) far more easy to use in the long run,
> (b) require far less interaction and work on the part of the user, and

> (c)be far less "in the face"
>
> but that design is either non-intuitive or unconventional.
>
> As a very geeky but pertinent example, consider the process of finding

> out the IP address on your client machine on Windows. One way is to
> open up the shell window, and do what UI designers frequently
> pooh-pooh Unix for. Use the command line and type ipconfig.
> Now, try doing that via the Windows GUI. Yet, one can give a strong
> case for the non-system administrator user, that the GUI method is
> better. But, will that user ever learn "ipconfig"? If not, then isn't

> that a failure of IxD? Perhaps, it is a failure of MS GUI design??
> What GUI could compete with ipconfig command-line?
>
> Moral of story:
>
> Going back to a topic many months ago, how does one balance simplicity

> for the simpleton and mediocrity for the majority of user? I am
> constantly hounded by this dilemma, in my designs. How can IxD
> transition a beginner UI to a intermediate UI? Doesn't the beginner
> UI train the user in bad habits, that will prevent the user from
> increasing skills?
>
> Please give examples of UIs that have succeeded in solving this
> problem. Thanks.
>
> The second question: how to convince management to allow a
> functionality to be designed in 2 modes:
> "beginner" and "intermediate", when the "simple", "intuitive",
> "beginner" but "mediocre" UI is so darn "appealing", "conventional",
> and "safe".
>
> Sandeep
>
> --- "Svoboda, Eric" <Eric.Svoboda at maritz.com> wrote:
>
> > Sandeep-
> >
> > I know you're trying to limit server trips, but is it really so
> > important to do so? If you could concede a little on this goal, it
> > seems that the easiest thing for a user to model would be the
> > standard drill-down menu with a breadcrumbs, with the final
> > selection pages using checkboxes. It's so widely used on the web
> > that users will "get it"
> > instantly. I realize they'll also be getting a little latency as
> > they traverse this kind of menu, but it might be a good trade off to

> > make for keeping the experience simple.
> >
> > Eric
> >
> > -----Original Message-----
> > From:
> >
> discuss-interactiondesigners.com-bounces at lists.interactiondesigners.co
> m
> >
> [mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesi
> gn
> > ers.com] On Behalf Of Sandeep Jain
> > Sent: Thursday, August 12, 2004 12:49 PM
> > To: id-discuss
> > Subject: RE: [ID Discuss] Hierarchical gui and multiselection
> >
> > Precisely. This is a file-browsing style operation.
> >
> > However, I have not seen that style of operation represented in HTML

> > design. My proposed solution is the the Open dialog design, but
> > inside a webpage.
> >
> > My question is whether I am stepping on or ignoring alternate web
> > conventions by doing so. Instead of icons for the folders, I was
> > thinking of adding a "..." to the end of items that a folders..since

> > the selectbox doesn't allow images.
> >
> > Every time I come up with a novel idea, I get burnt by marketing for

> > not following conventions. This isn't a "novel" idea, except in the

> > context of web design for this style of operation, I have not seen
> > reasonable alternatives.
> >
> > Sandeep
> >
> > --- Mark Canlas <mark at htmlism.com> wrote:
> >
> > > It just sounds like a regular file-browsing type
> > operation. Maybe you
> > > should try looking at the Open/Save dialog used in
> > Mac OS X (or
> > > Windows maybe?). I think it uses a combination of
> > breadcrumb trails
> > > and columns to browse through multiple folders
> > (levels), leaving the
> > > user only able to select from the children of the
> > current parent.
> > >
> > > By the way, as for making round trips to the
> > server, you could always
> > > store the entire tree in a portable format and
> > generate the menu on
> > > the fly, using DHTML or whatever rendering engine.
> > So, for a web
> > > interface, the time to display the menu would be
> > as fast as the
> > > client's computer (unlike a PHP-based solution,
> > which to me seems a
> > > bit too kludgy).
> > >
> > > Mark Canlas
> > > http://www.htmlism.com/mark/
> > > -----Original Message-----
> > > From:
> > >
> >
> discuss-interactiondesigners.com-bounces at lists.interactiondesigners.co
> m
> > >
> >
> [mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesi
> gn
> > ers.
> > > com] On Behalf Of Sandeep Jain
> > > Sent: Tuesday, August 10, 2004 5:51 PM
> > > To: id-discuss
> > > Subject: [ID Discuss] Hierarchical gui and
> > multiselection
> > >
> > > What would be a reasonable web-based design for
> > the problem below,
> > > that doesn't assume Flash?
> > >
> > > (1)Suppose that there is an N-level hierarchical
> > set of items, and you
> >
> > > want the user to navigate through the hierarchy
> > till there are a set
> > > of children items that the user wants.
> > >
> > > (2)At this point, the user would like to
> > multi-select items at that
> > > level.
> > >
> > > (3)However, the domain is such that the user
> > should not be allowed to
> > > select items from multiple parents.
> > >
> > > (4) It's probably not very useful to have many
> > roundtrips to the
> > > server, each time a parent item is opened.
> > >
> > > I came up with a Javascript design which is
> > conventional in Windows,
> > > but unconventional in HTML, as follows.
> > >
> > > The design is essentially an icon-less, Windows
> > Explorer, without any
> > > treeview on the left, and the itemview would be in
> > list view.
> > >
> > > Details -> There would be a combo-box listing the
> > parents going up to
> > > the root of the tree, and a selection box, below
> > it, which shows the
> > > children for the current parent. The combo-box
> > will always display
> > > the current parent. Any item in the selection box
> > which is also a
> > > parent would have an ellipsis (...) next to its
> > name. Also, to the
> > > right of the combo box would be 2 buttons with an
> > "Up" icon and text,
> > > and to the right of the selection box, there would
> > be a "Down" icon
> > > and text to step through the hierarchy.
> > >
> > > Bad design? Is there something more conventional
> > that could be used?
> > >
> > > If I were to remove constraint (4), would your
> > design change? Would
> > > you design be different if N(levels)=5?
> > >
> > > Sandeep
> > > _______________________________________________
> > > Interaction Design Discussion List discuss at ixdg.org
> > > --
> > > to change your options (unsubscribe or set
> > digest):
> > > http://discuss.ixdg.org/
> > > --
> > > Questions: lists at ixdg.org
> > > --
> > > Announcement Online List (discussion list members
> > get announcements
> > > already) http://subscribe-announce.ixdg.org/
> > > --
> > > http://ixdg.org/
> > >
> > >
> >
> > _______________________________________________
> > Interaction Design Discussion List
> > discuss at ixdg.org
> > --
> > to change your options (unsubscribe or set digest):
> > http://discuss.ixdg.org/
> > --
> > Questions: lists at ixdg.org
> > --
> > Announcement Online List (discussion list members get announcements
> > already) http://subscribe-announce.ixdg.org/
> > --
> > http://ixdg.org/
> >
> >
> > Confidentiality Warning: This e-mail contains information intended
> > only for the use of the individual or entity named above. If the
> > reader of this e-mail is not the intended recipient or the employee
> > or agent responsible for delivering it to the intended recipient,
> > any dissemination, publication or copying of this e-mail is strictly

> > prohibited. The sender does not accept any responsibility for any
> > loss, disruption or damage to your data or computer system that may
> > occur while using data contained in, or transmitted with, this
> > e-mail. If you have received this e-mail in error,
> > please immediately notify us by return e-mail.
> > Thank you.
> >
> >
> === message truncated ===
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/

_______________________________________________
Interaction Design Discussion List
discuss at ixdg.org
--
to change your options (unsubscribe or set digest):
http://discuss.ixdg.org/
--
Questions: lists at ixdg.org
--
Announcement Online List (discussion list members get announcements
already) http://subscribe-announce.ixdg.org/
--
http://ixdg.org/

_______________________________________________
Interaction Design Discussion List
discuss at ixdg.org
--
to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
--
Questions: lists at ixdg.org
--
Announcement Online List (discussion list members get announcements already) http://subscribe-announce.ixdg.org/
--
http://ixdg.org/

12 Aug 2004 - 7:24pm
sandeepblues
2003

I will dare to disagree with Don Norman.

Humans as in when we became homo sapiens, may not have
been wired to intuit.

But, in the modern day, where people for at least a
decade(?) have grown up with computers and WIMP
designs etc, clearly, people have been wired to intuit
things related to technology. Why are kids more wired
to figure out a VCR than their grandparents?

Sandeep

--- "Adlin, Tamara" <tamara at amazon.com> wrote:

> I like what Don Norman says: there is no such thing
> as an 'intuitive' design for the Web. Humans weren't
> wired to intuit things related to technology. The
> question is how quickly they can learn it.
> "Intuitive" really means (in this context) that it's
> super duper easy to learn (or that it's like you've
> already learned it). It's a nice way to change the
> discussion--what do you need to help novices learn,
> and what can you assume more experienced users
> already know. This can help direct design decisions
> better (in my experience) than trying to create
> something that's 'intuitive.'
>
> Tamara
>
> -----Original Message-----
> From:
>
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
>
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com]
> On Behalf Of Schomer, Todd
> Sent: Thursday, August 12, 2004 3:14 PM
> To: id-discuss
> Subject: RE: [ID Discuss] "Intuitive" designs can be
> cumbersome
>
> It's always a challenge to design for multiple
> user-levels, but it can be done.
>
> My thinking is that you can design something in such
> a way that a basic user can navigate through each UI
> element, and get through it. There is enough content
> in each dialog, for example, to understand the
> capabilites of the program.
>
> When the basic user has figured that much out, they
> can start to use hotkeys for jumping through the UI
> faster.
>
> For the power-user, I try to reduce the steps
> involved in getting from point A to point B by
> adding things like presets for dialogs, which
> configure all the settings with one menu choice, or
> preferences that allow dialogs to be configured
> their way when they open them next time.
> Or even modifier keys, which bypass steps - such as
> holding down the Option key when deleting something
> and bypassing the warning message that would
> normally appear.
>
> Another thing I do with my designs is have all the
> defaults be the most likely choices for the basic
> user, so if they forget to set something up, or
> don't understand something, the product will most
> likely work for them. (This is probably a "duh" but
> should still be mentioned, as I miss this all too
> often in other people's products). It's like having
> a setting for audio quality in iTunes. I shouldn't
> have to understand what that means in order to rip a
> CD to MP3, so the setting should be set for the most
> common choice and deliver me positive results
> without changing the settings.
>
> Last idea... To hide more advanced settings behind
> buttons, or in parts of dialogs that expand when the
> user clicks an Advanced button or twist-down
> control. Keep the basics in the main part of the
> dialog, and let the user expand into more advanced
> controls.
>
> Schomer
>
> -----Original Message-----
> From:
>
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
>
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
> ers.com] On Behalf Of Mark Canlas
> Sent: Thursday, August 12, 2004 12:59 PM
> To: 'Sandeep Jain'; 'Svoboda, Eric'; 'id-discuss'
> Subject: RE: [ID Discuss] "Intuitive" designs can be
> cumbersome
>
> I tried to meditate on this for a minute or two and
> this is the best that I could come up with.
>
> Let's start with power users. Power users are
> powered because they get to say or do as much as
> they want in as little effort/words as possible.
> Example, I get to find out the IP address and
> network configuration info of my localhost by typing
> in ipconfig. That's it, I'm done. You're right,
> maybe in the long run, that is the preferred mode.
>
> But the problem is new users, who basically don't
> know how to speak such a terse language. Since they
> might know only points and clicks, you might have to
> explain to them the concept of obtaining an IP
> address using only points and clicks.
>
> So, the habits that new users learn aren't
> necessarily bad ones... They just become less
> appropriate or less efficient over time (provided
> these users are being directly converted into power
> users over time).
>
> So, I guess the challenge, as I see it, is to find
> that sweet spot that meets the advanced users and
> the beginners, all in one interface. That's being
> able to let powers say what they want in as few
> words as possible, and still carry out that same
> message to new users.
>
> The thing that has always bugged me is this quest
> for two different interfaces... I don't really see
> the need, or how it would work. Two different
> interfaces just adds another choice for the user to
> make.
> While one might think it's easy to differentiate
> between novice and advanced, what about mediocre
> users? Where do they fall in? Will using the simple
> interface make them feel bad? And two interfaces is
> just more work for you, the implementer...
>
> Examples... I dunno, Google? Google is simple,
> powerful, and user-friendly, no? AutoCAD had this
> keyboard/graphical hybrid I've always been fond
> of...
>
> Keep it simple, I guess.
>
> Mark Canlas
> http://www.htmlism.com/mark/
>
> > -----Original Message-----
> > From: discuss-interactiondesigners.com-
> > bounces at lists.interactiondesigners.com
> [mailto:discuss-
> >
>
interactiondesigners.com-bounces at lists.interactiondesigners.com]
> On
> > Behalf Of Sandeep Jain
> > Sent: Thursday, August 12, 2004 3:01 PM
> > To: Svoboda, Eric; id-discuss
> > Subject: [ID Discuss] "Intuitive" designs can be
> cumbersome
> >
> > I am transitioning from one thread re.
> "Hierarchical gui and
> > multiselection" to this one.
> >
> > There are so many cases in IxD where a certain
> design would be
> > (a) far more easy to use in the long run,
> > (b) require far less interaction and work on the
> part of the user, and
>
> > (c)be far less "in the face"
> >
> > but that design is either non-intuitive or
> unconventional.
> >
> > As a very geeky but pertinent example, consider
> the process of finding
>
> > out the IP address on your client machine on
> Windows. One way is to
> > open up the shell window, and do what UI designers
> frequently
> > pooh-pooh Unix for. Use the command line and type
> ipconfig.
> > Now, try doing that via the Windows GUI. Yet, one
> can give a strong
> > case for the non-system administrator user, that
> the GUI method is
> > better. But, will that user ever learn
> "ipconfig"? If not, then isn't
>
> > that a failure of IxD? Perhaps, it is a failure of
> MS GUI design??
> > What GUI could compete with ipconfig command-line?
> >
> > Moral of story:
> >
> > Going back to a topic many months ago, how does
> one balance simplicity
>
> > for the simpleton and mediocrity for the majority
> of user? I am
> > constantly hounded by this dilemma, in my designs.
> How can IxD
> > transition a beginner UI to a intermediate UI?
> Doesn't the beginner
> > UI train the user in bad habits, that will prevent
> the user from
> > increasing skills?
> >
> > Please give examples of UIs that have succeeded in
> solving this
> > problem. Thanks.
> >
> > The second question: how to convince management to
> allow a
>
=== message truncated ===

12 Aug 2004 - 7:30pm
Peter Merholz
2004

>
> But, in the modern day, where people for at least a
> decade(?) have grown up with computers and WIMP
> designs etc, clearly, people have been wired to intuit
> things related to technology. Why are kids more wired
> to figure out a VCR than their grandparents?

It's not an issue of technology.

Kids are more wired to figure out *anything* than their grandparents.

A thread from my site:
http://www.peterme.com/archives/00000348.html

And here's Don's thoughts on it:
http://www.peterme.com/archives/00000353.html

--peter

12 Aug 2004 - 7:37pm
Dave Malouf
2005

Sandeep, maybe I'm not understanding what you mean by the word "cumbersome",
but from my guess, the only problem here is implementation and not an issue
of HTML vs. Flash vs. WIMP.

But I don't want to make this a technical discussion. I'm more interested in
the perception and definition of "cumbersome"?

Can you explain more about what you mean here?

-- dave

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Sandeep Jain
Sent: Thursday, August 12, 2004 6:42 PM
To: id-discuss
Subject: RE: [ID Discuss] "Intuitive" designs can be cumbersome

In the WIMP world, there seem to be lots of
conventions for the "onion" model. Technical
constraints make an onion model in the web world quite
cumbersome.

I would be interested in moving this discussion to web
application design (without Flash), where frequently
the limitations of widgets/technology, and the power
of interpretive UI tech. mean that innovative, varied,
and unconventional designs are possible.

In other thread running currently (hierarchy and
multiselection), there is a discussion about how one
should achieve an "Open File Dialog" UI on the
web...in short how to navigate through a hierarchical
data set and multiselect children (not necessarily
leaves) under a single parent.

The intuitive web convention will be to have multiple
roundtrips to the server when the user clicks on
parent links to open them, and have checkboxes next to
each list of children. Very intuitive. Very
cumbersome.

Sandeep

--- "Schomer, Todd" <Schomer at extensis.com> wrote:

> It's always a challenge to design for multiple
> user-levels, but it can
> be done.
>
> My thinking is that you can design something in such
> a way that a basic
> user can navigate through each UI element, and get
> through it. There is
> enough content in each dialog, for example, to
> understand the
> capabilites of the program.
>
> When the basic user has figured that much out, they
> can start to use
> hotkeys for jumping through the UI faster.
>
> For the power-user, I try to reduce the steps
> involved in getting from
> point A to point B by adding things like presets for
> dialogs, which
> configure all the settings with one menu choice, or
> preferences that
> allow dialogs to be configured their way when they
> open them next time.
> Or even modifier keys, which bypass steps - such as
> holding down the
> Option key when deleting something and bypassing the
> warning message
> that would normally appear.
>
> Another thing I do with my designs is have all the
> defaults be the most
> likely choices for the basic user, so if they forget
> to set something
> up, or don't understand something, the product will
> most likely work for
> them. (This is probably a "duh" but should still be
> mentioned, as I miss
> this all too often in other people's products). It's
> like having a
> setting for audio quality in iTunes. I shouldn't
> have to understand what
> that means in order to rip a CD to MP3, so the
> setting should be set for
> the most common choice and deliver me positive
> results without changing
> the settings.
>
> Last idea... To hide more advanced settings behind
> buttons, or in parts
> of dialogs that expand when the user clicks an
> Advanced button or
> twist-down control. Keep the basics in the main part
> of the dialog, and
> let the user expand into more advanced controls.
>
> Schomer
_______________________________________________
Interaction Design Discussion List
discuss at ixdg.org
--
to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
--
Questions: lists at ixdg.org
--
Announcement Online List (discussion list members get announcements already)
http://subscribe-announce.ixdg.org/
--
http://ixdg.org/

12 Aug 2004 - 9:02pm
sandeepblues
2003

This isn't a implementation problem. I am referring to
a design problem. For example, it is easier to go
through a learn-by-discovery process on a WIMP
application, than on a new-page-every-time web
application (due to tech. constraints).

In order to make something "intuitive", frequently
designs have to be layed out in a conventional manner
that a user might be familiar with.

Suppose that a "beginner" is someone who has used
computers (Word, PowerPoint) simply for a decade, and
now wants to configure their wireless router at home.
Suppose that this task requires them to check their ip
address 10 times through. It would be better the
router's manual introduces them to ipconfig asap as an
alternative, than to have them step through an
"intuitive" GUI.

It is frequently "cumbersome" to use highly simplified
user interfaces that follow standard conventions.
Wizards verus forms. Frequently, such designs are
safer. However, for applications where the designer is
darned sure that the user will use this app. 5 times a
week, shouldn't an intermediate level of UI be
presented to the beginner user immediately? This
takes the design into "unsafe" territory. The
question then becomes...how to ramp up a beginner,
"computer-savvy", but not "this-application-savvy"
user to use intermediate level UIs.

Sandeep

--- David Heller <dave at interactiondesigners.com>
wrote:

> Sandeep, maybe I'm not understanding what you mean
> by the word "cumbersome",
> but from my guess, the only problem here is
> implementation and not an issue
> of HTML vs. Flash vs. WIMP.
>
> But I don't want to make this a technical
> discussion. I'm more interested in
> the perception and definition of "cumbersome"?
>
> Can you explain more about what you mean here?
>
> -- dave
>
>
> -----Original Message-----
> From:
>
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
>
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
> com] On Behalf Of Sandeep Jain
> Sent: Thursday, August 12, 2004 6:42 PM
> To: id-discuss
> Subject: RE: [ID Discuss] "Intuitive" designs can be
> cumbersome
>
> In the WIMP world, there seem to be lots of
> conventions for the "onion" model. Technical
> constraints make an onion model in the web world
> quite
> cumbersome.
>
> I would be interested in moving this discussion to
> web
> application design (without Flash), where frequently
> the limitations of widgets/technology, and the power
> of interpretive UI tech. mean that innovative,
> varied,
> and unconventional designs are possible.
>
> In other thread running currently (hierarchy and
> multiselection), there is a discussion about how
> one
> should achieve an "Open File Dialog" UI on the
> web...in short how to navigate through a
> hierarchical
> data set and multiselect children (not necessarily
> leaves) under a single parent.
>
> The intuitive web convention will be to have
> multiple
> roundtrips to the server when the user clicks on
> parent links to open them, and have checkboxes next
> to
> each list of children. Very intuitive. Very
> cumbersome.
>
>
> Sandeep
>
>
> --- "Schomer, Todd" <Schomer at extensis.com> wrote:
>
> > It's always a challenge to design for multiple
> > user-levels, but it can
> > be done.
> >
> > My thinking is that you can design something in
> such
> > a way that a basic
> > user can navigate through each UI element, and get
> > through it. There is
> > enough content in each dialog, for example, to
> > understand the
> > capabilites of the program.
> >
> > When the basic user has figured that much out,
> they
> > can start to use
> > hotkeys for jumping through the UI faster.
> >
> > For the power-user, I try to reduce the steps
> > involved in getting from
> > point A to point B by adding things like presets
> for
> > dialogs, which
> > configure all the settings with one menu choice,
> or
> > preferences that
> > allow dialogs to be configured their way when they
> > open them next time.
> > Or even modifier keys, which bypass steps - such
> as
> > holding down the
> > Option key when deleting something and bypassing
> the
> > warning message
> > that would normally appear.
> >
> > Another thing I do with my designs is have all the
> > defaults be the most
> > likely choices for the basic user, so if they
> forget
> > to set something
> > up, or don't understand something, the product
> will
> > most likely work for
> > them. (This is probably a "duh" but should still
> be
> > mentioned, as I miss
> > this all too often in other people's products).
> It's
> > like having a
> > setting for audio quality in iTunes. I shouldn't
> > have to understand what
> > that means in order to rip a CD to MP3, so the
> > setting should be set for
> > the most common choice and deliver me positive
> > results without changing
> > the settings.
> >
> > Last idea... To hide more advanced settings behind
> > buttons, or in parts
> > of dialogs that expand when the user clicks an
> > Advanced button or
> > twist-down control. Keep the basics in the main
> part
> > of the dialog, and
> > let the user expand into more advanced controls.
> >
> > Schomer
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members
> get announcements already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members
> get announcements already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>

12 Aug 2004 - 9:51pm
Dave Malouf
2005

I think I'm not quite understanding your use of terms, but I'll try to get
past this for a moment.

1. "technical constraints" - which ones are you referring to?
Asynchronisity? When you say web-application, which kids? I mean you have
some that are done just to IE, or some just to IE, Mozilla (etc.) and don't
degrade down to lower versions. In both the first two categories, you can
make a web-based application seem like a client server app. There is some
jungling to do, but because you can parse XML on the fly there is a lot of
ways you can mitigate the perception of the user around asynchronisity. If
you are stuck in Netscape 4.x land, then yes, you do have some other issues,
but to be honest, even these can be surmounted. I think your overall thread
of "giving up" is an interesting take.

2. I do think though that there are many many different reasons to not treat
the web experience the same as the WIMP and these are technical constraints
per se, but that the web browser brings with it added contextual baggage
when opened. Basically , you are stuck with an application (your web-app)
inside a WIMP app (the browser) and that browser has a culture of convention
of use around it that makes it hard to do illicit change. In the end, my
testing of at least a 100 users while at documentum designing their latest
web-platform showed me that users end up hybridizing the "best" of
old-school web world with what they like about WIMP applications. This is
their expectations and it is completely unpredictable. There is a continuum
of expectations that users have moving from one extreme to another and
finding that right balance is very difficult.

3. I think there is another question. What is your available resources? Why
not have Two (or however many you need) different interfaces? Why not have
an interface that displays the "form" as you put it but offers assistance in
various conventional ways to get the user through that form; In this way you
not only guide but you also teach so that your assistance becomes less and
less necessary. The reason I put this suggestion in the scope category is
that to do a very complex interface like this requires a lot more resources
than most of us doing web applications are afford.

Anyway, these are some of the points that come to mind in this discussion. I
do not think there is a specialness in "web apps" per se that leads us to
different behavioral designs. I do think though that the final
implementation of these designs beyond the core behavioral structure is
where the details fall into place. I think it is safe to assume that you
should start to design your application--just go for it--as if it is just a
client server app and dare your developers to meet you there. Then like an
onion you will find a balance + discord all at the same time to get to your
imperfect solution. ;)

-- dave

-----Original Message-----
From: Sandeep Jain [mailto:sandeepblues at yahoo.com]
Sent: Thursday, August 12, 2004 10:02 PM
To: David Heller; 'id-discuss'
Subject: RE: [ID Discuss] "Intuitive" designs can be cumbersome

This isn't a implementation problem. I am referring to
a design problem. For example, it is easier to go
through a learn-by-discovery process on a WIMP
application, than on a new-page-every-time web
application (due to tech. constraints).

In order to make something "intuitive", frequently
designs have to be layed out in a conventional manner
that a user might be familiar with.

Suppose that a "beginner" is someone who has used
computers (Word, PowerPoint) simply for a decade, and
now wants to configure their wireless router at home.
Suppose that this task requires them to check their ip
address 10 times through. It would be better the
router's manual introduces them to ipconfig asap as an
alternative, than to have them step through an
"intuitive" GUI.

It is frequently "cumbersome" to use highly simplified
user interfaces that follow standard conventions.
Wizards verus forms. Frequently, such designs are
safer. However, for applications where the designer is
darned sure that the user will use this app. 5 times a
week, shouldn't an intermediate level of UI be
presented to the beginner user immediately? This
takes the design into "unsafe" territory. The
question then becomes...how to ramp up a beginner,
"computer-savvy", but not "this-application-savvy"
user to use intermediate level UIs.

Sandeep

--- David Heller <dave at interactiondesigners.com>
wrote:

> Sandeep, maybe I'm not understanding what you mean
> by the word "cumbersome",
> but from my guess, the only problem here is
> implementation and not an issue
> of HTML vs. Flash vs. WIMP.
>
> But I don't want to make this a technical
> discussion. I'm more interested in
> the perception and definition of "cumbersome"?
>
> Can you explain more about what you mean here?
>
> -- dave
>
>
> -----Original Message-----
> From:
>
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
>
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
> com] On Behalf Of Sandeep Jain
> Sent: Thursday, August 12, 2004 6:42 PM
> To: id-discuss
> Subject: RE: [ID Discuss] "Intuitive" designs can be
> cumbersome
>
> In the WIMP world, there seem to be lots of
> conventions for the "onion" model. Technical
> constraints make an onion model in the web world
> quite
> cumbersome.
>
> I would be interested in moving this discussion to
> web
> application design (without Flash), where frequently
> the limitations of widgets/technology, and the power
> of interpretive UI tech. mean that innovative,
> varied,
> and unconventional designs are possible.
>
> In other thread running currently (hierarchy and
> multiselection), there is a discussion about how
> one
> should achieve an "Open File Dialog" UI on the
> web...in short how to navigate through a
> hierarchical
> data set and multiselect children (not necessarily
> leaves) under a single parent.
>
> The intuitive web convention will be to have
> multiple
> roundtrips to the server when the user clicks on
> parent links to open them, and have checkboxes next
> to
> each list of children. Very intuitive. Very
> cumbersome.
>
>
> Sandeep
>
>
> --- "Schomer, Todd" <Schomer at extensis.com> wrote:
>
> > It's always a challenge to design for multiple
> > user-levels, but it can
> > be done.
> >
> > My thinking is that you can design something in
> such
> > a way that a basic
> > user can navigate through each UI element, and get
> > through it. There is
> > enough content in each dialog, for example, to
> > understand the
> > capabilites of the program.
> >
> > When the basic user has figured that much out,
> they
> > can start to use
> > hotkeys for jumping through the UI faster.
> >
> > For the power-user, I try to reduce the steps
> > involved in getting from
> > point A to point B by adding things like presets
> for
> > dialogs, which
> > configure all the settings with one menu choice,
> or
> > preferences that
> > allow dialogs to be configured their way when they
> > open them next time.
> > Or even modifier keys, which bypass steps - such
> as
> > holding down the
> > Option key when deleting something and bypassing
> the
> > warning message
> > that would normally appear.
> >
> > Another thing I do with my designs is have all the
> > defaults be the most
> > likely choices for the basic user, so if they
> forget
> > to set something
> > up, or don't understand something, the product
> will
> > most likely work for
> > them. (This is probably a "duh" but should still
> be
> > mentioned, as I miss
> > this all too often in other people's products).
> It's
> > like having a
> > setting for audio quality in iTunes. I shouldn't
> > have to understand what
> > that means in order to rip a CD to MP3, so the
> > setting should be set for
> > the most common choice and deliver me positive
> > results without changing
> > the settings.
> >
> > Last idea... To hide more advanced settings behind
> > buttons, or in parts
> > of dialogs that expand when the user clicks an
> > Advanced button or
> > twist-down control. Keep the basics in the main
> part
> > of the dialog, and
> > let the user expand into more advanced controls.
> >
> > Schomer
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members
> get announcements already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members
> get announcements already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>

Syndicate content Get the feed