Re: CSS for Help Docs

[Calum Benson <calum benson sun com>]

Alex Larsson wrote:

> How bad is this UI freeze? I've asked the docs people here to come up with
> some nicer headers and stuff for the Yelp index pages. Does the UI freeze
> mean we have to keep looking like ass?

I dunno what the official release team definition of 'UI Freeze' is, but
I'd say that if you make a change that means the documented description
of how you use the application doesn't have to change, then it has a
reasonable chance of sneaking in after the UI freeze.

(Of course it's nice if the screenshots in the docs exactly match what
you see on the screen too, but IMHO that's less important than having
accurate text-- maybe I'm wrong.)

A couple of weeks back, Seth forwarded an email of mine to the release
team suggesting which UI things I thought it might be worth leaving
malleable even after the freeze-- I've attached it here for reference. 
(Content of help pages wasn't on the list, but that's because I never
thought about it... I thought of that as more of a docs issue, but I
guess you have to document the help browser app too.)

Cheeri,
Calum.

-- 
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson ireland sun com    Desktop Engineering Group
http://www.sun.ie                      +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

--- Begin Message ---

• From: Seth Nickell <snickell stanford edu>
• To: Release the hounds! <gnome2-release-team gnome org>
• Subject: [G2R] [Fwd: Impervious guidelines]
• Date: 27 Jan 2002 13:00:23 -0800

>> 3) Some minor string changes that are important for HIG consistency.
>> Calum's made a list of some things that he thinks are "minor" enough
>> that its worth changing them even if the docs end up not saying
>> *exactly* the same thing as the interface.

> Could these be attacked / noted as soon as possible?

> Glad these things are on your collective minds, anyway. :)

Oops, stupid me, meant to attach them.

-Seth

--- Begin Message ---

• From: Calum Benson <calum benson sun com>
• To: snickell Stanford EDU
• Cc: Me <calum benson sun com>
• Subject: Impervious guidelines
• Date: Thu, 24 Jan 2002 19:14:11 +0000

Here's a first cut at a list of the types of useful change we could
potentially allow to break the UI freeze with minimal or no
documentation changes required.  (Those that would be required would
probably be sufficiently minimal to be low priority, and not required in
time for the release).

The categories under "labelling/wording" may require changes to
localized strings, though, depending on the particular change requested.

Labelling/Wording

- Window titles, to bring in line with HIG recommendations
- Error/Alert messages that aren't explicitly referred to in docs
- Label/menu capitalization and punctuation (proper use of colons and
ellipses)
- Adding tooltips for controls that are missing them
- Changing wording of existing tooltips
- Adding text label 'prompts' to text fields (to indicate required
units, format etc.)
- Adding "n items selected"-type labels under multi-selection
trees/lists
- Changing width of notebook page tabs to be proportional to page label
width
- Wording/captialization of status bar messages
- Adding labels (with access keys) to controls that don't have them--
possibly more of a navigation issue, but I put in here as it affects
string localization

Navigation

- Fixing tab order in dialogs
- Ensuring the focused item is clearly marked as such at all times
- Adding access keys to labels
- Removing access keys from OK and Cancel
- Disabling controls when appropriate
- Correct use of "activates-default" property of GtkEntry fields
- Changing step-size and acceleration properties of spin buttons
- Correctly setting/unsetting default button in dialog
- Ensuring focus is given to an appropriate control in a window whenever
it's opened

Menus+Toolbars

- Ordering of menu items, unless order is explicitly documented
- Addition/removal of menu separators
- Toolbar button ordering, unless order is explicitly documented

Preferences

- Properly remembering/restoring settings between sessions
- Change to using themed fonts, colours, icons etc. rather than
hard-coded (but not if extra GUI is required to choose them on an
app-specific level)

Feedback

- Appropriate cursor changes during system activity, drag and drop etc.
- Appropriate highlighting during drag and drop, to indicate valid drop
targets
- Adding appropriate progress bars during lengthy activities
- Addition of Stop or Cancel buttons to allow lengthy activities to be
interrupted

Windows

- Changing modality of a window where appropriate
- Changing frame style/available window commands of a window where
appropriate

Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson ireland sun com    Desktop Engineering Group
http://www.sun.ie                      +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

--- End Message ---

--- End Message ---