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
right-clicks.

Overall, my recommendation is to focus on contextual interface.  Also,
you should check out oscom.org 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
decision.

> 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
http://www.siggraph.org/members/jryan
+1-415-738-7513

"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: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]
       SUBSCRIPTION CHANGES & FAQ:  www.sigchi.org/web/faq.html
    --------------------------------------------------------------