Subject: Topic
To: Recipients
Cc: PolleZ
Report of a meeting with Dan on 4/22/87 about what to do to Finch before releasing "Finch/Thrush7"
Summary of items from PoachNotes (and elsewhere) relating to Finch
accurate to/from reports
provide some handling of multiple calls: hold, ...
allow placing calls from conversation log
syntax of Phone? command
most recent conversation log entry remains selected when Finch drops out
provide full range of commands from Finch: set db parameters - suppress ringing, etc
**0 back door, **0 flash, **1 cancel ringing, **2 restore normal ringing, **3n#cancel ringing for # minutes, **4 subdued ringing, **5n# subdued ringing for # minutes, hotline, spkrphone, ....
report status of own Lark, other interesting status?
easiest to have status line. fancier could have small indicators on global command line.
show light or phone for Lark operational; UP or DOWN
show cancelled/subdued ringing: bell with circle-slash (1 bell for subdued, 2 for cancelled/ 1 slash for sub, 2 for can/ gray slash for sub, black for can). show expiration of setting? show normal bell to indicate normal ringing. show user-defined ringing behavior?
test potential callee for busy before calling?
show real names of people (rather than Rnames) in logs, displays, ...
show number along with name in Etherphone calls, for user's future reference
Note: the current Finch provides five ways to place a call -- is this good?
Issues concerning the conversation log:
server vs workstation
permanent vs temporary
one log or many (security issues)
relationship to Walnut (defer)
relationship to telephone directories (defer)
role in controlling calls
redial, hangup, hold, conference, alternate (accelerator for hold+conference), spkrphone state
user interface decisions
contents of entries
current status - parties, states
history of states
statistics
error reports
extracted information (eg from tdir)
possible way to enter items in tdir: Phone <person> at <number> (office)
form of entries/log as a whole
Perhaps the log could be treated as one of the directories that you search when making a call.
Proposed management of a single permanent conversation log maintained on the server (using LoganBerry):
Write one log entry for each state change in each conversation
This should allow better debugging, for we would have a record of phone system activity.
We could also write statistics-gathering programs to run at specified intervals.
Compact the log periodically (eg daily) to one entry per conversation (eg the final one)
Prune old values from the log periodically (as needed)
We should consider coalescing this log and the internally cached conversation state held by Thrush.
Proposed workstation user interface: 2 areas of conversation log
an area for active conversations
keyword: value display, rather like an expanded Walnut message
could carry its own operations, with small character-sized icons that would pop up for explanations, thereby allowing 5 or 6 operations in a small space
what to present in the first line is an issue - want most important things there
The easiest thing might be to have a separate viewer for each active conversation. That would make sense out of the active icon stuff we do now. If a new call comes in, regardless of your current state, you get a new icon ringing, labelled as now. If you answer it (say via popup buttons from the icon), it automatically puts any other call on hold. If you conference it, it adds that conversation to the current one. A problem: if your desktop already has many icons, you might not see the new one. If one could force a new icon to appear on the first row (thereby demoting some other icon), it would work except when the icon row has been obscured via Adjust. Choice to be made: conference = answer if no other call, or conference not a valid choice if no other call.
an area for completed conversations
a condensed entry, rather like an entry in a Walnut msgset viewer
can be expanded to a full entry via a command (db query)
Note: although this proposal draws on Walnut metaphors, it only provides a single conceptual msgset for each person's log.
Remove current typescript area in Finch. Called Party & Calling Party area would probably go away too (to be subsumed in commands that could be performed directly from the log).
This means that the "Connecting... connected" information that currently appears in the typescript must go somewhere else.
Also, the typescript area shows the formatted number (eg, directory entry) that will be used, while the conversation log shows the actual sequence of digits dialled (unformatted).
Finch also maintains internal state about currently-active conversations -- how to merge the conversation log with this internal state?
Internal reports - sometimes appear in conversation log entries.
reason (generated remotely or locally)
NB
assorted local inventions
Which of these should be merged and how?
How many log entries to show a user without explicit queries?
probably the current day's entries - could have a user profile option
How to display confidence in caller/callee identity?
currently use "person?" for unauthenticated, "person!" for authenticated
Tension between having callee vs caller in the first line: with visiting and using a single Finch, there is a temptation to make it be the callee. Without these considerations, clearly the caller is the most important item.
fields of an active entry
+ to, via (visitee, if any), from (originator), from (other participants), subject, urgency/priority, time, duration
+ operations
hangup,
hold, answer (guarded iff currently active in another call -- automatically places other call on hold), conference, alternate (accelerator for hold+conference), spkrphone state
I still don't quite understand the meaning of alternate -- how is it different from answering a conference call, if answer automatically holds? Need join operation between 2 separate calls. Need answer that automatically holds + answer that automatically hangs up?
fields of a completed entry
to, from (originator), from (other participants)??, time, duration
could allow annotations: text, voice, etc -- a real Tioga document here (how to implement this??)
+ operations: redial, insert in tdir??
redial originator or entire conference, redial with same/different subject and/or urgency
Call placement
need to provide a call template to fill in to place calls from.
or at least allow eg, Phone Strowger priority:urgent subject:"dial telephones" (I wish we had a consistent syntax for commands with multiple parameters!)
Ideally, you could phone someone from a Walnut message, which would automatically inherit the subject field of the message.
Also (eventually) need a way to set the current priorities and subjects that the callee will accept. Presumably some sort of regular expression or something.
Meeting: Dan & Polle 5/7/87
The idea of a separate viewer for each active conversation seems like an interesting one to investigate. The goal for this scheme would be to eliminate the Finch window entirely. We need to clearly specify all of the "primitive" operations on calls, and show how each would be provided. In particular, operations that take multiple calls as parameters need attention.
A presentation of an active call should include the current state of that call (probably as words, but some states might be reinforced with color, highlighting, etc of the entry. Note: Dan really likes marquee highlighting.) For conference calls, the state of each participant is interesting.
An active conversation could include a field for comments to be added during the conversation: text, voice recordings, etc. Since LoganBerry only recognizes strings up to the first CR, one could specify that the Comment field would not be retained in the LoganBerry database. To save the comments, the participant would have to mail them (or the entire active entry), save them, or something. This actually provides a nice cross-over between telephone calls and email: only important calls (as defined by some participant) become email, by explicit request.
The ability to invoke operations from a closed icon (a la Cafeteria) will be explored after the open viewer functionality is settled (because they will presumably be the same or at least similar). In addition, we should revive Cafeteria's version of TiogaButtons, which allowed buttonhood to be temporarily removed for editing.
I was thinking of the active conversation area(s) and the completed conversation log as disjoint sets. Dan was thinking of them as different views. That is, all calls appear in the conversation log, even currently active ones.
Dan suggested that each entry in the conversation log have three levels, normally clipped to one: the first level is the current/final description of the conversation, with two lines. Duration, subject, priority, and possible reasons are secondary information. (Q: is the second line at a different Tioga level??) The second level is an expanded view, as in an active conversation viewer. (I'm not sure I see the need for this level, since all of the same information (without field names) would be available in level one. It could be an aid to copying it into a call-placement viewer, however.) The third level shows all of the successive states of the conversation. (Note that grouping all of the information about a given conversation together presents an organizational challenge for real-time updates. That behavior might come automatically from LoganBerry queries?) This last level could be directly useful for debugging.
Can a Tioga format specify invisible fonts, so that the user could toggle some fields of the log in and out of existence easily? For example, this might be an answer to whether or not to show the phone number associated with a caller.
The number of different kinds of telephone control viewers would grow. And there are/would be currently different mouse control actions in each. In a Tdir, there are: select, phone office, phone home. In a conversation log, we would like to have redial (+ ?). (If the conversation log contains active conversations, can one operate on those calls there also?) In an active call viewer, there would be answer, hang up, hold, ... Should we try to create a single uniform mouse action space for all telephone-related viewers (and use PopUpButtons for documentation of this uniform space), or should we use the different viewers to allow multiple simpler mouse action spaces? Note availability of PopUpMenus as well as PopUpButtons.
Part of the information about a call might include a picture of the caller (for flash), and the authenticity of the caller might be depicted there also: paint a moustache, Groucho Marks schnozz, or dark glasses on unauthenticated callers. Other possibilities for presenting authenticity include bold vs. plain, or color.
-----------
Primitive operations on "active" conversations, where active means any conversation that is in progress (possibly on hold, etc.). To support the single viewer per conversation model, these operations should be expressed as unary operations on some conversation. Where this is not possible or natural, it represents a weakness for the single viewer model.
Option 1: The "current" conversation is the single conversation that has use of the speaker/handset. Audio mixing occurs only when parties are in the same conversation, so one can add or subtract parties to control it. A conversation is
ringing,
current, or
on hold.
(
phone: launch a call to the specified party(ies)
option 1. and make it the current conversation
a. place any other current call on hold.
b. hang up any other current call.
c. add parties to current conversation
option 2. let it fend for itself for the moment)
answer: make this conversation the current conversation.
option 1. Can only be performed when no other conversation is current.
option 2. Place any other current call on hold.
option 3. Hang up any other current call.
hold: place this call on hold. Hold means that you are not listening to (or generating) the audio associated with that conversation -- it does not mean that the incoming audio is in any way paused. (Could do a special case for the synthesizer that would automatically Pause before holding). For the moment, a held synthesizer conversation is still reserved by the holding party. (Probably want a timeout to ensure that these don't tie up the synthesizer accidentally. Would a timeout be useful in general?)
option 1. Can only be performed on the current conversation.
option 2. Can be performed on any active conversation. Would allow a call to go directly from ringing to hold (possibly a bit disconcerting to the caller).
hangup:
remove self from this conversation. Status of others in conversation is unchanged, despite originator status of conference calls, etc. Display of this conversation disappears unless a) something has been typed in the
Comments field, or b) user has previously clicked
Save for this viewer. Could also have a special HangUpAndSave option, like blue-button or something.
option 1. Can only be performed on the current conversation.
option 2. Can be performed on any active conversation. Allows a person to reject an individual ringing call directly, without programmed parameters.
option a (orthogonal to above). Automatically
add call to current conversation (results in conference)
option 1. Can only be performed on the current conversation.
option 2. Can be performed on any active conversation (must then specify both conversations).
remove party(ies) from current conversation
make call a background call
Option 2: Audio mixing is controlled separately, so one can listen to multiple conversations at once. This is the most flexible for controlling who hears what, such as calling the synthesizer or the recording service.
For purposes of ring tunes, the originator is identified as the caller, even if it is a conference call.
Might be nice to know whether callers/callees are running Finch, so that you know how much they can tell about what's happening. That way you know whether to use the shortcuts that the system provides for telephone conversations (eg, they know who you are already). Could show via special font, or character (eg, *+) appended to caller/callee name.
-----------------------
PacTel Series 500 (5+10 function keys & lights, no display)
basic feature keys: call, answer, hold, group, re-dial
call used to access outside line
answer used to answer outside line/grab calls directed elsewhere
hold toggles hold/unhold (actually alternates between 2 connections). hanging up from this state "parks" the call so that someone else can connect to it (by dialling #<parking station number>)
extended feature keys: speaker, camp-on, call wait, do not disturb, voice call, retry/flash, mic off, call fwd, add-on, direct
add-on adds the current conversation to the (single) held call
many are toggles
direct calls a single location
* <2 digit> calls speed calling number
indicator lights (actually all keys have associated indicators, probably as much for confirmation as anything)
speaker, do not disturb, mic off, call fwd
distinctive ringing tones indicate origin of call
-----------------------
Should log initiation/cancellation of visiting, preferably at both Finches. Because of the single server-based log, it would be allowable to log forwarded calls at the receiving Finch only (if that is easier). The user could get a new updated view of the log when he returns to his office, as a side-effect of issuing the Visit/Unvisit command. A remote Unvisit should provide the same function, if possible.