Preliminary support for tracking active users and the objects they are accessing is described in "BRIDGE-based conferencing support" and "Synchronous awareness support". As of Spring 2003, the list of active users shows user id and login time, along with an indication of whether the access is from the web or the interactive client. The UserList's web view shows name and client time, along with group info for guest accounts. Enhancements to the current implementations fall into three categories:
- Additional status information in the live version of the list
- Enhancements to the user list web view to (e.g.) includes links additional information
- Filtering, to allow a custom user list to be shown for a specific set of users
1. Additional status information
Possible items to be included as status info in the user list. Most/all of these should be configurable through user preferences:
- Idle time. It appears that this could be implemented reasonably efficiently by:
- Adding a singleton idle time registry that other components could notify when intentional (AWT-thread-driven) activity occurs. A thread in this object could check for recent activity updates and modify idle time every few minutes as needed.
- Adding a hook in
bridge.util.ModificationTracker to notify the idle time registry when an object is changed. Now that ModificationTracker effectively resets every few minutes, it would likely be practical to indicate activity only when a modification time/user update is generated.
- Adding a hook in
bridge.swing.WindowMenu to notify the idle time registry when a window is activated, deactivated, opened, closed, iconified, or deiconified. These events are infrequent enough that all occurances could result in activity update. Some care would have to be taken to ensure that remotely opened windows (e.g., chat windows or windows on a shared workspace) did not trigger a false activity indication.
- An initial implementation of this has been added (030912):
-
cork.models.userlist.SessionData now has an idleTime property, of type java.util.Date. Using a date here lets us get away with only updating the property on a status change.
-
bridge.util.IdleTimeTracker periodically checks for activity and updates the idleTime property in SessionData. Activity updates are generated by the bridge.util.ModificationTracker and bridge.swing.WindowMenu. ModificationTracker already has a listener interface for this sort of thing. WindowMenu may need one as well.
-
bridge.apps.web.WebSiteEditor sets up the IdleTimeTracker
- Status string. This could be a free-form string that the user could set to whatever they wanted, e.g., "gone to lunch".
- A standard set of these ("available", "away", "busy, but available") could be provided, and a user-defined set of options could also be stored.
- The time at which status was set could also be provided. (Idle time indication makes this somewhat less useful.)
- An initial implementation of an open-ended status string was added 030912.
- Icon or picture of the user. Ideally this would be selectable from any readable object that could render an
image/* mime-type.
- More detailed information about guest accounts, for example, the path to the accounts object against which the user authenticated.
- There should possibly be an option in the accounts object to disable this.
- Optional affiliation info. In particular, it would be useful for new users to know who the VT people in the list are. The status string could be used for this.
- Access list of active objects. This should definitely be configurable, and disabled by default. Minimally, it should not reveal any information that a user could not discover by brute force inspection of all readable objects.
- A checkbox on the user list to enable/disable this (possibly defaulted on or off by persistent preference) might suffice.
We might also want to consider adding a "public chat" attached to the user list. Like most user list ideas this has scalability issues, but we might decide that the community-building issues trump scalability for now.
In addition to new state to be presented in the user list, we also need to examine the means by which a list repaint is triggered. For example, changes to client type state (which happen shortly after login from the web) are not immediately reflected in the user list. [Class bridge.swing.ListRepainter was added 031201. A subclass of this handles repainting the user list when changes to SessionData objects are detected. It also does periodic repainting to handle locally-computed values such as idle time.]
Several of these enhancements suggest the need for persistent, per-user preference storage, e.g., a "Profile" object, stored in the user's home directory.
2. WebView enhancements
The initial implementation of a web view for the system user list shows:
- User IDs
- Account database ID number for guest accounts
- Indication of web users
Problems include:
- No indication of idle time, status, login time, or activity
- Account database ID is too obscure to be meaningful beyond simply grouping users
Possible enhancements include:
- Use of grouping to separate web vs. interactive users
- And, possibly, idle vs active users
- Need to avoid use of font/style changes, though horizontal rules might be OK
- Inclusion of path information for authenticated guest accounts
- Link to popup (?) with additional information (login/status/idle time), and possibly option to initiate chat
|