Re: [HIG] Another alternative

[Matthew Thomas <mpt mailandnews com>]

Adam Elman wrote:
>...
> Some of you may have read the review that Matthew Thomas (mpt) posted
> last week; you may also have noticed that he wrote an alternative set
> of guidelines which he referenced in his review.  This alternative,
> "Improving GNOME 2.0 for Humans," is at
> http://geocities.com/mpt_nz/ig2h.html

If all goes well, Beta 2 of IG2H should be up in the next few hours.
I've fixed a number of ambiguous points, added cross-references, and
corrected all the grammar errors I could find.

>...
> 1) IG2H is relatively short compared to the current HIG.  I count 12
> pages (without images, which are broken for some reason),

The images are broken because I haven't drawn them yet. (A couple of
people have expressed interest in drawing them for me, but I've had no
firm offers.:-)

I'm trying very hard to keep it to 12 pages, on the grounds that if it's
any longer it won't be read by the people who need to read it (not to
mention making it easier to print as a handy reference booklet). This
may mean trimming some of the text once the illustrations are added,
though it's hard to tell while I don't have a two-column LaTeX version.

>                                                           as opposed
> to 50-some for the current HIG.

It would seem likely, judging by the number of `we need a section on
{whatever}' comments in the reviews of the mini-HIG so far, that the
current process would result in the mini-HIG growing 50 to 100 percent
over the next few weeks. That's not necessarily a bad thing, as long as
there is time to review the new sections as well as the existing ones,
and as long as others don't share my concern about the guidelines
getting too long for the necessary people to read and apply them before
GNOME 2.0.

> 2) The recommendations in IG2H are clear and self-consistent.
> 3) IG2H is relatively complete; while it certainly does not cover the
> breadth that HIG covers (it does not include a section on icons,

If I did include the section on icons, it would probably double the
length of the guidelines. :-) There's a lot of interlinked issues
involved -- metaphors, color, shape, object types, texture and
affordances, animation, showing metadata using visual effects, etc. In
addition, I'm under the impression (which may be wrong) that guidelines
on icon design would have a considerably smaller audience than the other
sections, since icons would tend to be drawn just by one person for a
particular app, and possibly the same person across many apps.

>                                                                  or
> on integrating apps with the desktop,

This seems like it should go in separate guidelines for making an
installer script, not guidelines for designing an interface. I tried to
keep to policy, not mechanism, and to things which are likely to stay
the same over the next five to ten years.

>                                       or mouse interactions, for
> example),

As I said in my review of the mini-HIG draft, mouse interactions seem
rather low down on the list of crucial issues to cover. Of course they
are important, and should be covered in a full HIG, but developers
should be fairly familiar with expected behavior already.

>           it covers what seem to be the crucial items that app
> developers should be concerned about at the moment, in a
> well-organized fashion.

That's the intention -- that developers of programs which (for the most
part) already exist can go through a concrete list of guidelines and
apply each of them to the current interface to get a noticable
improvement. I concentrated on the sort of issues which have come up
regularly in the Mozilla project over the last two years (standard
disclaimer: yes, I know Mozilla sucks, it's not my fault), on the
assumption that the same issues are likely to come up in interface
design for other Free Software projects.

>...
> The main reason I propose this is that I think IG2H is in a further
> state of completion than the HIG, so it would save us a significant
> amount of time to get to a final, postable version.  I also think
> that it would be far, far better to have a single document than for
> us to post our HIG and for mpt to also post his, and thus have two
> often-conflicting documents both purporting to be GNOME HI guidelines.

Rest assured that if the current mini-HIG is used as the permanent basis
for the GNOME guidelines, I'll retire IG2H out of harm's way (at least
until the next time someone decides to start a project to create a GPLed
desktop environment:-). But I am excited about GNOME as an opportunity
to provide users with a interface which is more elegant and usable than
any which exists currently, rather than a poor imitation of Windows or
Mac OS or worse.

> Here are some pre-requisites that I think would be necessary for this
> to work:
> 1) mpt would need to donate his document to the GNOME project, under
> the standard documentation license (whatever that is, I'm not sure at
> the moment).

I was planning to release it under the FDL. Is that appropriate?

> 2) mpt would need to be willing to make changes in his document in
> accordance with the group's reviews.  Alternately, he would need to
> be willing to have me or other members of the HIG team make
> changes/contribute additions.

Sure. (If I vehemently disagreed, you could always fork it.:-)

> 3) we'd need to rewrite the doc in docbook if mpt doesn't already
> have a docbook version.

I don't.

>...
> I know that mpt is also working on a longer document, which could
> become a full HIG.  I really hate to throw out good work that has
> already been done, but I also hate to see huge amounts of duplicated
> effort, and conflicting documents that would be much better combined.
>...

This is my fault, and I apologize. I've been working on DGSH since last
year, and on IG2H for a few months, but I got behind in Mozilla work;
and in the process of catching up on that, I didn't get IG2H into a
semi-complete state until after people had started writing their
sections of the mini-HIG.

-- 
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>