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, too. 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 question. 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. -- Andrew D Kirch | Abusive Hosts Blocking List | www.ahbl.org Security Admin | Summit Open Source Development Group | www.sosdg.org Key At http://www.2mbit.com/~trelane/trelane.key Key fingerprint = B4C2 8083 648B 37A2 4CCE 61D3 16D6 995D 026F 20CF