CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"ACM SIGCHI WWW Human Factors (Open Discussion)" <[log in to unmask]>
Mathijs Panhuijsen <[log in to unmask]>
Wed, 11 Apr 2007 13:12:20 -0700
Justizin <[log in to unmask]>
Justizin <[log in to unmask]>
text/plain; charset=ISO-8859-1; format=flowed
text/plain (150 lines)
On 4/11/07, Mathijs Panhuijsen <[log in to unmask]> wrote:
> Hello everyone,

Howdy Mathijs!

> I'd like to hear your input on a fairly fundamental design choice for
> the user interface to a content management application, which I'm
> helping to design. This application runs in a browser and allows its
> users to edit content in the browser window.

Responding directly to your subject here, I think you are applying
old-skool desktop app memes to a web app, where you can and most
definitely *should* do much more flexible things.  I've developed web
apps with toolbars, ribbons, side panels, and all three at once, and
they were awkward and horrific to maintain.

Create a new meme! :)

> The GUI must include a large number of controls (over 30, so they
> wouldn't fit the width of the screen) for rich-text formatting, such as
> a bold button, an italic button, a CSS style selector etc. But these
> controls are very often not needed, because the specific implementation
> of the content management application enforces a visualization of the
> content, rather than leaving it to the user. Also, the buttons almost
> always apply to a certain area of the Web page only.

My recommendation would be to use flyouts, if you are familiar with
google apps and other web2.0 stuff, you should know what i mean, just
a little box that floats up when you hit the cursor or use some access
keys in combination with a selection, perhaps?  you can also catch

Overall, my recommendation is to focus on contextual interface.  Also,
you should check out which has several existing editors /
user interfaces which you can reuse, build upon, or take inspiration
from.  Try a few different apps before making a theory-driven design

> What we're trying to determine is where to place these controls. We've
> identified the following options:
> Option 1-Place the controls in a toolbar at the top of the viewport area
> of the browser, analogous to normal desktop applications.
> Advantage: The controls are always visible and easy to find.
> Disadvantages:
> -High cost in valuable vertical space: the browser itself already has a
> menu, button bar and possibly custom controls such as Google Toolbar,
> and our GUI adds a menu of its own. It might be possible to show and
> hide these formatting controls as needed, but that is visually
> disruptive.
> -Very often, the controls will be unavailable and/or unnecessary, and
> waste space.

I agree with this, I've done a very large-scale app with menus up top
and it was a mess.  We coded them 12 different ways before I moved on
and they were just all wonky.

> Option 2-Use tabs to toggle between the main application menu and this
> toolbar, like the Ribbon in Microsoft Office 2007.
> Advantage: This option costs less vertical space and does not display
> controls unnecessarily.
> Disadvantages:
> -The user needs to discover these controls, and perform a click to
> access them.
> -There is still some cost in terms of vertical space.

i think it would be neat to see content management controls in a
higher z-layer, coming up via an access key or sliding in from the
side, like the dock on osx or a panel in gnome or kde, but i could
enumerate some caveats in this direction as well, for one that the
side of the browser window does not interact with users like the side
of the screen -- it's not a boundary.

> Option 3-Place the controls in a grid inside a panel to the side
> (compare floating panels in, say, Adobe Photoshop). The GUI already has
> an accordeon-style side panel, similar to MS Outlook, to display other
> types of information.
> Advantages:
> -On a Web page, horizontal space is 'cheaper' (the left and right sides
> of a Web page are often empty)

this depends on the device, and the web is device-independent! :-D

> -Controls can be hidden (by the user or the system) when they are not
> needed.
> Disadvantages:
> -This is an unexpected place to find buttons and the like (especially in
> the context of a content editor)
> -Either the user needs to discover these controls, and perform a click
> to access them, or the application needs to show and hide the controls
> as the user selects or deselects an area on the Web page that needs them
> (visually disruptive).
> Note: Early user testing showed this option to be confusing to users,
> especially if they had to open the panel themselves.

My experience working with the Plone Content Management System is that
it's better to give users controls by default, and allow a
"full-screen" editing mode which hides them in such a way that users
learn contextually the meaning of the icon which expands and contracts
full-screen mode.  In the same way that your users have trouble
finding the panel, our users do have trouble finding full screen mode.
 Hell, I am a developer and it may have taken me a year to notice. ;)

> Option 4-Display the controls close to the area that needs them (and
> only when that area is selected). This is similar to Microsoft Office
> 2007, where selecting a piece of text makes formatting buttons appear
> above it.
> Advantages:
> -Controls appear and disappear as needed.
> -Controls are close to the area on which they operate.
> Disadvantages:
> -Showing and hiding these controls is visually disruptive, especially
> considering the number of controls.

Although I think you are focusing too much research on Microsoft apps
for something which would be cross-platform, and feel that is a common
mistake of web application developers, I do think this comes close to
the contextual UI that I suggest.  This is how web apps work, it makes
sense, it's convenient, etc..

> It seems that every option has its advantages and drawbacks, so I was
> hoping to find out if any of these options has your strong preference.

My preference is toward a contextual UI for an app like this, and of
course as a developer of Plone I would suggest taking a look at it for
any content management needs, but there are upsides to all of the
options you see here.  Above all, I suggest to innovate rather than
following the lead of one or another sect - that's the approach of
application development that the web should bring!

> Thanks a lot for your helpful input,

No problem!

Justin Alan Ryan
Independent Interactivity Architect

"You don't lead by pointing and telling people some place to go. You
lead by going to that place and making a case." -Ken Kesey

    Tip of the Day: Use the archives to research common questions
     CHI-WEB: POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]