People files are a great benefit of BeOS. The People editor is short and to the point. People files provide a way for many applications to interact. Nearly all of us have to interact with people on a regular basis. Having one place to store all the information about them is very useful.
However, People files are rather impoverished. A testament to this is applications such as DeeperPeople. People just want more from their People files. :-)
I believe that people files could be made even more useful by expanding the set of features. A good way to do this would be to determine what features are in use and then to write the standard from what's already common. Some of these features could be determined from the DeeperPeople app, for example.
Another possible opportunity for GE is to add a People widget. It would provide a set of access functions to extract various fields and also support dropping people files on to. It could possibly be used in an email application. Then again maybe it's not such a good idea. I can't remember what I was thinking when I wrote this. :-P
As I see it, the main problem with People files is no different from any other database. What if you want to add or change the data fields? Any user can add more attributes, but that's not very helpful without a program that can use the attributes. However, if you start changing the attributes, you lose the standardization of People files.
One simple solution is to maintain the current People files as a basic set of attributes, and then to include "advanced" People files with more attributes. As long as the advanced attributes can be agreed upon, standardization can be maintained.
Another solution is more complicated. Create a "compatibility layer" (some kind of program or kit?) that handles the People file attributes, and let People-type programs use the compatibility layer, instead of directly dealing with the attributes. The layer should allow for the creation and modification of the actual attributes. The layer would inform the program(s) what attributes are currently in existence so that the program knows what to display to the user.
Perhaps I'm making this too hard. Perhaps we should just encourage the programmers to write People-type programs that handle the reading, creation and modification of attributes. As long as the fields are, in fact, attributes, then the data is still transparent to the user, although a little more difficult for the programmer to deal with.
