Design Requirements for Addresses

Contents

• # Summary
• # Terminology
• # Design Goals
• # See Also
• # Comments

---

Summary

This page was reviewed by the design group on 20 May 2004, and reflects the current thinking of the design group at that time. This document primarily deals with the design goals that might impact how addresses work within a pure Chandler-to-Chandler context; this document does not try to cover the issues that come up when users need to see addresses in order to use the addresses to interoperate with non-Chandler software (like web browsers). We need to come up with a separate document that lists practical contexts in which addresses are used for interoperation and exposed to users. For additional thinking that has not been formally reviewed, see the See Also section.

---

Terminology

Warning: Can't find topic Glossary.Name

Warning: Can't find topic Glossary.Link

• Element - A view, an item collection, a content item (or an item cloud). Anything that can be shared.

---

Design Goals

Unifying goal: Chandler users should feel like they a working within the Chandler paradigm of items and collections, not a file-system of paradigm of hierarchically organized files. (Items are richly interconnected; membership in collections is fluid; Items exist in multiple collections at once; deleting a collection does not delete its content items; etc.)

1. Invisible addresses
   • At the UI level, in the typical end user's mental model, we should have "invisible addresses" rather than two-layer addresses. A user should be able to simply create and share items, without having to think about addresses. However, there's an important exception. In order to facilitate interoperation with other apps, Chandler users may need to be aware of some addresses, and those addresses should be explicitly designed for interoperation.
2. Users share items, not addresses
   • The content item at an address is not swappable
   • Example: I can give you read access to my "Chao" Contact.
   • Example: I cannot give you read access to a "picture of the day" address, and then post different content items to that address every day.
   • Example: I can't give out an address that points to one Contact item, and then tomorrow post a different Contact item at that address
   • Example: I can choose to stop sharing an item, but I can't "choose to cause an exportable address to become invalid"
   • Example: It is not the case that "users may create a new exportable address"
3. Users work with Chandler collections, not namespaces
   • Example: I search for my "Chao" Contact in my "OSAF" collection, not in an "OSAF" namespace
   • Example: It is not possible that "The user could bind the email into another namespace or bind non-email items into the /Mail namespace. The user could even remove a binding to the email from the /Mail namespace."
4. Users work with display names, not symbols or repository level itemNames
   • Example: In my address book I have a Contact called "Chao Lam". Nowhere in the UI do I see a string like "ChaoLam" or "Chao_Lam" or "Chao%20%Lam".
   • Users do not have to assign itemNames in addition to display names. Users do not have to know about itemNames.
   • Ideally, in any interfaces for scripting and queries, it would be very desirable for users to work only with display names, not itemNames
5. The UI always shows an item's current display name
   • An item's display name may show up in lots of places in the UI (summary view, detail view, sidebar, bookmark bar, sharing manager, etc.). A user might be able to rename the item using UI affordances in any of those different views. Whenever a user renames an item in one part of the UI, all the other parts of the UI should immediately show the new name. Ideally, that requirement should include any UI that shows query or scripting strings.
6. Users work with links, not addresses
   • Example: In the Chandler UI, a link to a Chandler item looks like this: Robin Williams
   • Example: When a Chandler user "sends" an item out by email, ideally the body of the email message should contain a link, not an address. (Having that link launch Chandler may be a hard problem, but having an address there instead doesn't make it any easier. For more on the subject, see LisaDusseault20040423.)
7. Users never assign addresses
   • Addresses are machine-generated, not manually assigned by users
8. All links are perma-links
   • Links should not expire, or become invalid because of changes to content. The Chandler link mechanisms should be designed to prevent any sort of "not found" errors like the 404 errors on the web. (An exception to this comes up when an item is deleted, in which case we might actually want to return a 404 error rather than a message stating that the item was deleted.)
9. Changing the name of an item does not break any links
   • Example: If I share my "Chao" Contact with you (or publish it some other way), and then change the name of that contact to "Chao Lam", that change does not result in the original link becoming invalid.
   • Example: If I share my "Knitting Club" collection with you (or publish it some other way), and then change the name of that contact to "Knitting Group", that change does not result in the original link becoming invalid.
10. Moving an item does not change its address
    • Example: Let's say "Chao" is a Contact in my "Knitting Group", and I share my "Chao" Contact with you. If I then remove "Chao" from the "Knitting Group", that should not break the sharing of "Chao". There shouldn't be a 404 error trying to get to Chao just because Chao is no longer in the Knitting Group.
11. Deleting a collection does not change the address of member items
    • Example: Let's say "Chao" is a Contact in my "Knitting Group", and I share my "Chao" Contact with you. If I then delete the "Knitting Group" collection, that should not break the sharing of "Chao". There shouldn't be a 404 error trying to get to Chao just because there no longer is a Knitting Group.
12. Users never see addresses, except perhaps for supporting interoperation
    • In the ideal Chandler UI, users only see links, never addresses. (An address would be something like chandler://chris@mymachine.com/mail/unread/Msg232 ). However, users may need to see addresses in order to support interoperation with traditional apps, like web browsers. But, with the exception of facilitating that, users should never see addresses.
    • In the detail view for an item, there is not an "address" field.
    • In the nav bar, there is not a dedicated address field that exists just for the purpose of showing addresses. Whatever nav bar we have should be geared towards helping a user navigate to things in their Chandler world (parcels, views, collections, item), using user-facing Chandler constructs (like display names, collection membership, attribute values) rather than file-system constructs like path names.
13. Names can have spaces and kanji characters
    • Users can create names with spaces (like "My Friends"), and names with special characters (like / and ").
    • Users can create names in any language they want to (Chinese, Japanese, etc.)
14. Names do not need to be unique
    • Users can intentionally give the same names to two items in the same collection.
    • Example: "Lunch with Tug" on Tuesday, and "Lunch with Tug" on Thursday.
    • Example: In general, a user can have two collections named "foo". (However, there may be special cases where the application imposes uniqueness restrictions in order to interoperate with other software. For example, if we have some collections that map to IMAP folders, we might enforce IMAP naming restrictions.)
    • Example: If I share an item with someone else, the name of the item may change as a result of their editing, which is not under my control. I can't ensure that the item will still have a unique name in the context of some collection of mine.
15. Users can leave items unnamed.
    • Example: An email message with no subject line, or a photo in a folder of photos.
16. Names change if and only if a user wants them to
    • A user can change an item's name whenever they want to
    • A user should never get an alert box or a dialog box as a result of changing a name.
    • A user never has to rename an item in order to put it in a collection.
    • An item is never automatically renamed by Chandler.
17. The identity of an item should not be tied to a particular parcel.
    • A parcel may create a content item, but in the user's mental model the parcel does not own the content item. A user should be able to delete a parcel, or swap out one parcel for another, and still be able to view the old content item. That content item should still have the same identity, and be available for sharing, and visible in a generic viewer.
18. No design requirement for canonical organization (canonical namespace)
    • Users will organize their data based on OOTB collections and collections they create, and they won't see items in terms of how addresses are structured via path segments.
19. A user can navigate through another user's content
    • There's a simple browsing use case in which I make a specific collection available you, and you can somehow do remote browsing and go directly to that collection and see it in my repository.
    • Additionally, there's another use case, in which you do remote browsing with your original destination not being a specific collection in my repository, but instead with the original destination being my repository as a whole. In that case, there needs to be some UI that somehow lets you start at the "root" of my repository, and then get from there to all the different individual things I've made available to you (views, items, and collections). There's one variant of this use case where you're using a Chandler client to browse my repository, and there's another variant where you're using a web browser to broswe HTML pages that correspond to content in my repository. We care about both of those variants.
20. Users browse based on collections, not path segment hierarchies
    • Example: Say you publish your repository and I browse around in it. I might be browsing using a Chandler client, or I might be using a web browser to browse through statically published HTML pages, or I might be browsing via some other means. In any case, the way I see the items organized should reflect the way you organized your content, or should reflect the organization that you chose to expose to me -- the way that you put your items in collections, and the way that you richly interconnected them. My browsing experience should not be influenced by the structure of the addresses used to fetch the items and collections.
    • If you buy in to that example above, that necessarily dictates that users are not browsing a hierarchy of items, but rather a richly interconnected web of items (which might contain multiple organizational hierarchies, if it's been set up that way).

---

See also

Warning: Can't find topic Trash.PagesAboutAddressing

---

Contributors

• BrianDouglasSkinner - 20 May 2004

---

Comments Welcome

---