General characteristics of blogs:
- Reverse-chronologically ordered entries, consisting of:
- Title
- Body
- By-line
- Date/time-stamp
- "Permanent" link
- Comments
- Explicit support for maintaining draft entries prior to publication
- Explicit support (or just conventions?) for indicating updates to published entries
- Comments are generally linear (not threaded), and usually pop up in a separate (small) window.
- IP-based blocking is supported on many blog tools.
- Conventions for font and link styles (could almost be handled by current template tools in bridge)
- Content summaries via RSS (?)
- Email notification when new entries are posted
Notes/issues:
- Synchronous text might be useful for entries, but would be overkill for comments. (A SharedList of strings should suffice, particularly if comment lists are not extremely long. Even if they are, it isn't clear that splitting them up would help since we will typically want to render them all anyway.)
- Should look at the "Blog This!" tool from Blogger. It's essentially a link you keep in your browser's favorite's list. When you get to a web site you want to address in your blog, you jump to the "Blog This!" link and it opens a simple edit window complete with a URL to the previous web page (the one you want to talk about). There is a publish button on this tool that will then publish your comment to your blog. No need to go to your regular blog editing tool.
- A blog-based tool might be useful for journalling activity in the kind of workspace-based projects that we are attempting in the Awareness project. They could serve both as a record of activity and as a kind of "email without delete".
- We need to think about additional meta-data that could be associated with entries, such as topic/subject area, and alternate views of the database that could be generated based on this information.
- To simplify permissions management, the blog data could be structured as a folder containing:
- A blog config object. This would be responsible for rendering the "front page" of the blog
- A drafts folder, containing (undated) draft objects that could have restricted read permissions
- Entries should be containers, so that they can hold complex content objects as well as discussion objects.
- A content folder, containing the content from published blog entries. Internal structure should allow hashing over publish date. Naming of the content should automated (using publish time).
- Need to think about things like versions on the draft-to-published step. I suspect that we want to copy the content and throw away the draft, or at least have that as an option. (For security reasons.)
- A discussion folder, containing discussion objects structured and named the same way as the content folder. This folder would generally have less restrictive permissions than the other objects in the blog folder.
- A templates folder, with template instances of content and discussion objects.
- A trash folder, for deleted entries
- This kind of structuring suggests the Packages notion that we've considered for other things (like concept maps) that are open-ended, structured collections of objects.
- Discusion link handling could be done via an option on the config object, to allow on-demand construction of discussion objects. (This would prevent a lot of empty discussion objects being created for blog entries that are never commented on.)
- By-lines (for entries) should probably be defaulted but editable, to handle cases where people want to use their real names (instead of IDs) or where entries were collaboratively authored.
- Dates should probably be similarly configurable, though actual posting date should be preserved somewhere. (This is will simplify importing existing content, but still provide a way to discover when things actually appeared.)
- Email notifications are a long-standing omission from BRIDGE. Need to think about a general design for this...
- IP-based blocking would also be a generally useful extension to BRIDGE's permissions scheme.
- Comparison of blogging systems here: http://www.asymptomatic.net/blogbreakdown.htm
- Does not include SniSnap, a Java-based blog/wiki tool
- Trackback/ping
- Docs:
- Trackback Ping URL associated with each entry (may be auto-discovered)
- URL is added (in MT) as part of the entry configuration
- Should trackback URL be separate from entry name?
General reflections
Blogs, being highly structured collections of essentially two kinds of content, are particularly well suited to more structured database approaches. It is likely that a BRIDGE-based blog system could be considerably more flexible than the current generation of blogging tools, but will likely:
- Require relatively more manual construction to maintain the order, or require relatively complex machinery for automating the structure (e.g., maintaining large collections in a reasonably efficient way and with appropriate permissions for entries and comments).
- Not scale particularly well.
These same problems are encountered other applications that have relatively fixed structures, such as the next generation "moo" object. A good solution to these issues, allowing unstructured collections while better supporting structured apps, would result in a much more interesting system.
Initial Structure (rejected, see below)
A blog is a specialized website that includes the following:
- A "drafts" directory, which will include subdirectories for draft entries.
- By default, an entry will contain a text object, with meta-data stored in the object's
EmbeddedObjectDescriptor.
- If configured to do so, a separate object for the abstract will be added to the directory.
- Images or other media associated with the entry can be added to the entry's directory.
- A discussion object will be created on-demand for the entry, if configured to allow discussion.
- The entry directory itself will be the preferred addressable/renderable unit for the entry.
- On further reflection, this approach seems problematic. Storing meta-data that isn't automatically updated (e.g., name and date) in the EODescriptor has proven problematic for threaded Discussion objects, and the added complexity of a directory (primarily just for image upload support) seems unnecessary.
- An "entries" directory will contain published entries, hashed by time.
- Should hashing be configurable, or will something like "year/month/entry" be sufficient?
Initial Structure II
A blog is a specialized website that:
- Extracts templating information from a template object either in itself or in its parent, if its parent is also a Blog
- Contains a directory (sub-Blog) for each year in which blog content has been published
- Each year directory will, in turn, contain per-month sub-Blogs that hold BlogEntry objects
- Contains a "drafts" directory (which may be a sub-Blog?)
- Contains a "comments" directory, hashed in the same per-year/per-month way as entries
- comments would generally have more open permissions
- CommentList objects would be created on-demand
- Contains a BlogIndex object that renders a configurable index to sub-blogs, and which can be embedded in a sidebar
- Includes state for:
- Number of entries to show by default, with default of "all"
|