The object user experience

I get alot of questions of how will the object storage affect the user experience. If anything is an object will users have to sort the properties of a file, will they even see the properties of a file as an object? Will documents be browseable? Will appointments have folders that hold the address fields? and so on... Hopefully this post will explain and answer these questions: First of all... the user and developer experience are different. Users use the UI while developers use the API. The user experience shows folders and files much like any file system does. It just adds many more types of 'files' a user will see like appointment and contact files but they still feel like a file that holds data. Only that it holds structure and data, not just a stream of bytes. Think of a file like a zip file... it holds folders and files inside it only each file can also hold other folders and files in it. Users see a contact file... they can delete it, sort it, filter it and do anything you would expect to do with a file however the developer using the API can dig deep into the contact file to view its properties, members, addresses, relationships with appointments and so on. So only objects which are self-holding and that users use like documents, email, PIM objects, devices, drives, folders and normal files are viewable by the user. All the rest are handled by developers and are visible either through specific UI's like the Properties view or used internally for the developers use. So for a user, there are folders which organize objects. For the developer anything is an object which can hold data (or share it) and hold other objects. So to the user it feels like a normal file system while to a developer its a data storage. Even applications appear to the user as a single object while to the developer - settings are stored inside of it including code and resources the application needs. If a user copies an object like a document... it copies anything in the document including embedded documents. So the user who is used to a normal file system continues to get the same feeling. Relationships with other objects are not copied, but still are referenced. If you move a document to another system, all its files are valid but its external references are invalid and removed unless you make them re-searchable by providing keywords or some other way to find thier new relationships on the new system. So you could make a file relate to a contact by its name so that when you move the file to another system, it relinks the contact by finding it by its name. This means moving objects between systems still remains intact. When you export an object, it includes all the contents of the object in a single file so you can move it between systems even over systems that dont understand the object format. But what about Search? Well... because it is an object storage after all... finding objects of the same type are instant since they are referenced by thier class (so the class can update its instances dynamically). Filtering, Sorting are all user interface issues, not object storage issues. And if you are searching lets say by Name, it returns not the Name object itself but a parent 'user-viewable' object in the results. So searching for a contact name, does not return the name property but the contact file object. Just like you can share object data between objects, so can you share objects between objects. This allows one object to appear in multiple places where only if the object exists in no locations, is the object removed from storage. But from the developers point of view, each object has only a single owner so while objects can appear in multiple locations, its still only owned by a single object. What does this ownership do? Its a spine for the object which defines its true location. When a user copies an object, it duplicates the contents of that object to the target location. If a user shares an object, only its link is copied, not the contents of that object. If the user deletes an object, it only deletes the link. If an object has no owners then it is removed from the system along with all its children (unless they are shared). This removes the need for shortcuts/shadows/aliases/soft-links but still gives the functionality of allowing to access an object from multiple locations. Note that you can always find all the locations an object is shared by to remove it from all those locations. Hopefully this should answer some of your questions about the object storage and its user experience.