Get BeOS 5 Free!!
   
 
 
Requirements

    There are several functions that Einsteinium must incorporate to be efficient and useful.

Selective Memory/Discretion
    Einsteinium should be able to ignore, or be told to ignore, certain applications and documents, such as:

  • Applications that are automatically invoked by UserBootscript or by opening a file
  • System server daemons that are activated rarely
  • The Deskbar and Tracker (again, system components)
  • Confidential documents or folders that the user does not want out in the open
  • That URL you go to every day that contains the word "spank"
Rank Manipulation
    Every rule has exceptions. If we use the rule that applications or documents that get accessed more often than others are more important, there will certainly be exceptions to this rule. Enabling artificial rank manipulation leaves room for exceptions. The user must be able to:
  • Confine an app/doc to a concrete position on the list
  • Confine an app/doc to a particular level, but allow it to change position in that level
  • Increase/decrease the importance of an entry, either by position or by level
    (useful for fine tuning a list that is pretty stable)
  • Kick an app/doc off the list entirely (not the same as telling Einsteinium to ignore it)
    One notable exception to the rule is when a user is experimenting with new shareware/freeware. A large percentage of such applications get used several times and then discarded. To avoid having them show up on the list, new applications should be put on a "waiting list" of sorts, and only added to the main list after a certain time period and number of activations have been passed. Of course, the user should also be able to decide immediately to place the new app on the list.

Simplicity!
    The human mind can only comprehend seven different objects at once, and that's pushing it! When you display more than about 6 choices in any situation, the user is forced to break up analysis of the choices into multiple sweeps, comparing two or more groups of choices with each other. Therefore, Einsteinium should, and will, only show 5-7 objects per layer/level. However, through expandable sublists the entire list can hold 5-7 layers/levels as well, making the total number of entries on the list between 25 and 49, which should be more than enough.

Automation
    Well, d'uh. But seriously, if an application can automatically add things to a list, it should also automagically remove items from the list that are no longer used. The goal is to have an absolute minimum of user intervention in managing the launcher. Therefore, a half-life concept should be applied to the items on the list. Over time, items that are no longer used will move down the list and eventually fall off, without the user ever lifting a finger. True intelligence.

  • An INTELLIGENT application launcher. An application called "Kagari" has a start on this, but lacks a couple of levels of sophistication that would make it extremely useful. What an intelligent launcher needs to be useful:
    • The ability to be told to ignore certain applications, such as system servers which you may upon rare occasions need to restart or applications like Expander that open automatically when you unzip an archive or even applications that are run by the system itself, such as anything in Bootscript or UserBootscript.
    • The ability to "tack" an application to a particular spot (or level) on the list, making it permanently more or less important than other applications, even if it isn't used as often as the applications below it, or is used more often than the applications above it.
    • A derivative of the above is the ability to "bump" and application up or down in importance on the list. This would be slightly different from "tacking" the application, and would still allow it to travel up or down on the list as the applications around it gain or lose importance. A simple method for doing this is artificially assigning a higher or lower rank to the application that is being "bumped".
    • A launcher that is designed to make the user's life simpler shouldn't display more than 6-10 entries in each level. What's the use of something that displays every application on the system? If that's what you want, just open up the Be menu! For applications that don't fit on the first level, there should be drop out panels for several deeper levels. This way, the most used applications get displayed first, in a clear and concise manner.
    • New applications should be put on a "waiting list" for at least a week, to make sure they don't get in the way and then just take up space on the list after the user deletes them. This would be an incredible boon to people who download and mess with a lot of shareware and freeware programs and then throw away the majority of them.
    • Application ranking itself should use an AI technique like averaging and deterioration over time. In other words, applications that are deleted, or are no longer used as often for any reason, will over time make their way down to the bottom of the list as the rank is lowered, and then they will be deleted. Shazam, the user doesn't need to edit the list to remove old applications! Wow, what a concept, huh? The time since activated should be averaged in with the number of activations somehow, in order to accomplish this. The algorithm shouldn't be too difficult to figure out. The user could even be given the choice of customizing or de-activating the rate of deterioration.
    • A perceptive programmer would note that all of these options could be implemented pretty easily using file attributes. Whenever an application is run and the signature is caught by the launcher, make a zero-byte file (like People files) in a settings folder, then assign an attribute for each piece of data about the application that needs to be remembered for the algorithms:
      • Name of application (Each app on the list should be renameable, so something like "smtpd" can be named SMTP Daemon, which is great for apps that have terrible names or multiple copies of the same app in different places on the drive. How else could the user tell which name pointed to which version?)
      • Unique application signature
      • Whether the application should be ignored (!!!)
      • Date of first activation
      • Date of last activation (deterioration algorithm should take into account how long ago the last activation was -- if the app hasn't been activated for a long time, the odds are higher that it has been deleted than they are if the activations just went down slowly over time and the last activation was pretty recent, therefore it should deteriorate and be removed from the list more quickly)
      • Number of total activations
      • Date when application is allowed to leave the "waiting list" (probably redundant as long as the date of first activation is set, unless the user will be allowed to set a longer/shorter time for a particular app)
      • Whether the app is "tacked"
      • Position if "tacked"
      • Whether the app has been "bumped"
      • Whether the app was "bumped" positionwise or levelwise (Levelwise "bumping" will mean that the app will be shifted onto a different panel in the drop out panel list, where each panel should have a maximum of 6-10 apps on it, as opposed to positionwise "bumping" where the app is only shifted up or down by one app position. Is this redundant and too complicated? Possibly.)
      • Factor of "importance shifting" if app has been "bumped" (apps can be "bumped" up or down more than one position or level)
    • A separate settings file should keep track of some other things that will affect the whole list and will be changeable by the user:
      • Waiting period for apps on the "waiting list"
      • Number of apps to show per level
      • Number of levels
      • Rate of deterioration
      • Directory trees/folders to ignore (is this possible if we mainly work with application signatures? I don't know.)
      •  
    • Other things that should be built in to decrease user frustration:
      • User should have a choice whether to put the launcher in the Deskbar as a replicant, on the desktop as a replicant, or just float around as a toolbar, or any combination of the above.
      • Toolbar mode should be dockable to any screen edge.
      • Toolbar mode should be autohideable.
      • Toolbar mode should have settings available to make it take the same position in all workspaces, or not.
      • Toolbar mode should have the ability to not show at all in some user-selectable workspaces. This way if the user always uses workspace X for playing full screen games, she can turn it off in that workspace and still use it in all the rest. Slick.
      • Deskbar replicant should be easily reloadable if the Deskbar crashes. (see my DeskAttendant application for more tirades on that subject)
 
   

BeNews                              Red Bear Network Services
Site design by Red Bear Network Services
All information is Copyright ©1999-2000 Kris Finkenbinder and individual authors.