Product Specification

Introduction

This feature list describes a hypothetical system designed to facilitate web-based collaboration. This OpenRecord design is inspired by wiki software and sites like Wikipedia, as well as Content Management Systems (CMSs) like Zope/Plone and eZ publish. The OpenRecord design also draws on ideas from outliners like Lotus Agenda and OmniOutliner, spreadsheets like Lotus Improv, and newer work like Chandler and RDF.

OpenRecord is similar to a wiki, but with some database features added in. Wiki systems usually let you organize your content as pages of text, or pages of rich text. In OpenRecord your content is organized as a database of items, or records. Each page on an OpenRecord site can query the database to get some set of items, and those items can be displayed in an editable table, or in an outline format, or in other formats. In time, OpenRecord could grow to incorporate simple spreadsheet features, as well as interactive charting and graphing features, and OLAP and pivot table features.

Goals

1. Enable a workgroup to work in an unusually open and transparent style
2. Facilitate sharing and collaboration
3. Facilitate tracking of goals, tasks, and work accomplished
4. Facilitate comparison and prioritization
5. Facilitate categorization and structuring of content
6. Make it easy to create new content without first planning how the content will be organized
7. Make it easy to gradually add structure and organization to the content.
8. Make it easy to re-organize content in different ways, and have multiple concurrent organization schemes.
9. Discourage the growth of a jumbled jungle of rambling discussion
10. Offer features geared more toward collecting facts and figures, rather than op-ed content
11. Discourage long pure-text discussion threads (like email or IRC)
12. Facilitate the creation of valuable reference material

Examples of use cases

1. People can propose new ideas for the workgroup to consider. It should be easy to do make a new proposal, perhaps by filling in some simple form.
2. People can add little scraps of new information about a proposal that was previously suggested. For example, if one person proposes that the group lease equipment from a certain vendor, but doesn't give the URL for the vendor's website, another person can come along later and fill in the missing information.
3. A site might provide a small database of interesting products, or companies, or non-profit organizations. Each entry could include lots of little details we might want to keep track of, like links to the external websites, or the tax id number of the organization.
4. People can add to the list of things to keep track of about an organization. For example, somebody might create a new field for keeping track of when each organization was founded, and then other people can fill in the value for that field for each new organization, and people can go back and fill in that information for previously listed organizations.
5. People can fill out surveys, and the site can gather the and display the results.
6. People can create new surveys covering different topics, like what countries the organization operates in, or what their affirmative action and employment practices are, or what their fundraising practices and organizational overhead rates are.
7. People can create new "scorecards", which give scores to different organizations based on the answers to questions on different surveys. (Or perhaps some other sort of tools geared toward quantitative evaluation?)
8. People can look at lists of organizations and see how they scored on scorecards.
9. People can contribute to cost-benefit estimates based on knowledge about the work the organizations do.
10. People can see accounting records about how the group is using its money.
11. People can see a record of all the email sent and received by the project.
12. People can see simple charts and graphs, generated from whatever quantitative info we have on record, like the annual budgets of different organizations, or how much money the project spent this year compared to the last 2 years.
13. People can disagree with each other, with having to argue about it. Two people can have different answers to the same question, and the system can record both answers, and show both answers to anybody who asks.
14. People can propose new ideas. People might propose new ways of running the site, or new sections the site should include, or a new ways for selecting what work to do.
15. People can comment on proposals, and list pros and cons, and add suggested amendments or refinements.
16. People can vote for or against proposals, or somehow rate or rank the proposals.

Features

• Priority 1 features
  1. No invisible content
     • All the content on the site should be visible to the public.
     • Anybody can browse the site without logging in, and they can see all the content.
     • All of the content should be viewable to anyone who browses to the site. All content available to account holders should also be available to the general public.
  2. No anonymous content
     • Nobody should be able to anonymously add content to the site.
     • In order to add content, you first have to create an account for yourself.
     • Exception: it might be fine to let anonymous visitors make very minor contributions. For example, we might let people fix small typos, or click on checkboxes to place votes or categorize content. But we should draw the line at entering new content.
     • Each piece of content is attributable to some particular user.
  3. No decaying content
     • All content should be permanent.
     • It should be impossible to delete content, or to make content invisible. All content should be reachable through the navigation menus, without having to know a secret URL.
     • It should be possible to "retract" content, if it is obsolete or incorrect or offensive. You should be able to retract content by marking it as retracted. The retracted content is not deleted, and is still publicly available, but it is clearly labeled as retracted.
  4. Free accounts for everyone
     • Anyone should be able to create an new account for themselves.
     • Creating a new login account should take a minute or less.
     • You should be required to provide your real name and a valid email address. We should not allow for anonymous or pseudononymous accounts.
     • We should require that each account name be the user's real name. My account name should be "Brian Douglas Skinner", not something more fun or more cryptic like "brian" or "bskinner" or "papabear".
     • In order to get your account, you must agree not to post content that is protected by copyright or intellectual property law. You will need to agree that by posting content you are dedicating it to the public domain under the terms of the Creative Commons Public Domain Dedication. As a result, all content is publicly available for reuse and repurposing — content is never left in some sort of legal limbo where we don't know who created it or how to reach them.
     • Once you have a login account, you can sign up for a "transparent email account" with an address firstname.lastname@openagenda.org.
     • Once you have a login account, you can create any kind of content, and do anything that anyone else can.
  5. Change logs
     • Change logs should be readily available.
     • For example, say some piece of content was created a year ago, and since then has been changed a dozen times. By default I should see the most recent version of the content, but the version number should be visible with it, and there should be a link (or links) that allow me to see the original version or any of the intermediate versions. I should also be able to see when each change was made, and who made the change.
  6. Standard formats
     • All the web pages should be delivered in a small number of standard formats.
     • XHTML and CSS should be the norm for every page.
     • Some pages might also use JavaScript.
     • Some pages might also include .gif or .png or .jpeg images.
     • Everything is stored in Unicode.
     • No pages should use Flash or ActiveX.
     • No content should be in .doc or .xls attachments.
  7. Navigation bar
     • There should be a nav bar available on every page.
     • From the nav bar, it should be possible to get to every page.
     • It should be possible to expand or collapse parts of the nav bar, to focus on just what you care about and get rid of visual clutter.
  8. Items and attributes
     • When users create content, they're creating items. Every piece of new content is a new item. The back-end data store simply stores a big jumble of undifferentiated items.
     • Every item can have a "Name", a "Summary", and a "Body".
     • Users can make up new attributes to add to an item. — For example, I can add a "Phone number" attribute to the item representing Amnesty International.
     • Any attribute can have more than one value. — For example, I can put three different phone numbers into the "phone number" attribute for Amnesty International. Or I can put one phone number in the attribute, and you can put a different phone number there without erasing what I put.
     • An attribute can have a suggested data type. — For example, the "Name" attribute would have a suggested data type of "String", while a "Annual budget" attribute would have a suggested data type of "Money". Any attribute can be assigned any type of value, regardless of what the suggested data type is. "Annual budget" may have a suggested data type of "Money", but you're still free to put in a string value like "Too little!".
     • Attributes can have a literal values (like numbers, or dates, or text strings), and they can also have values that are references to items. For example, the item representing the book "The Hobbit" might have an attribute called "Author", which could contain a simple text string like "J.R.R. Tolkien", or which could instead contain a reference to an item representing Tolkien. The Tolkien item could have its own attributes, like date of birth. All references between items are automatically bi-directional, so when you take the item "The Hobbit" and set its "Author" attribute to point to the "Tolkien" item, the system automatically sets an inverse attribute on the "Tolkien" item to point back to "The Hobbit". You can think of these automatic inverse attributes as "of/by/for" attributes — "The Hobbit" has an "Author" set to "Tolkien", and inversely, "Tolkien" is the "Author of/by/for" "The Hobbit". An employee item has a "Department" attribute, and the related department item is the "Department of/by/for" that employee.
     • It should be a two-click operation to take any attribute value that's a string literal and turn it into a new item. If the item "The Hobbit" has an "Author" attribute containing the string "J.R.R. Tolkien", you should be able to click on "J.R.R. Tolkien" and do some command called "make this into an item". The command should create a new item which has a "Name" attribute set to "J.R.R. Tolkien", and the "Author" attribute of "The Hobbit" should now point to the new item.
     • Each attribute is itself an item, with attributes like "Name", "Summary", and "Suggested data type". Users can add other attributes to an attribute item, and put the attribute item in categories, and so on.
     • Every item can have a "Start Date" and "End Date".
     • Every attribute value can have a "Start Date", "End Date", and "Source".
  9. Items and kinds
     • Items do not inherently have a class or kind.
     • Items can be assigned to kinds. — For example, I can make my Amnesty International item be of the kind "Charity"
     • An item can be assigned to more than one kind.
     • Users can create new kinds.
     • Each kind can have a list of suggested attributes. For example, the kind "Book" might have suggested attributes like "Title" and "Author". When a user creates a new item of that kind, the entry form for the item will include fields for all the suggested attributes associated with the kind.
     • Users can make up new attributes and add them to the list of suggested attributes for a kind.
     • Any item can serve as a kind, and any item can be assigned to be an instance of some kind, or an instance of some any other item. There is no distinction between Classes and Objects, or in our vocabulary, between Kinds and Items. This is a "Prototype-based" system rather than a "Class-based" system. For example, a there could be items like "Dog" and "Cat", which are of kind "Animal". So, you could say that "Dog" and "Cat" are instances of "Animal". "Animal" could have suggested attributes like "hasTail" and "isCarnivore", and "Dog" and "Cat" would have values for those attributes. But then "Fido" and "Snoopy" could be of kind "Dog", so that you could say that "Fido" and "Snoopy" are instances of "Dog", while "Dog" in turn is an instance "Animal". If "Snoopy" is an instance of "Dog", it is therefore an instance of "Animal" as well. "Snoopy" might be also be both a "Dog" and a "Cartoon Character", because we allow an item to be assigned to more than one kind.
  10. Items and categories
      • Users can create new categories, and put items in categories. — For example, I can create categories called "Fiction" and "Non-fiction", and I can put some books in fiction and others in non-fiction. [PENDING: Maybe consider using the term "tag" instead of "category", on the theory that it's shorter and less intimidating and more likely to give people the sense that an item can have more than one tag? The downside is that "tag" maybe suggests something that's just a word, not something that might itself have a description and other attributes.]
      • When a user looks at a category, they can see a list of all the items in that category.
      • When a user looks at an item, they can see all the categories that item is assigned to.
      • Each category is itself an item, with standard attributes like "Name" and "Summary". Users can add other attributes to the item, and assign the item to a kind. — For example, I might create an item called "Kenya", which is of kind "Country". "Country" has suggested attributes like "Population" and "GDP". I can create an item called "Africa", which is of kind "Region". I can assign "Kenya" to the "Africa" category.
      • Categories can be structured into a hierarchy. [PENDING: how?]
      • Different users can create their own categorization schemes. I might categorize "Atlas Shrugged" as "Good", while you categorize it as "Polemic". That's fine. We can look at each other's categorizations if we want to, but we're not forced to.
      • [PENDING: Is a kind maybe just a sort category that categorizes attributes? For example, the "Author" attribute belongs to the category "Book". Book is a kind simply because it has some attributes that have it assigned as a category?]
  11. Items and pages
      • There should be a clear and rigidly enforced separation between content and presentation. Content consists of items, attributes, categories, and kinds. Presentation consists of pages, layouts, and sections. Both the content and the presentation are kept in some form of structured data store, like an XML file tree, or an RDF database, or a relational database, or a Chandler repository.
  12. Editing items
      • When a user edits an existing item, or creates a new item, all the editing is done in some kind of structured form. Each attribute of the item is edited in a separate field. The editing UI is more like a spreadsheet than word processor — more like an order form than a wiki page.
      • All editing is done "in line", on the same page the content is being viewed. Unlike a wiki, you don't have to press an "edit" button, and you don't have to go to a separate page to start editing. To edit, you just click on some text and start typing. The tool should have a WYSIWYG feel, like a word processor.
      • We do not offer any kind of wiki-style mark-up, even for items that have large text bodies. Structure is never encoded in text. If you want something to appear as a list of bullet points, those bullet point line-items are really separate items, not a wiki-style applied to plain text. The UI makes it easy to create a list of items all at once.
  13. Editing layouts
      • In addition to editing content items themselves, users can also edit the layout of the pages that contain the items. For example, let's say you're looking at a page that has a big table on it, where each row in the table has an entry for a Book — there's one row for "The Hobbit", and another for "The Wisdom of Crowds", and so on. Each column of the table is for some attribute, like "Title" or "Author". To edit a content item, you could click on "The Hobbit", and type in some different text. But you could also edit the layout of the page itself, rather than an item on the page. For example, you might want to add a new column to the table, or change the width of an existing column, or change the table to be sorted by "Author" instead of "Title". To play with an example of a JavaScript widget that allows this sort of editing, check out the ActiveWidgets Grid widget.
      • Sometimes the user will want to save the changes that they make to the page layout, and other times they won't. We need to support both types of use, but it may be tricky to know when to save and when not to. We could automatically save every layout change, but then when I'm just casually poking around a page I might inadvertently mess up the layout that you carefully arranged. Alternatively, we could generally refrain from saving layout changes, and only save them when the user explicitly hits a "save layout" button. In either case, we'll want to have some way to let the user do a "save as...", or somehow "copy" or "clone" the entire page and create a new page showing the same content. Both the new page and the old page may continue to show the same content items for years to come, but one might evolve to have a summary-view style layout, where the other might be a detail-view that shows all the attributes of every content item.
      • It should be easy for a user to grab the URL of the page that they're currently looking at, where that URL represents the page exactly as they're current looking at it, with all of the layout options set just as they are now. If I'm looking at a page that I've just sorted and arranged to show some key point, I should be able to easily send you the URL so that you can see what I see. For a great example of this, check out Kevin Lynch's demonstration of Stateful Linking to Rich Internet Applications.
  14. Pages and sections
      • Each page is defined by a page layout. A page layout it just a list of sections that appear on the page. The first section appears at the top of the page, the next section below it, and so on. There's nothing fancy with multiple columns or text flowing around images or anything like that.
      • What a section looks like depends on two things: what items appear in the section, and what type of section it is. Initially, we'll probably want to have just a few types of section: probably table sections, item detail sections, and outline sections.
      • A table section would just show a simple table of items and their attributes. Each table section would have a list telling it what attributes should appear as column headers, and in what order. The table section would also have a list telling it what columns to sort on, and the table section would know how wide each column should be, and so on.
      • An outline section would show a bullet-point list of items, arranged in a hierarchy, like the lists on this page.
      • An item detail section would show the attributes of a single item, with each item on a separate line. An item detail section might show all of the attributes of the item, or might show only a subset of the attributes, depending on how the section is configured.
      • Each section has some sort of "content list" that determines what items appear in the section. The content list for a detail section would simply list a single specific item. The content list for a table section might specify "all the Book items in the category Fiction".
      • It should be possible to set up a content list so that it in effect pre-screens the content to show just the items that you yourself have created. For example, you might want to see the list of all the charities that you have nominated, rather than all the charities that anyone has nominated.
      • Transclusion is a first class feature. A page doesn't "own" the items that appear on it. Items exist in their own right, and can appear on lots of different pages at once. An item still exists even if it doesn't currently appear on any pages. This is fundamentally different from how wikis work, or how word processors work, where the page does own all of the content on the page.
  15. Raw item pages
      • Each page has its own URL, and each page may display one or more items, depending on what sections the page layout includes. Independent of pages their URLs, each item has it's own URL, pointing to a raw item page. A raw item page shows item detail information for all of the attributes of the item. The attributes of the item can be edited, but unlike with normal pages, on the raw item pages the layout of the page is not editable.
  16. Access permissions
      • There is no access permission model. All items are editable by anyone. Nobody ever "owns" an item or a page.
  17. Clean UI
      • There should be no modal dialog boxes.
      • There should be no menus or dialog boxes to "Save" or "Open" files. All content should be automatically saved.
      • You should be able to do common tasks in just a few clicks. (As we're putting together the software we should keep records about how many clicks it takes to do things, and we should work to keep breaking past records. In version 0.1 you could create an item in 2 clicks, but in version 0.2 you can create an item in 1 click!)
      • The visual design is simple and clean — a start page like Google, not Yahoo — colors like Plone, not Userland
      • We should have undo and redo features. (If we wanted, it would be easy to implement a rollback feature that would allow the entire site to be rolled back to some earlier point in time. Or a "window into the past" feature, that allows a user to look at the site exactly as it appeared at some earlier date.)
  18. Built-in data structures
      • The software infrastructure should have some kinds of items available as built-in primitives, including:
      • User Account
      • Person — not necessarily a User
      • Mail message
      • Link (name, URL, internal/external)
      • Page
      • View
      • Picture
      • Category/Collection
      • Attribute/Value
      • Comment
      • Date — including Timestamp (with date and time), Date (with no time), and Year (with no month or day)
  19. User-created data structures
      • It should be possible for end-users to create new kinds of items, and create new items of those kinds, like:
      • Charity
      • Country
      • Proposal
      • Donation — $1,000 to PATH on May 5, 2006
      • Goal/Task
      • Weekly status report
      • FAQ entry
      • Glossary entry
      • Op-ed
      • Properties and units of measure — DALYs, dollars, etc.
      • Variable being measured — total budget, number of members, etc.
      • Vote/Rating
  20. Content export and tool migration
      • We should not be "locked in" to a particular software toolset.
      • It should be possible to export the content into simple, standard formats, like XML or comma-delimited text files.
      • Ideally, the content should be automatically exported all the time, so that there's always a current version of the export file on hand.
      • Five years from now, it should be feasible to port all of the content into some new content management system.
  21. Names and identity
      • Underneath the covers, each item has a unique identifier, but users never see those identifiers.
      • Items can have names, but the names do not serve as identifiers.
      • An item does not have to have a name.
      • Names do not have to be unique. A user could create two separate items, each named "The Hobbit".
      • A single item may have more than one name. Different users can assign different values to the "Name" attribute, or a single user could assign more than one value. A charity might have the name "Doctors Without Borders" and also the name "Medecins Sans Frontieres".
      • Whenever an item has any kind of relationship or interaction with another item, the items keep track of each other based on their identifiers, not their names. This is true for everything in the system: keeping track of what kind an item is assigned to, what categories an item is in, what attributes an item has, what attributes a derivation rule refers to, etc.
  22. URLs
      • Each piece of content has a unique URL.
      • All URLs are permanent. No URLs ever go stale or result in 404 errors. A URL always addresses the same piece of content for its entire life.
      • The URLs should not disclose any information about what software products are serving the content. The URLs should not include strings like ".php" or ".asp"
      • The URLs should be as short as possible. Ideally they should all be less than 60 or 80 characters long.
      • The URLs should not include names or descriptions of the content that's available at the URL. For example, URLs should not include strings like "Mail", "Money", "People", or "Brian".
      • The URLs should not include any information about how the content is organized in the navigation hierarchy, or about how the content is categorized in any taxonomies used on the website.
      • Examples of good URLs:
        • http://openagenda.org/page.html?id=38762904
        • http://openagenda.org/page?id=38762904
        • http://openagenda.org/page.html#38762904
        • http://openagenda.org/page_38762904.html
      • Examples of bad URLs:
        • http://plone.org/documentation/archetypes/quickref#requirements
        • http://example.org/foo/index.php/iggy/content/view/full/45
  23. Free, and supported
      • Here's one key feature we're looking for in the software that we use to run the site — we'd like it to be free, as in free beer.
      • We'd also like to know that it will continue to be free for years to come, which suggests that we might to look for software that's available under an open source license, like eZ publish.
      • Lastly, we'd like the software we use to end up being active supported for years to come. We'd like to use software that has a thriving ecosystem of customers and developers and companies offering support services. That suggests not trying to cobble something together from scratch, unless you're extremely optimistic about the software gaining widespread popularity and leading to a thriving community.
  24. Search engine indexing
      • We need to make sure that search engines like Google are able to index all the "virtual" pages that OpenRecord serves.
• Priority 2 features
  1. Transparent email
     • Any user should be able to have a "transparent email account".
     • That user should be the only person who can send mail from the e-mail account.
     • It should be set up so that all copies of all the messages that user sends are automatically posted on the website.
     • Similarly, copies of all the messages the user receives should be automatically posted to the website.
     • People sending mail to the account will need to know in advance that their messages will be posted publicly, and we need to make sure they're okay with that. As a safety check, we could require that the first line of each message be a consent statement, like "I hereby dedicate the following message to the public domain, under the terms of the Creative Commons Public Domain Dedication, as described on the page http://creativecommons.org/licenses/publicdomain/". If that line is missing, we might automatically bounce the message, and/or send a reply explaining the problem and offering an alternate email address for private messages.
     • The email messages should be first-class items, that can be categorized and annotated just like other items.
     • We might want to automatically bounce any message that has an attachment, rather than try to figure out how to post attachments with messages. Also, attachments are likely to be in proprietary file formats, like .doc and .xls, which we'd rather not have content stored in.
     • We could also think about only accepting plain text messages, and automatically bouncing messages sent in rich text or HTML, if that makes our lives easier. Or, we could accept HTML mail, but then ignore the formatting info and treat the message as plain text.
• Priority 3 features
  1. Photos
     • It should be possible for account-holders to post photos to the site.
  2. Subscriptions
     • It should be possible to subscribe to all or part of the site.
     • Anybody should be able to subscribe to RSS feeds generated by the site.
     • Anybody should be able to subscribe to email mailing list feeds generated by the site.
     • Ideally, anything that's available for RSS subscription should also be available for mailing list subscription, and vice versa.
     • You should be able to subscribe to a feed that includes all new content posted to the site and all changes made to existing content.
     • You should be able to subscribe to specific portions of the site, such as
       • All the outgoing email messages sent by Brian Skinner.
       • All the outgoing email messages sent by anyone.
       • All the changes to the list of proposals.
       • All the changes to the one proposal my friend wrote.
       • All the changes to any charity on the list of charities.
       • All the changes to the records relating to the charity I work for.
  3. Live updates
     • When you're looking at a page, and an item appear in more than one place on the page, if you make a change to the item in one place, the item will automatically be updated everywhere else it appears on the page.
     • When you're looking at a page, and another user makes a change to one of the items shown on the page, the item on your page is automatically updated to reflect the change.
     • Similarly, if you have two browser windows open, each looking at a different page, if you change an item on one page the change will automatically propagate to the second page.
     • (This feature may sound wildly ambitious to experienced engineers, but is actually not too hard implement. The page being viewed just has some simple JavaScript code that polls the server once a minute or so, requesting a list of changes. The server replies with the list of changes, and the JavaScript code on the client updates the page. More details can be found in my 2003 paper about Observable Queries.)
  4. Additional types of sections
     • Pivot table sections — support for taking a collection of items and rendering them in a pivot table.
     • Bar chart sections — support for taking a collection of items and rendering them as a bar chart.
     • Scatter plot sections — support for taking a collection of items and rendering them as a scatter plot.
  5. Derived attributes
     • Users can assign simple derivation rules to attributes. For example, for an attribute called "Per capita GDP", I could create a derivation rule that says that "Per capita GDP" for this item is equal to "GDP" divided by "Population".
     • The derivation rules may be presented to the user as simple text strings like "[Per capita GDP] = [GDP] / [Population]", but the derivation rules are not stored as simple text strings. Instead, the derivation rules are stored using item pointers for the attribute references. If another user changes the name of the "Population" attribute to read "Total population", that change will not break the rule, and the next time you view the rule it will appear as "[Per capita GDP] = [GDP] / [Total Population]"
     • A derivation rule will only arrive at an answer if the referenced attributes have values that are of compatible types. The rule "[Per capita GDP] = [GDP] / [Population]" will work if "GDP" and "Population" have number values, but if one of them has a string value, then the rule will quietly give up without raising a fuss.
     • Even attributes without derivation rules can have more than one value, and an attribute with a derivation rule can have both a derived value and one or more user-assigned values.
     • A derivation rule might be used to populate an attribute with values retrieved by traversing references to other items. For example, for an item that represents a person, I might create a derivation rule like "[Cousins] = [Parents].[Siblings].[Children]", to say that a person's cousins is the set of all the children of the siblings of the parent of the person.
  6. Accessibility
     • The graphical styles respect default settings for fonts and colors in the user's browser, and conform to accessibility requirements.
     • The generated web pages follow commons accessibility guidelines, such as the United States Section 508 Guidelines, or the W3C's Web Content Accessibility Guidelines.
  7. On-line help
     • On-line help should be available.
     • Help pages are just normal pages, built out of sections and items.
  8. Client platforms
     • The DHTML pages generated by the site should work in at least the 2 or 3 most popular browsers on each of the 3 major platforms: Windows, Linux, and the Mac. We probably don't need to support older browsers, but we should support the versions of IE, Firefox, and Safari that are recent enough to still have a substantial installed base.
  9. Scalability
     • The system should scale up to handle small workgroups, with maybe a few hundred user accounts, maybe a couple dozen people browsing through pages at any given time, and maybe handful of people editing pages.
     • Caching?
     • Load balancing?
     • Data store replication?
  10. Polyglot items, internationalization, and localization
      • Polyglot strings, and polyglot items — see my 2003 Chandler email message describing polyglot strings and localization
      • Internationalization and localization, built using polyglot strings, and polyglot items
• Lower priority features
  1. Content rating
     • Maybe some sort of features geared towards letting user give ratings or rankings to content, so that the group can collaboratively sift through everything and have the good stuff rise to the top?
     • Maybe some sort of features for making your own annotations on items or attributes that other people created, so that you can keep track of what to build on and what to ignore — maybe tools for marking content as to whether you "affirm" it or "question" it.?
     • ...?
  2. Search tools
     • Maybe a simple search box in the corner of every page?
     • Maybe a separate page for doing more complicated searches?
     • Maybe brute-force full-text searching? Full-text indexing?
  3. Skins/Themes
     • Maybe end users can create new CSS style sheets and save them to the server?
     • Maybe end users can pick which style sheet to use with a given page?
     • Maybe each end user can each have their own default style sheet — we look at the same page, but I see blue text and you see red?
  4. Security
     • SSL support?
     • Audit trails?
     • Kerberos?
     • Certificates?
  5. Installers
  6. Submissions
     • Maybe workflow features that allow people to create proposed items, and then submit those items for approval?
     • Maybe workflow features that support the idea of "draft" status vs. "published" status?
  7. Spell checking
  8. Scripting
     • Maybe end-user scripting?
     • Maybe user defined macros?
     • Maybe filters?
     • Maybe rules for automatic categorization?
  9. Text recognition — "next Tuesday", or "call Joe"
  10. Interoperability
      • Interoperability with what? RDF, WebDAV, FTP, UTF-8?
  11. Peer-to-peer servers
      • Anybody can install this OpenRecord server software on their apache server, and then point it at a list of other known OpenRecord servers. All the OpenRecord servers can query each other periodically to stay up to date on the latest changes made on each server, so that all the servers are roughly in sync. All the content remains available and in the public domain, even if any one server goes down unexpectedly, and even if a server is suddenly taken off-line permanently (think government coup, or police raid, or corporate bankruptcy). The data is out in the ether, not locked into any one data store on any one server.
• Features that aren't part of what I have in mind
  1. Blog features
  2. Chat features
  3. Discussion forums
  4. E-commerce features
  5. Calendar views
  6. Email compose and send tools
  7. File attachments
  8. Advertising management
  9. Publishing approval workflows

Staged Implementation Roadmap

Should we decide to build our own software infrastructure "from scratch", rather than using an existing product like eZ publish, we will want to build out in stages. Here's are some initial thoughts about how to sequence the stages.

Feature Set	Milestone
	0.1 (minimal kernel)	0.2	0.3	.4	.5	.6	.7	.8	.9	1.0
Account creation	nope	nope — demo accounts are hard-coded	nope	?	?	?	?	?	?	yup — people can create accounts for themselves
Authentication	nope — you can edit without logging in	yup — users can log in	yup							yup
Scalability	nope — if two people edit, the system crashes	nope — only one user can be logged in at a time	nope							yup — a few users can be logged in at a time
Data store	nope — dead-simple single-file plain-text "data store"	nope — dead-simple single-file plain-text "data store"	nope							yup — safe and reliable
Clean UI	yup — we do good UI design from day one	yup	yup							yup
URLs	yup — we do good URL design from day one	yup	yup							yup
Items	yup — everything is an item	yup	yup							yup
Attributes	yup — any attribute can have more than one value — attributes are items too	yup	yup							yup
Data types	nope	yup — an attribute can have a suggested data type	yup							yup
Kinds	yup — items can be assigned to kinds — any item can serve as a kind	yup	yup							yup
Categories	yup — items can be put in categories	yup	yup							yup
Pages and sections	yup — support for table sections and detail sections	yup — support for outline sections	yup							yup
Editing items	yup — items can be edited	yup	yup							yup
Editing page layouts	yup — page layouts can be edited	yup	yup							yup
Change logs	nope — we only record current values	yup — change histories are recorded	yup							yup
Nav bar	yup — simple nav bar	yup	yup							yup
Standard formats	yup — XHTML, CSS, etc.	yup	yup							yup
Sunshine features	yup — nothing anonymous, nothing invisible, no decay	yup	yup							yup
Platforms	nope — just Firefox on windows	nope	nope							yup — IE, Firefox and Safari, on Windows, Mac, and Linux
Search tools	nope	nope	nope							yup
Subscriptions	nope	nope	nope							yup
Photos	nope	nope	nope							yup
Transparent email accounts	nope	nope	nope							yup
Live updates	nope	nope	nope							yup
Content export	nope	nope	nope							yup
Accessibility	nope	nope	nope							yup
Interoperability	nope	nope	nope							nope
Skins/Themes	nope	nope	nope							nope
Derived attributes	nope	nope	nope							nope
On-line help	nope	nope	nope							yup
Polyglot items, i18n, l10n	nope	nope	nope							nope
Security	nope	nope	nope							nope
Scripting	nope	nope	nope							nope
Text recognition	nope	nope	nope							nope
Installers	nope	nope	nope							nope