Proposal: The GNU Uru Project

[Lyno Sullivan <lynosull freedomain org>]

November 7, 1998
To:	debian-doc@lists.debian.org, gnome-doc-list@gnome.org, fig@fig.org
Fr:	"Lyno Sullivan" <lls@freedomain.org>
Re:	Proposal: The GNU Uru Project

<http://www.freedomain.org/u/lls/writings/gnu-desktop/19981107-gnome-pf1.html>

I want to present a design idea, that seems appropriate to these listservs.
 The idea seems sensible to me, but if this is really a dumb idea, please
say so.  I am looking for a way that I can offer programming assistance,
but I am only interested in working on GPL'd projects. I am inexperienced
with GNU/Linux and Gnome but am trying to learn.  I will make up some
terminology in this article, so please correct anything I say.  If I
describe a worthy goal, please help me to understand how it might best be
attained, and help brainstorm additional user features, that should be
available.  Thank you for your patience and your help.

I have created a concept for a product that I am calling "GNU Uru".  The
name is a spin-off of the word "guru".  It is pronounced as "GNU Uru" with
a silent "NU".  I thought I was pretty clever, when I came up with the
name, but feel kind of sheepish now.  In any case, I have no attachment to
the name.  I will use whatever name is already assigned or whatever name is
decided upon.  If a team already exists for this product, please direct me
to them.

The concept of GNU Uru formed when I was exploring the Debian documentation
set. Let me start with Debian GNU/Linux and work my way into Gnome.  The
dwww package appears to be the best answer to the general issue of a
person, wanting an answer, being able to come into the GNU Documentation
Library (GDL) (maybe "repository" is a better word than "library") from the
Command Line Interface (CLI) prompt or the Graphical User Interface (GUI).
They can review the list of Titles in the GDL.  They can review the Table
of Contents for any document.  They can do searches of the index. That is
good but it is only part of the need.

My most general goal is that, when a Wintel user is converted to a
GNU/Linux Desktop,  they have "familiar" Help Facility resources.  Then I
want to take the existing Wintel solution several steps further--I want to
connect the government worker community and the free software community.
Just so you know, I have been doing mainframe (3270) help facilities, like
those described here, for well over 15 years (in government applications)
and have a pretty good understanding of the technical, end user, end user
support infrastructure, and text creation issues.  I am working now to get
a cessation of government spending on non-free software, in Minnesota
today, and tomorrow the world (*1).  If I succeed there will be an
increasing interest in GNU/Linux, within the government worker community.
IMHO, a good Help Facility is THE key resource that must be in place and
ubiquitous, in Bash and Gnome, by the time these new, non-technical, users
arrive.  The government tech-heads will arrive first and they will be more
tolerant of having to work hard to find the documentation--heck, many of us
are very familiar with how to use the excellent IBM mainframe documentation
manuals.  It is the application end-users that I am most concerned about.
If they arrive on the GNU/Linux Desktop and start reporting, to their
managers, that the GNU Help Facility sucks pond water, that could turn into
a serious setback for the free software community.

The GDL fulfills part of the needs of the GNU/Linux Desktop end-user--the
GDL is the documentation repository.  The remainder of the needs, such as I
can imagine them, are fulfilled by a context sensitive Help Facility.  I
propose that the GNU/Linux Universal Help Key be the PF1 key (the GNU Uru
Key), as is typical in most Wintel applications.

Here is how I think about the issue.  Imagine the user sitting on some
screen in any application (including the Bash CLI) and they need help.
What do they do?  I propose a universal solution.  They use the mouse (or
keyboard cursor if the mouse is unavailable) to position the pointer
anywhere they want on the screen and then they press F1 for the GNU Help
Facility (Uru).  If they drag the cursor to mark a set of text, that
passage becomes part of the PF1 context.

The user presses PF1 and what appears?  Imagine that a screen pops-up and
provides the following capabilities.

1) Context Sensitive Help -- the user gets very specific help about the
specific field (or text passage) on the screen and, even, the data within
it (useful for 3270 data entry screens).  They get a screen of context
sensitive help and they get hyper-text links to surrounding Policy Manuals
and Procedure Manuals.  Every function a user performs is within the
context of some task, so the infrastructure needs to support a surrounding
Task Management Facility.

2) General Help Search -- they get the full search facilities of the dwww
package. Maybe we need a Guile AI engine, that can handle fuzzy searches
too. Perhaps the index should have categories that allow searches of
sub-web-spaces.  User organizations can create their own Documentation
Libraries that can be concatenated to the GDL.  <SEGUE> I am trying to
convince government to create all its information under the LGPL but
private companies may not want to do this.  If we care about this issue,
perhaps the GDL information should be under the LGPL rather than the GPL.
I am pretty narrow-minded on the issue, but I consider a copyleft license
to only be acceptable when it is listed on RMS's "What Is Copyleft?" page
(*2).  When a better documentation license is listed on that page, then I
will prefer it.  The GNU Uru software will, of course, be GPL'd. </SEGUE>

3) Problem Chat -- they can "call" their organization support center and
have an on-line chat (via text dialog and, perhaps, voice) with their
support representative.  The user can click a button that authorizes the
support person to review the screen they are looking at.  The support
person can say "why don't you OK me to run remotely for you."  The user
clicks the OK and the support person takes over the user's session and runs
it for them.  The user watches everything that goes on.  A "movie" is made
of the whole Problem Chat" so that the end-user can replay it if necessary.
 Sensitive parts of the screen can be blanked out.  The "movie" can be sent
to a library of movies, for later context sensitive indexing and retrieval.

4) Problem Reporting -- they get information about the possible ways they
can report their problem and get help. Their environment information is
gathered and their screen is scraped and a problem report is prepared.  The
user can edit the Problem Report to remove (or encrypt) certain
confidential information.  The Problem Report gets routed via email to a
designated mailbox.  It does not go to the developers but goes into the
user's support organization.  If it gets reviewed, and the support
personnel determine that it actually is an application problem, then it
gets forwarded to the developers.

5) Suggestion Box -- the user can provide a suggestion about how the
interface might be improved.  That suggestion is whisked via email directly
to the developer or the team responsible for that specific part of the
software.  We need to bypass the bureaucratic solutions and create the
infrastructure that connect the people up, at the lowest levels of the
system.  Maybe the Suggestion Box is only opened, with the specific
permission of the developers.  Each development team could decide.

6) Time Reporting -- since work is done within the context of tasks, PF1
can be an easy way out into the Task Management Facility.

7) Create Uru Help -- a developer is provided the option to tweak the
context definition and then write or link in the appropriate help.  End
users might be authorized to splice their own commentary into the help
information.

For mainframe centric users, F7 and F8 page up and down the text (as does
PgUp and PgDn).  PF3 exits back one level. Other function keys provide Find
and FindNext and similar capabilities (following the CUA standards).  Users
can set key navigation styles according to mainframe function key
standards, Emacs standards, etc.  We do not want people to have to fumble
around too much to figure out their navigation keys.  We need several key
palettes.  We also need standard navigation buttons.  We need (maybe Java)
apps that provide the Uru function and navigation inside web browsers.

All this, of course works recursively.  If the user is sitting in the help
text and wants to use the GNU Uru key to, for example, make a suggestion to
the text developer, they need to be able to do so.  They need to also be
able to reach the Uru developers and the Uru key palette pickers.  If the
cursor is positioned on a jpeg image, maybe they need to be able to reach
the artist.  If sound is playing, maybe they position the pointer to the
speaker icon and press the GNU Uru key to reach the musician or the
composer (or at least find the lyrics of the song and the story behind it).
 We need to think big picture.

These are just a few of the pieces that I can imagine.  We need a solution
that provides the infrastructure required by large organizations.  I have
worked for several state governments and a very large insurance company so
I have a sense of their issues.  We want the systems to be in place so that
when a Department Commissioner of a business CEO decides to convert to the
GNU/Linux Desktop, they get the right infrastructure support free software.
 The GNU "Uru Key" (PF1) is just such a feature.  I can even imagine
Training Units in large organizations buying Uru mugs (from the FSF, of
course) to hand out to those trainees who successfully complete the
GNU/Linux Desktop Training curricula.  Certainly, everyone needs a "GNU
Uru" keycap sticker to paste over the F1 keycap (they get two stickers
because the Microsoft key is aliased to the Uru key).  Remember, packaging
and promotion are important too.  We need to cover the <expletive-deleted>
Windoze trademarked keycap, so it becomes invisible to the world.

The GNU Uru Project will need volunteer support from many people, besides
software developers, and we need a way to get an invitation out to people,
who can fill these other user-friendly, content creation roles.

(*1) " GNU/Linux Emancipation Plan"
<http://www.freedomain.org/u/lls/writings/free-mn/19981005-gnu-plan.html>

(*2) "What Is Copyleft?" <http://www.gnu.org/copyleft/copyleft.html>


-- 
Copyright(c) 1998 Lyno Sullivan; this work is free and may be
copied, modified and distributed under the GNU Library General
Public License (LGPL) <http://www.gnu.org/copyleft/lgpl.html> and
it comes with absolutely NO WARRANTY;  mailto:lls@freedomain.org