[178] in Athena User Interface
Draft: RFC on Gnome Menus
daemon@ATHENA.MIT.EDU (Christopher D. Beland)
Thu Jun 15 18:07:27 2000
Message-Id: <200006152207.SAA00477@interstitial-spaces.mit.edu>
To: aui@MIT.EDU
Date: Thu, 15 Jun 2000 18:07:23 -0400
From: "Christopher D. Beland" <beland@MIT.EDU>
The plan for this document as I understand it:
1. Y'all comment on it.
2. I update the components tracking page.
3. I make revisions and add screenshot and HTML links, and post this
in our project notebook.
4. Someone e-mails a URL pointer to owls@mit.edu. (Anywhere else?)
Note that this document includes new proposed details on how the Gnome
system should work, which others should ponder, and new information
about Project Pismere collaboration. (I talked to Tom Thornton and
some student developers today. More on that later.)
--
The Athena User Interface (AUI) team is currently in the process of
adapting the Gnome desktop for use in MIT's academic computing
environment. The Dash menu will be replaced by the Gnome Panel, which
usually takes the form of a gray bar that resides at the bottom of the
screen. The panel (which has a user-configurable appearance and
location) has status icons and buttons for launching common services
and applications, and a "start" button providing access to set of
configurable menus.
We hope this interface will provide a friendlier gateway to Athena for
users familiar with the Windows and Macintosh operating systems, while
still providing the power and customizability of the Unix environment.
[Include screenshot of Gnome User with caption]
We are currently designing the scheme by which pre-defined menus will
be organized and maintained. Our primary goal is to make it easy to
find all the software one might ever need from on Athena through the
menu system. Compounding factors include the need for brevity (to
make it easy to find things), the need for completeness (to make it
possible to find things), configurability, supportability, long-term
maintenance, the need to organize software in clear conceptual
categories, and the complicated maze of overlapping administrative
entities.
We would like to involve the user, administrative, support, and
development communities in the design process; as such, we are
soliciting your input on the project and ideas on how we can ensure
that the end result meets as many of the needs of the MIT community as
possible.
The message that follows details our current, preliminary design.
Feel free to circulate this document; send feedback to aui@mit.edu.
Thanks,
The AUI Team
--
Project Status
Formal usability testing with a early beta prototype is planned for
the end of Summer 2000. A complete list of project components, noting
which are required for this preview release, is available at
http://web.mit.edu/aui/notebook/components.html. (See also project
notebook.) Opt-in, campus-wide testing is anticipated to occur over
the 2000-01 academic year, with the new interface potentially becoming
the Athena default in the 8.5 release of Summer 2001.
Specifically with regard to the Gnome Panel, we are still in the
process of defining our list of core supported applications (like the
new mail reader and word processor), and will soon begin a
comprehensive review of available Athena software.
Before we decide exactly what programs are "in" or "out" and where
they belong in the menu tree, we need to clearly define an
organizational framework. A straightforward hierarchical tree of all
the useful software in all of the public Athena lockers would be far
too large and unwieldy to be practical, and so the Gnome menus require
a something more sophisticated. We would like to define, with your
help, exactly what that something should be, so we can move on to the
the cataloging of programs for individual menu entries.
Lay of the Land
The Gnome menus are designed to be the desktop's access point for the
bulk of system software. It is designed to be the launching pad for
programs used both frequently and infrequently, in addition to being a
universal repository for configuration tools and capplets, and add-ons
for the Gnome desktop. (Very frequently used programs may also be
launched from the panel, and sometimes the file manager or other
applications.)
The menus do not necessarily correspond to any physical or logical
filesystem; rather, they represent an organizational constellation of
useful programs. The Gnome file manager is the appropriate interface
to actual filesystems (subject to some amount of hiding from novice
users if so configured). Files on local disk, remote filesystems, and
removable media appear in the file browser. Removable media are also
accessible from icons which appear on the panel itself.
Making Lockers Gnome-Aware
One useful organizational grouping for the menu hierarchy is the
locker itself. This applies to lockers with a limited amount of
software that have a clear and directed purpose. For example, the
course locker for 18.03 might contain a small number of mathematics
packages relevant to the class. This grouping also may make sense for
lockers with a single administrator. A user's personal locker, or that
of a friend, might contain familiar applications that the user
mentally groups as being in the same "place" (perhaps as part of a
class project).
Users should have the ability to add the pre-defined submenu
corresponding to a particular locker to their menu tree. For
instance, at the beginning of the term, a student might add five
course lockers to a "Classes" menu for easy reference.
Only the locker administrator has the ability to change the contents
of this submenu. The configuration is stored in a special dotfile at
the top level of the locker. The menus can be created and edited by
hand, but more likely would be built using a special graphical editor
designed by the AUI team, most likely based on the existing Gnome menu
editing tool.
Cross-Locker Menus
Most lockers contain software that falls into more than one category.
For example, the SIPB locker contains everything from a mail reader to
Mosaic to file utilities. Many logical groups span multiple lockers.
Network file transfer applications may be found everywhere from
infoagents to gnu to local disk.
The Dash solution to this problem is to assign a central maintainer to
group and update the menu tree appropriately. This system has some
shortcomings, including lack of sufficient maintenance and coverage.
We propose a more compartmentalized approach, in which the relevant
maintainers of a given set of software (say, SIPB and Athena Delivery,
or Course 18 and Academic Computing) cooperate on menu maintenance.
Thus all administrative entities which contribute software to the
"Spreadsheets" group would share control, enforced by AFS ACLs. A
special locker or directory would be created (depending on performance
and implementation details) to hold the configuration files. Users
could add these menus just as they could the menus for the
single-purpose lockers. We hope this will lead to more frequent
updates, though we will work to ensure that the most important lockers
have updated Gnome menus before we make a public release.
Custom and Local Menus
In addition to rearranging submenus, users should also have the
ability to create icons that point to arbitrary binaries in the
filesystem. They will be able to use the same (or a similar) tool as
the locker maintainers to do this.
Some workstations - such as home machines or those in academic
clusters - will have additional software installed locally via RPM or
some other package management system. A desirable feature of the
Gnome menu system would be to detect menu entries deposited in
standard locations (generally by applications targeted at Gnome,
Debian, KDE, or AfterStep) and create a special "Local Software"
submenu.
Cross-Platform State
The set of panel icons and menu entries should not be reduced to the
least common set of software available on all Athena platforms; any
program available on any platform should be includable. Users should
also be aware of what software they might be missing because they are
logged in on a particular platform. In the worst case, users might be
led to believe that a particular piece of software was not available
because they could not find it in the logical place on the Gnome menu.
In the best case, users would know immediately that to run a needed
but infrequently used piece of software, they should change platforms.
Thus, all panel icons and menu entries should persist from login to
login. If the associated binary or script is not available, either
the icon should gray out, or the user should receive a message
explaining the situation on attempted execution. (If the former
solution is implemented, this should be clearly and prominently
documented.) A bonus feature would be the ability to configure icons
to default to a more widely available program (or perhaps a different
version of the same program) if the preferred application is not
available.
Project Pismere Collaboration
We have begun to collaborate with project Pismere on user interface
design in several areas, including the menu system. The goal is to
allow the Window Start Button to carry some or all of the same menus
as the Athena Desktop. This is being accomplished from Dash by
parsing the global menu definition file. If the AUI team creates a
global top-level list that points at all known locker-level
configuration files, this capability will be maintained with the Gnome
system. It may also help support a mechanism for users find useful
submenus to add to their logins.
The full potential Gnome menu hierarchy, as previously mentioned, will
be considerably larger than the Dash tree. It is currently unclear
how the necessary pruning will be managed for Pismere workstations.
