Douglas B. Terry
Abstract: This is a draft of some of my ideas for a telephone directory browser.
Introduction
Browsing paradigms
There seem to be (at least) two possible paradigms for allowing humans to browse through a whitepage database (or collection of databases); I'll call these the Clipping model and the Query model.
The Clipping model portrays the complete whitepage database as a hugh document that a user can browse through. Browsing, in hopes of locating an entry with particular characteristics, is made easier by having only parts of the document visible at any point in time. Portions of the whitepages may be hidden by user-directed or program-directed clipping operations; needless-to-say, operations are also needed to redisplay clipped data. The "Levels" buttons in Tioga provide an example of a particular type of clipping. More general clipping operations would be needed for conveniently browsing very large documents, such as a 20,000 entry whitepage database.
The Query model builds a collection of directory entries that can be browsed by running a query on the whitepage database. While a query can be of the form "Retrieve everything in the database", the query is generally intended to limit the amount of information that must be browsed to find a desired directory entry. The more precisely specified the query, the less data there is to browse. In the extreme case, a query uniquely specifies a single entry, e.g. "Retrieve Rname=Terry.pa", and the browsing phase is trivial.
For either of these browsing models, the interactions between the database and the viewer displaying directory entries must be complex in order to achieve good performance when browsing large amount of data. Such interactions remain to be explored.
A prototype whitepages browser
A prototype browser, based on the query model of browsing, was built in September to test out some ideas. The prototype browser is embodied in a viewer containing two sub-viewers: the query-panel and the browser. The browser sub-viewer looks identical to current Finch directory viewers except that its contents are determined by the query-panel. That is, it consists of a list of directory entries that are TiogaButtons and can be used to place phone calls (and could maybe do other things?).
The query-panel is a form containing fields for all of the information in a directory entry, e.g. Rname, Name, Office Number, Home Number, etc. A user performs a query by filling the form; a regular expression (or at least a pattern containing wildcards '*') may be used as the value for any field. When the "Browse" button is clicked, all entries matching the form are retrieved from the whitepage database and placed in the browser sub-viewer. (This is like Query-by-Example or Query-by-Form.) The user can specify the attribute on which entries in the browser will be sorted. The query may involve merging the contents of several whitepage databases (though this was not implemented). If several databases are used, an additional field should exist in the query-panel to allow the user to confine the query to a particular database, e.g. I'm only interested in entries from my private database.
Updates to a database can be accomplished in a similar manner: a user fills in the form and clicks "NewEntry". (This was not implemented.)
Whenever a user clicks "Browse", the contents of the browser sub-viewer is updated to reflect the current query and the old contents are discarded. Occasionally, a user may wish to retain the browser's contents in a phone book. The "PhoneBook" button creates a new phone book viewer containing the directory entries currently in the browser. In this way, a user can create any number of phone books for future use.
Issues and requirements
A meeting of the Voice Project members on October 18 produced the following preliminary design issues concerning the user interface, functionality, and data model for a whitepage browser:
User interface: A menu-based tool interface will support some combination of querying and clipping for convient browsing. The types of clipping that are needed remain to be explored; Tioga style level-clipping may prove useful. Templates can be used as forms for specifying queries. A query "history" containing specs for recently executed queries is valuable for resubmitting queries. (Multiple query viewers could be used.) Whitepage querying facilities should also be available from CommandTool commands and integrated with the existing Finch commands. In cases where a whitepage query yields multiple callees for a "phone" command, a browsing viewer can be created with the results of the query.
Functionality: Queries involving multiple databases should be supported. The retrieved database entries could be either merged into a single browsing viewer, or else displayed in separate viewers. The types of queries allowed might range from simple retrievals based on the value of a single attribute to multiple attributes with regular expressions and/or Soundex. The management and backup of personal databases residing on either a server or local machine must be worked out (for both startup and steady state).
Databases: Indicies may be needed (or desired) for rnames (GV and NS), fullnames, feepnames, Soundex codes, firstnames, organizations, registries, etc.
Some problems may arise when trying to incorporate private telephone directories. First, not everybody listed in a private directory has an rname, so rnames may not be acceptable primary indicies. Second, we must work out conventions for storing personal databases on servers.
Performance issues include performing queries without resorting to exhaustive enumeration and incrementally retrieving database entries satisfying a query in response to scrolling directives.
Telephone directories for Voice 7.0
Date: Wed, 25 Mar 87 12:19:18 PST
From: Terry.pa
Subject: Telephone directories for Voice 7.0
To: VoiceProject^
Cc: Terry
Reply-to: Terry.pa
This is a proposal for how to manage, update, and use private and public telephone directories (tdirs) in the new voice world. I'd appreciate any comments you can give me on this design. I'm happy to go off and implement it; I just want to make sure that we are in agreement before doing so.
Telephone directory management
As is currently the case, public whitepages information should reside in a LoganBerry database on the server. In addition, each person's private directory will also be stored in a server-managed LoganBerry database. That is, the server will store one public database and N private databases where N is the number of Etherphone system users.
Each tdir database will contain the same attributes as the current tdir files: name, work#, home#, and remarks. Additionally, I'd like to see a field for a person's electronic mail address.
Questions: Should an entry be allowed to have more than two phone numbers, i.e. should we generalize to an arbitrary numbers of phones for a user? This raises the issue of which of many numbers to use if someone says "Phone Fred" and Fred has multiple numbers. Should we have separate fields for first and last names? Or maybe a field for a person's full name and another for his nickname? Is a remark field sufficient for other information, e.g. some people keep street addresses in the remark field while others keep organizational affiliations?
Browsing and updating directories
The following goals influence this design:
* It should be easy to place calls
* It should be easy to add information to a user's private directory
* Personal data should override public data
* A common directory should be used for telephone and mail recipients
Two styles of browsing are convenient: ad-hoc queries such as those allowed by the LoganBerry browser (and demonstrated in the video-tape) and pre-fetched data that can be browsed such as the current tdir files. Observe that the current tdir files can be viewed as simply the result of a query that has been preserved.
The LoganBerry browser will serve as the basis for interactively browsing private and public tdirs. (I need to re-introduce the notion of merged databases to the browser). The result of a query will be a set of Tioga buttons similar to those in a current tdir. Clicking on different attributes of a returned entry invokes different operations:
Buttoning on the name simply highlights the entry.
Buttoning on the work# places a phone call to that number.
Buttoning on the home# places a phone call to that number.
Buttoning on the mail address creates a walnut sender with the recipient address filled in.
Buttoning on the remarks is a no-op.
Note that, unlike the current tdir, it doesn't matter what button is used to click on a field.
The results of a query can be saved for future use in a "phone book". In database terms, a phone book is a "materialized view" or a "snapshot". The tdir browser will have a menu operation that creates a phone book having the selected name. If a user selects the word, "Private", and clicks "MakePhoneBook", a file, "Private.phonebook" will be created with the contents that are currently present in the browser's output viewer. Phone books behave identically to the browser's output viewer; think of the browser's output as a temporary phone book.
Users can create as many phone books as they want, smodel them to file servers, etc. Of course, an operation is required that takes a phone book file and turns it into the appropriate TiogaButtons. This can be done by an explicit CommantTool command or a Finch menu button. In addition, a user profile entry can specify which phone books should be automatically opened when Finch is run; this is analogous to the current "Finch.TelephoneDirectory" profile entry. Finch can continue to have a "Directory" operation that opens the desired phone books (in case the user has destroyed their viewers). Finch will also need a "CreateBrowser" button.
Updates to a user's private directory can be done interactively by filling in the browser's form and clicking "NewEntry". There will also be a button for "DeleteEntry". (These buttons are identical to those in the vanilla LoganBerry browser). Public tdirs will be treated as read-only. They can only be updated by a voice guru (as is currently the situation).
The Phone command
A "Phone" command allows easy call placement from a command tool. The new Phone command is similar to the existing one but runs queries on the public and private tdir databases. Its most general form is like the LBQuery command (see LoganBerryToolsDoc.tioga):
Phone attr-type(filter): attr-value attr-type(filter): attr-value ...
For example,
Phone name(prefix): Terry
Phone name(wildcard): "*, Doug" phone(prefix): 494
Of course, no one wants to type this much junk. So reasonable defaults will be used.
One approach is to have the filter default to "DWIM" and the attr-type default to "name". This would allow someone to just type:
Phone Terry
But, unfortunately, would not allow him to simply type:
Phone 494-4427
There are two problems with this. First, "494-4427" is obviously a phone number and not a name. The system might be smart enough to recognize this. Secondly, the DWIM filter will see the "-" and think it has a subrange. This implies that perhaps DWIM should not be the default for phone numbers, or else I need a different DWIM.
In fact, in this case, why should it do a query at all? Perhaps we need a "Dial" command that simply takes a phone number, whereas the "Phone" command always does a data base query.
The algorithm used to implement the phone command is as follows:
Run LoganBerryBrowser.FilteredQuery on user's private tdir database
Select number of returned entries from:
1 => have unique result so place phone call (but which phone number do we use?)
>1 => have ambiguous result so open a temporary phone book viewer with the various choices, user can then select which one he wants. (Could also use a pop-up menu to list choices.)
0 => Run LoganBerryBrowser.FilteredQuery on public tdir databases
Select number of returned entries from:
1 => have unique result so place phone call (but which phone number do we use?)
>1 => have ambiguous result so open a temporary phone book viewer with the various choices, user can then select which one he wants. (Could also use a pop-up menu to list choices.)
0 => No match!
Comments? Suggestions?
... Doug
Notes from meeting about White Pages
Date: Tue, 7 Apr 87 16:34:57 PDT
From: Swinehart.pa
Subject: Notes from meeting about White Pages
To: VoiceProject^
Cc: Swinehart
Reply-to: Swinehart.pa
Doug and I met for about 90 minutes to talk about directory browsing.
Here are some notes I had made on his earlier proposal:
1 Users' databases should be allowed to be either local to the workstation, managed by a server, or both. LoganBerryStub makes this trivial to arrange, aside from data management problems (more below).
2 Users should be able to have multiple personal directories and to browse multiple organizational ones (CSL, PARC, Xerox, Palo Alto, ...). Trivial for same reason, this time due to existence of the merged browsing capabilities already in place.
3 I've converted NamesGV to NameDB, an interface that uses LoganBerry databases to implement a white pages (telephone lists obtained from elsewhere), blue pages (the old Lark-registry stuff), and red pages (a cache of Grapevine connect sites and key values for use in RPC binding and in authentication.) I want to be able to do these things later when we have a more highly-developed directory system, so their attributes [sic] should be kept in mind.
4 Lots of other attributes, beyond those mentioned (e.g., home addresses, blood types, ....) should be supported. This is trivial too. A remark field isn't sufficient.
5 Re: the Phone command. There were some questions in Doug's proposal, about how to interpret queries, that could be solved with a simple syntactic parser ahead of the query handler. For instance, entries beginning with digits or phone number punctuation are phone numbers, and all other entries are names.
Here is a list of additional low-level issues that arose during the conversation. Most are suggestions for optional improvements to LoganBerry:
1 If LoganBerry Open were ReadOnly, per log and index file, until a change were needed to that file, SModels of the resulting databases would transfer fewer copies.
2 We need some tools to merge logs with the same primary keys but different additional attributes. This is an alternative to browsing a merged view of several databases at query time. Both are valuable facilities.
3 The LoganBerry browser is inconvenient for making one-field replacements to large entries. A command that would validate and enter the current Tioga selection as an entire entry would be nice. The most likely selections would be browser typescript output, after manual modifications.
4 I continue to believe that it should be possible to write an updated entry into a different log (the activity log) from the one the entry originally came from. This would require cross-log REPLACE specifications, and would impose a replay order constraint when rebuilding the indices. It also eliminates the ability to remove a log and thus remove all history of the entries in that log. Doug points out that I can achieve nearly the same effect, sans atomic replace, with a layer of software just above LoganBerry. True enough.
5 Directories need the Unix-style notion of links -- entries in one directory that refer to entries in another. Probably the methods described below, carefully applied, give us that for free!
6 We should keep in mind the need for "linear enumerations" when multi-valued queries are encountered -- so that, for instance, synthesized voice could be used to guide a Lark-only or outside caller to the desired one of a number of candidates. This is orthogonal to the entire discussion of the next section, as far as I can tell.
Primary achievement:
1 I expressed concern about the "snapshot" nature of the Phone books that Doug's proposed directory browser would produce, and mumbled something vague about wanting direct active views instead. A "redisplay" button like ViewPoint printer icon property sheets have would be OK (to avoid the need for database triggers), but treating a query result as a permanent immutable Tioga file seems like the wrong model.) In very short order, we had developed the alternative notion that phone books should be user-formatted Tioga "forms", some of whose nodes would represent directory queries (e.g., "all of the A's"). One could have various different arrangements within the same document, or different documents organized differently.
2 Users can use the Tioga clipped-view facilities to great advantage, in order to get to the right place in such an active document before invoking any queries (by expanding the view!)
3 A multi-valued query would produce a view based on a standard, simple, form. Operations on selections from that form could be used to find the corresponding entries in the user's personalized phone books, so that near-vicinity browsing could then be employed. The exact value of this approach, and the means to accomplish it, are TBD.
4 There are several data-management problems to be addressed in order to achieve all the multiplicities implied here. DF files and/or the Tioga-style phone books both represent components that can be used to solve them. Ideally, we'd have as few independent mechanisms for dealing with multiplicities as possible. More work needed.
5 Mechanisms similar to those in Super-Calc (and presumably Lotus 1-2-3) for specifying a desire to view either the query functions themselves or their query results, and perhaps for using text editing operations on the query outputs to specify changes in the underlying database, should be evaluated.
Observations:
1 Super-Calc (spreadsheet) similarities observation from previous paragraph.
2 Uncanny resemblance, in functionality and methodology, to scripted documents (!)
3 J. White has been worrying about some of the virtual-document notions needed to support Tioga-style viewing of a document that's produced only on demand. In particular, only the part of the "document" that's currently being viewed needs to be produced. Scrolling operations, Find searches, etc. must generate additional values. Perhaps there's some collaboration possible here, too.
4 Fish-eye views in Tioga become more compelling.
5 To do this right requires developments in many areas (on-demand display in Tioga, hooks in Tioga Find, ...). That would take a long time. However, each of the required concepts can be individually tested in much simpler experiments. We can then predict the behavior of a completed system from the results of these experiments, and choose to integrate only those that we have time for and/or that seem worth it. We need more summer students.
6 The results of these experiments will include a set of user system components that we've needed for a long time for testing some interesting user interface ideas, primarily those dealing with persistence in user interfaces.
7 This is more than enough food for thought, and we should adjourn. So we did.