Color Reactiveness on the Desktop
For the seven-month period spanning July 1997 to late January 1998, I was involved in an OS development project called InSight. Part of my role within the InSight development group was to study interface designs in an attempt to further understand which aspects would still be viable and useful for users for the next five to seven years. In addition to the interface, I had the opportunity to collaborate on the design of the underlying OS, since much of what we were doing on the visible aspects of the system was tied very heavily to the underlying workings of the OS. Bringing together the design of the desktop and the underlying mechanics of the OS, we hit on what we believed to be a good idea—the concept of color-reactive destop elements.
A lamp is a window element in which the color is tied directly to the operational status of the application using that window. Simply put, it is like a status LED for that particular application. As you use the program, its lamp changes color depending upon what is happening and what you'd like it to reflect—CPU usage, program status, etc.
Let's assume you have an e-mail checker which checks your mailbox every two minutes for new mail. Most of the time the lamp in the window remains blue, meaning it is just sitting around waiting for something to do. Every two minutes it turns yellow to indicate it is busy checking your mailbox for new mail. If no mail is found, it goes back to blue. If new mail is found, it turns yellow or begins flashing.
Beacons are like miniature lamps, meant to be used only when applications are in an iconified state. If you have a window open on your desktop, it has a lamp in one corner of the window. Now, when you click the iconify button, the entire application is collapsed into an icon on your desktop. If you still want to monitor that application, collapse it to a beacon instead of an icon. In that way, you will be able to see what is going on with the application without having to constantly open and close it.
For example, suppose you are downloading five different RPMs via FTP. You can collapse each one down to a beacon with a color that reflects whether or not the download is proceeding without problems. At this point, you have five little beacon icons at the bottom of your screen and you can monitor their progress by checking if they are all still glowing a nice shade of green. You could even set it up so that the color was a function of transfer speed. Bright green could indicate a fast transfer; red could indicate a slow or dead transfer.
In order to fully understand how lamps and beacons behave, keep in mind the fact that the color of the lamp (or of the beacon) can be tied to a variety of “behavior sets” such as CPU usage, process status, or specific events which may occur within specific applications. A “behavior set” dictates what actions will produce what colors. Here are a few practical examples.
Suppose one of the above-mentioned FTP transfers begins to stall. One of the beacons begins to glow red and stays red for several minutes. Simply pop the window back open, kill or restart the transfer. The instant you kill that process, the other four beacons begin to glow more brightly, since you have just improved the speed of the other four by freeing up some bandwidth.
Beacons make the task of babysitting multiple applications a breeze. An entire 3-D rendering package could be collapsed down to a single beacon—one that will turn green when the rendering of a scene was complete, for example. There is no longer any need to continually pop the application back open to see what is going on.
Since the behavior of color-reactive elements should be consistent throughout the desktop, a centralized point of control is needed (in the form of a control panel, for example) to allow the user top-level control. From there, it would also be wise to allow the applications, if permitted by the user, to dictate their own behavior sets. Ultimately, the user must have total and complete freedom to dictate the appearance and behavior of color-reactive elements on his or her desktop.
There are two ways to go about changing the appearance of a lamp or beacon on the desktop. With InSight, the plan was simply to change the icon on the fly by loading the appropriately-colored icon in its place. The second way, which takes considerably more CPU time to accomplish, involves hue-shifting the image data within the icon +/- 180 degrees to achieve the desired color.
The first method requires a small cache of colored icons to be present and ready to be loaded. About eight different colored lamp icons (and eight beacon icons) are usually enough to handle most situations. On the FTP site (ftp://ftp.linuxjournal.com/pub/lj/listings/issue58/) is a file called 3039.zip, containing a small archive of example lamps and beacons in different colors for you to look at and experiment with. The eight colors are clear, blue, aqua, green, yellow, amber, red and purple. That's right—the raw image data has already been provided for you. These icons are, in all respects, ready-to-use.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- Tips for Optimizing Linux Memory Usage
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Return of the Mac
- Android Candy: Intercoms
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Designing Foils with XFLR5
- Non-Linux FOSS: .NET?
- Play for Me, Jarvis