Managing Network Monitoring Equipment (RFC)

As I was trolling through SlashDot's Star Trek's Design Influence On
Palm, New Tech (please don't shoot me), I came upon a series of posts
(cited below) that almost got to the point of a problem I'm having: My
network monitoring is hard to use, network monitoring has no standard,
nor prepackaged equipment capable of doing it with minimal installation
time or turnaround because of this network monitoring and lan analysis
varies GREATLY between sites, and between companies.
  This results in increased training costs, and increased acclimation
time for new administrators. Also untrained NOC staff (the poor sap most
companies have doing third shift and overnight NOC work) will not be
able to use or understand display output from these systems. The
solution to this problem is complex, but a feature set becomes apparent:

Theory: (from posts on slashdot)

That brings up an interesting thought. Perhaps if interfaces were
designed to be intelligible on TV, they'd be more usable in reality,

Think about it. People watching the show may not know anything about
computers, but they still had to understand the occasional piece of
information that was important to the plot. (One good example would be
when Dr. Crusher was caught in her son's experimental warp bubble. She
didn't know where she really was until she saw (and the viewer) saw a
picture of the "nature of the universe" and recognized it as something
she (and the viewer) saw on one of Wesley's screens in Engineering.

That kind of driving force behind usability would probably be beneficial
to general use of computers.

From the Star Trek Technical Manual - Page 34

We incorporated the concept of software-definable, task specific panel
layout into our controls because Mike (Okuda) thought it a logical way
of simplifying designs that would otherwise have been nightmarishly
complex. The basic idea is that the panels automatically reconfigure
themselves to suit the specific task at hand.

Practice: (these are from posts on slashdot)

Here in Australia, our new combat "Collins" class subs had a user
interfce designed by committee. It took 13 button presses to designate a
target and launch a torpedo. The generals, when assessing this new sub,
complained that the UI in a Playstation game to at most three clicks to
designate a target and launch; why can't a multi-billion dollar sub work
like that.

The contractor then employed some game UI designers to rewrite the
combat system.

Many years ago, in 1972, I modelled a UI after the displays in "2001".
This was a 24x80 text display on a TV showing the status of a mainframe
computer. The upper half of the screen showed constantly updated status
information. Ever few seconds, the lower half of the screen switched to
a new screen, alternating between a memory map, a job list, status
messages, and requested operator input. High priority messages would
immediately preempt the lower half of the screen.

This was a big hit. People would stand outside the glass computer room
wall to watch. It was self-explanatory enough that people could follow
it effectively.

from one of my admins: "You know, network monitoring should look
something like the Astrometrics Lab on Voyager"

My thoughts on the matter as follows:

1. The system should never suffer from a lack of display area, or
attempt to compact data into a small display area, it should be easy to
understand, and easy to monitor even from a distance.
  This means that the solution will need to be multiple monitors,
preferably with touch-screen support, and a logically structured device
based (be it a server, a vlan, a managed switch, or a router) navigation
method. The control surface and the display surface should not be
discrete, they should in fact be the same device.

2. There is already a wealth of GOOD, and free lan analysis software
out there (MRTG, nettraf, Etherape, Ethereal, tcpdump, syslog, Nettop,
Statnet, phpSysInfo, argus, etc.)
  What this means is that we don't need to reinvent the wheel, merely put
it on the car in such a manner that it gets the user from point A to
point B without any real concious thought, without diluting the tool in

3. This system should be capable of being distributed throughout the
topography and capable of tunneling data with minimal impact
on firewalls, or the current network configuration.
  It should also in whole take a minimal amount of time to configure and
configuration of such a system should not require a reconfiguration of
the whole network. Also configuration should be kept separate from
normal use, and it should be "ready-to-use" out of the box.

My questions are these, is there any use for such a product? What do
you use in LAN and network monitoring? Where are the largest UI
hiccups? What do you want but don't see in your current solution? When
you leave is your staff able to interpret data from your equipment
effectively? Could the whole process be sped up?

I would also like to take a seperate moment to apologize to Mister
Hallacy, it appears we are both being played with, and he has been
greatly helpful in this matter.

Thank you for your time and consideration, and your patience with my
ill-concieved and offtopic posts over the last few days.