|
|
|
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)
|
|