Re: A call to action / Guidelines

[Kevin Cullis <kevincu orci com>]

"Christopher D. Beland" wrote:
> 
> > Where can I find the outline of the Apple Human Interface so that we
> > can start putting GNOME stuff in it?
> 
> The Macintosh Human Interface Guidelines are accessible from:
> 

Thanks!!

> http://devworld.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-2.html
> 
> Adopting these guidelines for Gnome looks like it would be a
> monumental task.  It's also not the most straightforward job in the

True, but if nothings been done, we've got to start somewhere.  As I
stated, I don't like to reinvent the wheel, but I'd sure like to make it
a tire. There are some issues regarding Linux which don't quite fit the
older Mac ideas anyway, but we can throw those out.  But the principles
remain: form follows function.

> world.  In creating a distinct "look and feel" for Gnome, a whole new
> host of small usability issues is bound to be created.  Also, I think
> Apple has not always made all of the right decisions (and many times
> there are multiple "right" decisions) so we must also rely on the
> expertise and experience of Gnome developers, users, testers, and
> designers to know when to deviate from the historical path.  But, as
> people have said, it's almost certainly worthwhile - as long as it
> makes an impact on the actual product.

Well said.  Apple has stated that themes WILL NOT be a part of OS X
stuff and Aqua.  Too bad, but we can avoid that problem.  But too much
customization causes programming and performance issues which we can
address in the documents.

> 
> The key question is how will the Guidelines (whether they are spawned
> from this list, Eazel, or elsewhere) actually affect the
> implementation process.  For small things, like placement of objects
> in dialog boxes, the Guidelines can make UI improvement as easy as
> filing a bug report.  ('Section 2, paragraph 5 specifies the button be
> in the lower right corner, and Section 3, paragraph 2 states the
> standard label is "close" not "cancel".')
> 
> Presumably, if developers feel the consistent look and feel the
> Guidelines mandate is reasonable, they'll make corrections.  Even
> better, if they feel consistency and user-friendliness is important,
> they'll make such corrections a less-than-negligible priority.  I
> think developer attitudes are mostly a function of how well the rules
> are written, how they are presented to the community, and how
> responsive to developer needs and input the process will be.

Again, if the document shows the results and benefits of the changes and
there are little or no technical reason other than work to be done, then
I would hope that our salesmanship would help.  If there are technical
reasons, problems, or issues which will cause great amount of work, I'd
think that we'd at least rethink our comments.

> 
> The Guidelines leave many higher-level problems unsolved.  For
> instance, even if the session management system has every button,
> switch, and light in proper order, users may still find it confusing
> to use on a conceptual level.  It may need to reorganize its interface
> in a new paradigm, or even add or lose some functionality.  How can
> developers get this sort of feedback, and what role might this list
> play?  I see the following possibilities:
> 
> 1. The developer(s) is part of a large organization that includes UI
> specialists.  In this case, gnome-gui-list is probably best advised to
> leave development in the hands of the experts, as there are too many
> other project getting zero UI attention to waste resources
> second-guessing other teams.

True.

> 
> 2. We see a need for UI attention in a particular program.  We
> approach the maintainer and ask them if they'd consider implementing
> some UI improvements if we came up with some suggestions.  If the
> response is positive, we have a conversation about the program over
> the list and/or IRC, and someone volunteers to summarize the
> discussion in the form of a report to the maintainer.  (Developers
> would be encouraged to participate in the discussion, of course.)

No problem here with that.  Besides my closest friend is a programmer
and I occasionally listen to him ;-).

> 
> 3. If the maintainer in (2) says they have no time to implement UI
> improvements, but wouldn't otherwise be averse to them, then we still
> might find a volunteer who would be willing to consider implementing
> our suggestions.
> 
> 4. The situation is complicated, our expertise is insufficient, and/or
> the developers disagree with our off-the-top-of-our-heads suggestions.

Off-the-top would be during the beginning of the project only and as
time would permit, we'd lessen the additions to the feature list to
quickly close.  I.e. we'd be working two to three steps ahead of the
programmers in designs and documents so that the programmers would have
less to worry about and quicker execution.

> Someone needs to start collecting real-world data, perhaps by
> organizing UI feedback from users at large, or by getting the program
> on the agenda of UI experts and/or formal usability testing.
> 
> 5. A developer asks for our assistance.  Yay!  See 2.
> 
> Perhaps the Guidelines can be written in a collaborative fashion.  We
> seem to be quite willing to spend endless hours debating the "shoulds"
> of various things; why not harness that energy?  For each section of
> the Guidelines, someone could volunteer to draft something simple,
> short, and stupid.  8)  Then we could have a discussion, which the
> volunteer would then summarize in the form of a revised statement.  We
> could iterate through the various sections.  In the end, we would have
> a set of Guidelines we could present for comment from developers, the
> public, and UI experts.

Have you heard of UML? I would think that that would benefit us greatly
in documenting our efforts. UML is VERY process driven and it would help
if we all used it.  DIA for Linux has a UML function.  We should look at
it.

> 
> I think the key elements in this process would be a.) getting enough
> people to volunteer small amounts of time for small portions b.)
> collaborating with enough people (UI people at Eazel and Helix Code,
> developers, project leaders, etc) to gain momentum and acceptance c.)
> publicity and d.) follow-through on actually writing the reports and
> evangelizing their contents.
> 
> But I have the sense that mysterious goings-on inside private
> companies or higher up in the Gnome leadership may be pre-empting the
> need for such an initiative.  (Personally, I have no idea how Gnome

If they were smart, they would ask if we're willing to help.  Good
leaders will listen.

> really works in a social sense, and I have not had enough sleep lately
> to trust myself to propose much of anything with complete sanity.)  It
> would be useful to touch base with the people in those circles, who
> are certainly all strangers to me.
> 
> In summary, we need to strength both the (idea -> document) and the
> (document -> code) processes in order to make this list an effective

This is where I excel, documenting the process and I've already begun
this with the LDP folks.  Both documents should be aligned so that it's
easy to move from one to the other and traceability is VERY important
from a QA perspective. I'll at least start something in the next few
days, like an outline.

> tool for UI improvement.  We also need to become more aware of other
> UI initiatives and how they and we fit into the project as a whole.
> Perhaps turnover on the list would be less if it had both better
> productivity and recognition.
> 
> If only I were paid by the word,
> 
> Beland

Now get some sleep and thanks for the input. ;-)

Kevin

begin:vcard 
n:Cullis;Kevin
tel;home:720-489-9283
x-mozilla-html:FALSE
adr:;;8285 S Poplar Way #202;Englewood;CO;80112;USA
version:2.1
email;internet:kevincu orci com
x-mozilla-cpt:;0
fn:Kevin Cullis
end:vcard