Troubleshooters.Com Presents

The Universal Menu System (umenu) Open Source Project

Project Charter

> < ^

Why umenu?
Design Manifesto
Intended Audience

Why umenu?

Ease of Use
Automated Documentation
Command to Application Conversion
Portable
Free, No License Hassles
Easily and Universally Configurable
Respectful of Your Existing System

xistingSystem">Respectful of Your Existing System

Ease of Use

I originally created this menu system for just one reason -- to counteract this objection while selling and advocating Linux server systems:

"But Linux is so much harder to use than Windows"

This oh so true sounding piece of "common sense" is actually a clever use of an apple-orange comparison, which, when examined carefully, is marketing hype. The true statement would be:

"The Linux command line is so much harder to use than the Windows start menu"

And here's another true statement:

"The Linux umenu interface is as easy to use as the Windows start menu interface"

If your users, clients or customers complain that the box you're giving them is "user unfriendly", a umenu demonstration will ease their fears. If you'd like to use Linux servers but are afraid of administration problems, umenu can make day to day administration trivial.

If you have any kind of "user friendliness" issue, check out UMENU.

Note!! In March 2002 Troubleshooters.Com published the specification for EMDL (Easy Menu Definition Language), together with an EMDL to UMENU converter. That makes UMENU menu system authoring an order of magnitude easier and quicker. EMDL is available via the Troubleshooters.Com projects page. EMDL is, and will always remain, text editor configurable. It's fast and easy with any autoindenting editor, and lightning fast with VimOutliner.

Automated Documentation

UMENU isn't just for the computer illite isn't just for the computer illiterate. Every network and system administrator and programmer has a "cheat sheet" of scripts to relieve themselves of the manual labor associated with arcane commands. UMENU is just such a "cheat sheet", automated to run commands with a couple keystrokes.

Command to Application Conversion

Command line operations are extremely flexible and powerful, but often tricky. UMENU can convert the most complex command into a prompted "mini-app" by prompting for each command line parameter in whatever order the menu designer desires.

Portable

Imagine having the same menu structure available at telnet teletype terminals, curses or ansi.sys enhanced character terminals, GUI (Win, X or Mac), or on your browser (via either CGI or Java). UMENU's Menu Definition File specification makes it possible.

Imagine being able to use it in Linux, Unix, Win, Mac, or pretty much any other place. UMENU is written in PERL, so it will run where PERL does. UMENU's object structure is designed for portability. Note also that it can quite easily be ported to Python, C++, or any other OOP language.

Free, No License Hassles

UMENU costs nothing, no matter how many users. No need for software metering, and no hassles with the Software Police. You can try it with a clean conscience. You can confidently use it as a building block for your enterprise, knowing you have full right to view AND MODIFY the source code.

So as long as you respect the GPL License, basically meaning you can use and/or give away and/or sell and/or modify the program, as long as you give the recipient all source code and these same licensing rights these same licensing rights and responsibilities, including leaving all copyright notices intact. Basically, you can do anything except make it proprietary.

Note that we have plans for an API so your proprietary programs can use UMENU without becoming Open Source themselves.

Easily and Universally Configurable

We've all been frustrated by configuration programs that don't work, or don't work the way we want them to, or keep us in the dark as to what's going on. It's for that reason that I specified that ordinary text editors can be used to do all UMENU configuration.

We hope that configuration programs are created to make configuration easier and more foolproof. But we insist that the administrator always be able to fall back on a simple text editor for all UMENU configuration.

Respectful of Your Existing System

The Windows Registry taught us a valuable lesson. "Shared" systems are just global variables that inevitably cause bugs and make maintenance a nightmare. Registry-enabled apps invariably break as new OS versions and other apps change the environment. New installations often break existing software. Complete de-installation is a thing of the past. And there are maybe ten people on the planet who truly understand (and truly care about) the registry.

UMENU is different. Installation is as simple as copying its files into a new directory tree. That tree contains everything. De-installing UMENU is as simple as deleting its directory tree, deleting any config files you chose to create outside of that tree, and eliminating the UMENU_CONFIG environment variable.

Design Manifesto

The Universal Menu System has certain overriding design principles. At the highest level, these boil down to productivity, reliability and portability.

Productivity

The Universal Menu System's SOLE benefit is improved productivity. That means saving time, and avoiding mistakes.

Saving time

UMENU offers access to hundreds of commands with a few keystrokes. The commands can be categorized and arranged to eliminate time-consuming manual and help file reading. That same categorizing and arangement minimizes keystrokes. Complex command line commands can be converted to user friendly apps using UMENU's Prompted Argument Substitution feature.

UMENU accepts keystrokes without requiring an extra press of the Enter key. UMENU accepts typeahead so once the user is familiar with the menu, he or she does not need to wait for repaint (especially valuable to touch typists, and in telnet sessions or other slow connections).

Avoiding mistakes

A single chown or rm command can render a system useless, resulting in loss of days (or weeks if backups are inadequate). UMENU can be used to limit the user's activities to those things less likely to cause problems, and can minimize the chance of incorrect syntax even on potentially dangerous operations.

Reliability

Simplicity
Modularity
Resource Conservation
Text Editor Configurability

Simplicity

In the last few years of feature bloat we've learned that compexity decreases reliability. Every effort has been made to keep UMENU simple. For instance, menu definitions are not kept in a database, because databases are high maintenance resources often requiring a dedicated employee. Instead, menu definitions are tracked by the operating system itself, via a file naming convention that mimics the heirarchy of the menu structure. UMENU pushes the complexity onto the (already tested) operating system.

Another example of pushing complexity onto the operating system is the fact that all terminal output is simple printable character (plus \n newline) stdio. While this may not be fast or pretty, it's supported by all OS's without need for drivers, additions or tweeks.

UMENU is as simple as a DP 101 semester project. And we're proud of that fact.

Do one thing, and do it well

Part of UMENU's simplicity comes from our design decision to do one thing and do it well. UMENU is a menu system -- nothing more, nothing less. It is not a "shell". It is not database enabled. It is not a file manager, nor an expert system, nor a scripting tool, nor a computer language, nor an authoring t a scripting tool, nor a computer language, nor an authoring tool, nor an XML interface. UMENU's only job is menuing, and it's supurb at its job.

Modularity

The elderly among us (those over 35) remember the days of DOS. An application went into its own directory, and affected no other app. It could be transferred to another computer by copying the tree. In the days of DOS, the Troubleshooter needed only concern himself with that one application (or the OS interface to resources like printers and modems). DOS systems were basically modular.

Then came Windows. In the name of "Seamless Integration", every program's code was thrown into c:\windows\system (as dll's), and every program's variables was thrown together into the registry, a complex database of system-global variables. Every program interfaced with every other program. No modularity. The results were predictable -- constant crashes, monumentally difficult troubleshooting, technologist shortages, and "living with problems".

The creators of the Universal Menu System refuse to be a party to non-modularity. We therefore demand, as a fundimental design constraint, that UMENU be able to operate out of it's own directory tree (which can have any name at any level), with absolutely no interaction with any other subsystem. The sole entry point to UMENU is the the current directory (which should be the program directory) when the UMENU session is begun. The default arrangement of UMENU has the UMENU system's configuration file in the program directory. The default setup of the config file puts the Menu Definition Files in a directory relative to that one. On such a system, de-installation consists merely of deleting the tree and getting rid of the UMENU_CONFIG environment variable.

We believe so strongly in modularity, that we offer neither an installation nor a de-install program. We WANT the person doing the install to know exactly what's going where. We HIGHLY recommend that on single user systems the entirety of the UMENU system go in a single tree, and have designed our tarballs (.gz) and zip files (.zip) to do just that. Our README file contains simple instructions for this simple installation.

"Seamless Integration" is nice in the rare instances when it's needed, but there are plenty of ways of achieving it besides crash-prone executable grab-bags and global variable databases. If, in the future, seamless integration with UMENU is needed, it will be available modularly via our planned API. Rest assuarly via our planned API. Rest assured that if installed correctly, UMENU will never clobber your other applications and resources, nor will other applications and resources clobber it.

Resource Conservation

Moores Law: Disk, memory and speed double every 18 months.

Litt's Law: Coding sloppiness doubles every 18 months. We're barely breaking even.

All developers are glad we no longer need to count bytes and instruction cycles, and that we don't need to code in assembler. But the designers of UMENU do not believe all discipline can be abandoned. "Resource hog" programs crash more, cause other programs to crash more, and are tougher to troubleshoot.

UMENU uses many resource-conserving techniques:

Offload most processing to the PERL interpreter. This saves huge amounts of disk space because PERL is already there, and also saves memory because PERL is tightly coded and tested.
Offload menu lookup to the OS's file system.
Keep individual menus in individual files to granularize memory usage is to the single menu in use at the time.
Limit features to limit resource usage.

Text Editor Configurability

Dedicated configuration utilities are wonderful, but there inevitably comes a time when, during a particularly difficult troubleshooting session, we curse them as black boxes. By keeping menu definition in easy to edit files, we guarantee that problems can be fixed or worked around, even in the face of corruption or config program malfunction.

Text Editor Configurability is and always will be a basic design constraint of the UMENU system.

Portability

Portability has three distinct facets: OS portability,environment portability (plain text, curses/ansi.sys, GUI, browser), and menu portability.

OS Portability

First, UMENU is written in PERL, which is one of the most portable of all languages. Beyond that, UMENU has hooks for OS dependencies, which can be triggered by the os= line in umenu.cnf. UMENU easily runs under most UNIX versions and workalikes (including Linux and BSD), but currently does not run under Windows, although one individual converted an earlier version to run under Windows.

Environment Portability

The current (0.7.0) implementation of UMENU does plain text I/O, right down to using 24 newlines to clear the screen. Since plain text I/O is the lowest common denominator, it will run on every type of terminal. That leaves Java and browser environments. Since HTML and Perl work quite well together, this should be fairly simple if we or somebody else decides to do it.

In worst cases like Java, it's a simple matter of translation to another language. And fortunately, UMENU's code is very simple.

Menu Portability

Absolutely nothing in the Menu Definition Files depends on the environment. That means the menus will work the same in plain text, curses/ansi.sys, GUI and browser. Of course, Menu Definition Files will not work under different operating systems, simply because commands are different in different OS'es. However, for a person conversant in both OS'es, Menu Definition File translation is simple, and can even be assisted by conversion programs.

Intended Audience

Novice users
Intermediate users
Technologists
VARs, Vendors and System Integrators

Novice users

Novice users *cannot* be expected to do a good job in a command line environment. They need a menu to act as a framework for their computer activities. That framework is configured, by administrators, to match their needs while preventing them from getting into trouble. The UMENU Universal Menu System is the perfect framework for novice users.

Intermediate users

Although intermediate users have some skill on the command line, they prefer the simplicity and speed of a menuing interface. This is confirmed by the popularity of the Windows 95/98 start menu. The UMENU Universal Menu System provides them with such a system. Commands can be added or changed either by administrators, or by the intermediate user (probably via a configuration program). UMENU provides all the same benefits as the Windows Start Menu, and in addition provides a much speedier interface for touch typists.

Technologists

Technologists are (for the most part) completely at home at the command line. But command line usage can be slow, especially if the technologist needs to look up the syntax of a command. A technologist can formulate his own menu, with the commands he uses most often, to speed up his work. A further benefit is that the Menu Definition Files he configured can later serve as documentation for similar commands.

VARs, Vendors and System Integrators

The vendor does not sell hardware and software, but instead sells an integrated system for the purpose of performing certain tasks. Often the e for the purpose of performing certain tasks. Often the end user, and even the end user's ability and education, is unknown to the vendor. By supplying a menu interface, the vendor can provide added value and minimize the chance of user problems.

> < ^