Observations It would be nice to provide enhancements and remove a few limitations in follow-on versions of Concur. What follows is a discussion of those enhancements and limitations along with a few other observations made during the development process.
A good designer can provide the means to mitigate his biases. This thought surfaced when defining the indices and when calculating the normalization factors for the CBR. This is an important concept. A good designer needs to be mindful of when his choices are, perhaps, self-centered and the user might appreciate another way of looking at it.
Application developers often provide a preferences capability so the user may express their choices rather than have features hard-coded in the designer's image. Ideally, the application would learn those preferences. This becomes challenging especially when some program options are required to be known immediately or upon first usage and learning requires training or a period of observation.
Also, Concur was built first as a meeting scheduling application and the case-based reasoner was added as a latter step. This suggests to the author that some applications could have a machine learning capability added without too much difficulty. Access to the source code would be required, however, for the modifications invoking the machine learning modules.
Only two?
Concur is limited to two players. Many, if not most, meetings involve more. Increasing the number of players beyond two, or the distance between them beyond 6 feet, requires the use of a communications media other than infrared. Further, current Newton products do not support more than one communication media operating at a time. A network solution seems appropriate with, perhaps, IR links to Newtons and desktop machines for other users. A directory service and name binding protocol would be needed to identify and connect with those parties. To insure timely responses, agent software would be needed so that their users would not be continuously interrupted and to provide a means to support off-line users. Those agents will need to have learned their user's preferences and be fully empowered to represent their users or human intervention will be required.
Overall, the scheduling of meetings is relatively simple. Incorporating an individual's preferences from a trained machine learning module seems likewise simple. The problem gets interesting, however, when the agents are untrained and the individual is not present to render a decision.
The current design asks that one user approve a time before passing it on the other, or next, user. When there are a number of users and user agents, it does not make good sense to apply this model and allow each user or their agent to change, one at a time, the suggested time of the previous user. Concurrence could be a long time coming.
Another approach might be to find a solution by having users concurrently select and approve several times simultaneously. If distributed agents were performing these tasks, they might act fairly quickly but individual users could become confused and have difficulty. Further, this approach seems unduly complex and closure uncertain.
Improvements might have a central node or server do the processing where the applicable data is sent to that processor. [Jor95] Communications traffic might be reduced if the processing node had the advantage of each user's preferences rather than having to ask each node to do their own CBR inquiries. In a peer-to-peer model, that server might just be the processor of the meeting instigator or any node on the network with the most free cycles and the ability to do the computation quickest. Another improvement suggests that instead of moving data to this processor and each user being subject to the same rules of logic, a clone of the users' agents could be sent and their rules and wishes followed.
The actual search algorithm might use an AA matrix where each user is listed vertically, time running horizontally and where the available time slots contain a value expressing one's preference to meet ranging from not desired (dark gray) to preferred (white). The algorithm would then look for times having the most white when looking down through the rows. To speed the search, it would use a "large pixel" search strategy where a coarse look is achieved using a composite value for all the cells in a column (or a range of columns) and refining the search to the whitest areas. An approach such as this would satisfy people's preferences with the added property of possibly finding an optimal blend.
A major difficulty is how to extract a time line of preference values from a case base or other knowledge representation. CBR obtains recommendations by building a probe and locating the nearest neighbor. An inversion of that process is required to extract the degree of preference for all times in the range of interest. And this degree of preference continuously changes over even small increments of time.
Dynamic Case Base Indices
The current implementation of Concur operates in a low-power real-time environment necessitating certain design concessions. Ideally, it would be nice if Concur were to dynamically establish indices based on the three highest relative importance indicators set by the user in the Preferences view. Unfortunately, there is a bug in the current version of the Newton OS making this difficult and given a large case base, this could take some time and power. Fortunately, the user would be making infrequent changes to the relative importance sliders suggesting that when the bug restriction is removed, Concur could change indices dynamically.
Would do it differently next time...
The next version of Concur should support a user specified time by when the meeting must be held. This would set an outer bound whereas the current implementation assumes up to one month (30 days) past the "try for" time.
A minor observation is that the Preferences view has too much content and that it would be appropriate to split the view into two separate views. One of the new views would focus on the times one cannot attend meetings and the other would center itself around CBR issues such as the relative importance sliders and the tolerance level. Also, the "single" connect button is really two buttons; a connect button and a disconnect button superimposed one on top of the other. The coding would be more complex, but a few minor cosmetic side effects could be eliminated that are caused by the hide and show commands.
NTK, Newton OS and NewtonScript
Many parts of the Newton ToolKit, the Newton OS and NewtonScript are well designed for the environment in which they find themselves. For example, the OS was carefully designed to operate in an environment without secondary stores.
Frames are a nice touch providing the NewtonScript developer a lot of flexibility when designing data structures. The ability to transmit frames as complete data structures to another Newton is an example of how the Newton designers tried to provide both ease of use and ease of programming. Simularily, dynamically sized arrays and the simple foreach iterator make coding tabular data easy. On the other hand, NewtonScript should have the ability to define static, in addition to dynamic, data types and the lack of a case statement forces the use of awkward "if then else if" constructs.
As a new product the Newton Toolkit development environment seems only partially complete. The browser/editor does not support several features common to its competition. For example, it doesn't support double click and drag to select multiple words and lines. The compiler doesn't support incremental compiles or a separate linker making the development of larger program cumbersome. The windoid palette of widgets for constructing views needs to either draw faster or have an option to not show itself except when wanted.
Conclusions Concur successfully applies case-based reasoning to learn its user's meeting scheduling preferences. As such, Concur met its goals as an experimental implementation of machine learning in a small memory, low-power, real-time environment with a minimum of verbal negotiation between the parties. Concur is unlikely, however, to see widespread use on Newton platforms because its use of infrared communications limits its use to meetings of only two persons. While the remaining algorithms support multiple persons, the round-robin model is likely to have poor performance if extended to multiple persons. A more powerful conflict resolution model is needed.
Concur also provided the author with an opportunity to learn and experiment with Newton Technology; a new programming language, development environment, operating system and computing platform. On balance, the Newton design choices seem well suited for their intended uses and future versions of the Newton Toolkit and NewtonScript are expected to address many of their shortcomings.
References
[App87a] Apple Computer, 1987, Knowledge Navigator, Apple Computer, Cupertino, CA, VT87021. [A 5 minute 45 second concept video illustrating what computing might like be for a university professor in the year 2015.]
[App87b] Apple Computer, 1987, Project 2000, Apple Computer, Cupertino, CA, VT87017. [An 11 minute concept video including an adult learning to read segment.]
[App94a] Apple Computer, 1994, Newton Programmer's Guide, Apple Computer, Cupertino, CA.
[App94b] Apple Computer, 1994, The NewtonScript Programming Language, Apple Computer, Cupertino, CA.
[App94c] Apple Computer, 1994, Newton Toolkit User's Guide, Apple Computer, Cupertino, CA.
[Bra88] S. Bradtke & W. Lehnert, 1988, "Some Experiments with Case-Based Search", Proceedings of the DARPA Case-Based Reasoning Workshop, Clearwater Beach, FL, Morgan Kaufmann, San Mateo, p80-93. [also in the Proceedings of AAAI-88]
[Cul94] M. Culbert, 1994, "Low Power Hardware for a High Performance PDA", Proceedings of the 39th IEEE Computer Society International Conference, San Francisco.
[Eng94] M. Engber, 1994, Lost In Space, PIE Developers, San Francisco, v2.3, May 94, p39-43.
[Jor95] R. Jordan, 1995, personal communication.
[Kol93] J. Kolodner, 1993, Case-Based Reasoning, Morgan Kaufmann, San Mateo, ISBN 155860237-2, p193-392.
[Kop88] L. Kopeikina, R. Brandau & A. Lemmon, 1988, "Case Based Reasoning for Continuous Control", Proceedings of the DARPA Case-Based Reasoning Workshop, Clearwater Beach, FL, Morgan Kaufmann, San Mateo, p250-259.
[Mae93] P. Maes & R. Kozierok, 1993, "Learning Interface Agents", Proceedings of the 11th National Conference on Artificial Intelligence, AAAI Press, Menlo Park, ISBN 0262-51071-5, p459-465.
[McK94] J. McKeehan, & N. Rhodes, 1994, Programming for the Newton, Academic Press Professional, Boston, ISBN 0-12-484800-1.
[Oak94] H. Oakley, 1994, Getting Objective, PIE Developers, San Francisco, v2.5, Sep 94, p1618.
[Ris88] E. Rissland, J. Kolodner & D. Waltz, 1988, "Case-Based Reasoning", Proceedings of the DARPA Case-Based Reasoning Workshop, Clearwater Beach, FL, Morgan Kaufmann, San Mateo, p1-13.
[Sei94] C. Seifert, K. Hammond, H. Johnson, T. Converse, T. McDougal, S. Vanderstoep & M. Pazzani (ed.), 1994, "Case-Based Learning: Predictive Features in Indexing", Machine Learning, Kluwer Academic Publishers, Boston, ISSN 0885-6125, p37-56.
[Smi94] W. Smith, 1994, "The Newton Application Architecture", Proceedings of the 39th IEEE Computer Society International Conference, San Francisco, p156-161.
[Sta86] C. Stanfill & D. Waltz, 1986, "Toward Memory-Based Reasoning", Communications of the ACM, 29(12), p1213-1228.
[Syc89] K. Sycara & D. Navinchandra, 1989, "Index Transformation and Generation for Case Retrieval", Proceedings of the DARPA Case-Based Reasoning Workshop, Pensacola Beach, FL, Morgan Kaufmann, San Mateo, p324-328.
[Ull88] J. Ullman, 1988, Principles of Database and Knowledge-Base Systems, Computer Science Press, Rockville, ISBN 0-7167-8158-1, p361-368.
[Wel94] R. Welland, G. Seitz, L. Wang, L. Dyer, T. Harrington & D. Culbert, 1994, "The Newton Operating System", Proceedings of the 39th IEEE Computer Society International Conference, San Francisco, p148-155.
[Wel95] P. Wells & J. Schlimmer, 1995, "Planning Arguments in a Selection Task", Washington State University, unpublished paper.
Original paper: Copyright © 1995 by Larry Bugbee
This HTML rendering: Copyright © 1997 by Larry Bugbee
All rights reserved.