Sedgewik
From WhyNotWiki
"Sedgewik the intrepid wiki system" (formerly "Wrinkle") is the working/code name of this project. The name is likely to change several more times before it is finished.
Wrinkle edit (Category edit) .
[edit] Introduction
I plan to write a new wiki/information management system/whatever-you-want-to-call-it in Ruby that knocks the socks off of anything out there right now.
I would like to take the best ideas from such projects as:
- Semantic MediaWiki
- Basecamp
- Backpack
- ActiveScaffold
- Tumbleblogs
- TuxCards
- ...
...and combine them with my own ideas.
Or, I may decide it's most efficient just to join/extend one of their efforts rather than starting from scratch...
[edit] Status
This project is still in the early planning stages.
[edit] Purpose/goals
In my case, this has as much to do with Category:Organizing and Writing as anything. I want something to:
- organize all my random thoughts
- publish my articles (that are worth publishing) online
These goals are somewhat removed from each other, but I think that they can/should be combined into a single database/application.
By having the relational database aspect of it, I can promote several things:
- categorization, and hence organization
- reusability of data (just include/reference the appropriate record by id/URL, rather than copying and pasting content)
- enforcing constraints (like, all books that I talk about must have an associated author). This also promotes my feelings of organization.
But then for the publishing side, I can perhaps compose articles that reference / include from that database. I'm imagining taking chunks of random thoughts from my "random thoughts database", stringing them together in some coherent order and with some "glue" text to tie them together and declaring the result an "article" (which may have a blog article and an item in an RSS feed associated with).
It is in a sense a cross between a wiki and a blog:
- the wiki aspect is that it is very evolutionary--articles will tend to not be written in one sitting but rather over the course of several session, each one adding a bit of content or iteratively refining the wording/quality.
- blog: articles are organized by tags (categories); it is a form personal expression, publishing things about things that matter to me, organized in a way that makes sense for me
[edit] A wiki
It's largely going to be a Personal Wiki, but I think I want it to be possible for it to cooperate in collaborative wikis too...still need to figure out how all that's going to work.
[edit] A personal wiki
or a "brain cache"
If you ever think to self, 'didn't I read/see something cool about that a couple months ago? where did I see that?', this might be the tool you need to keep track of those sightings...
[edit] [Motivation (category)]
Currently I'm storing my random thoughts/notes in about 50 different text files. And I can't even do multiple categories that way! And I can't access it when I'm away.
[edit] Problems it attempts to solve
Wrinkle / Problems it attempts to solve edit
[edit] Design principles/(nonfunctional?) requirements
- Have many small pieces/objects that are woven together, rather than monolithic page objects like in MediaWiki
- It's as much about the relationships between objects as the content in the objects
- Object-oriented
- Ruby-powered
- So quick and easy and intuitive to edit things that people will want to do it
- Any topic object can be treated as a category/container.
- make it as easy (or even easier) to post stuff to an install of this system as it is with delicious (specific feature: bookmarklets)
[edit] Small pieces/object
Why? Because it facilitates/promotes the following good things:
- very easy to reorder things, while retaining good stuff like revision history tied to that small object
- accurate maintaining of revision history when it is moved, etc.
- fine-grained licensing/authorship/source tracking
In MediaWiki, you can make lots of tiny objects ("articles"), but it doesn't work well... Why not?
- Because you have to edit each of those on different pages, for one thing. (I want to pull the tiny objects together onto one page and allow in-place editing via Ajax.)
However, in the meantime, I'm going to try doing that anyway.
Even though the tiny objects are independently viewable and editable, I anticipate that most of the time, they will actually be viewed on a page that includes them. In English: those objects will actually end up being the sections and paragraphs on a page.
Why?
- more readable + better user experience to have decent-sized pages, rather than clicking many links, going to many tiny pages
- the larger page is where most users will find this information
- we can rearrange sections on the larger page to achieve an order that makes the most sense and is the most pleasant to read
(Negative) side-effects of this design decision:
- entire "documents" (which are actually comprised of many smaller pieces, combined together) may not flow as well, be as "readable". I think that's okay though. We may have a link from one section to another. That's okay though. It may look kind of funny, but it will still work and shouldn't get in the way too much. (Required feature: links from one section to another, when the sections are on the same page, will need to be translated into a same-page link (using # in the URL).) (What links am I talking about? Those links make it so the "sections" are usable even as standalone pages. If they refer to some idea from another "section", they need to link to it, because we can't assume it will be read in a context page that includes that other section.)
Positive implications:
- People can sign up for [change notifications (category)] ("watch this article" in MediaWiki) with a finer granularity. Rather than getting notified anyone changes any part of some huge, monolithic article, just sign up for those sections (objects) that you care about and you'll only be notified about changes to those.
See "Extract section and move to new page" on Transitional wiki.
To make it easy, it would be good to be able to create untitled pages/objects. In other words, don't require each page/object to have a title. Many such objects will appear as sections on the page and not be viewed independently, so a title really isn't necessary.
[edit] Quick, in-place editing
Frustrated by how long it takes just to switch to (and from) page editing mode in MediaWiki. I think some in-place editing Ajax magic could help with that.
You could even in-place-edit individual list items. Plus drag and drop them around. Ideal for editing to-do lists (which is a pain in Mediawiki).
In-place Ajax adding, changing of categories.
Drag and drop reordering of sections.
[edit] Design idea: wiki aspect as just a plugin/component rather than the primary idea
— Tyler (2007-03-07 13:38):
I've recently decided that I might have been looking at designing this completely backwards. Rather than basing it on MediaWiki and asking "how can I add on all these nice metadata / inter-object relationship features on top of it", maybe I should be building that part first -- creating the needed tables/models/etc. first -- and then decide how to get wiki features -- revision history, markup language, etc. -- to work inside of that framework.
I don't think it will work as well as I'd like to just tack on my features on top of the MediaWiki schema/framework. It doesn't support metadata very well (you'd have to encode it in the main wiki text, as I understand it) and doesn't have separate columns for the things I want to be searchable, sortable, etc.
I think I'm learning towards making the framework more table-centric and maybe just have one or two columns be "wiki-enabled".
I think I'm learning towards having a lot of specialized tables, one for each mini-application . For example, a
software_projectstable that stores information about software projects in a very structured way. I think that's the only way that will satisfy me.So software_projects will have many columns that are not wiki-enabled (in the normal sense): home_page_url, repository_url, license, authors, etc. These columns certainly may have some of the features that wikis have (revision history, etc.), but it's important that they be in their own columns. Then we can filter, search, sort, etc. on that column. We can sync those columns with an external/more authoritative source (like rubyfurnace, rubyforge, etc.) so that our copies of those columns don't get out of date, etc.
So most of the fact-like properties (objective, not subjective; there is only one right answer) of a record will have their own highly-structured, validated columns. That way it will be generally useful to anyone and they can benefit from my/our organization/folksonomy.
They don't, however, have to use/care about our more subjective content, like "comments"/"things I like about it"/"examples"...those "fields" can all be fully wiki-enabled (maybe one wiki field for each one so we can make it even more structured than just having one free-form wiki text field): People can collaboratively write examples for a particular software library using fully-featured wiki-text markup.
People could even have their own personal "wiki field" for every object. (Of course, that would actually be stored via a has_and_belongs_to_many relationship rather than being a single column for each user in the table.) That way people could store their own personal notes/thoughts about a record if they wanted without cluttering up the primary wiki-text/primary namespace. But it would be different from just storing those thoughts in their own blog or on their user page -- it is much more integrated than that. Their notes are associated tightly with the record. So for them, their notes would be appear as part of the record. (If they are private, though, then no one else can see their notes.) It lets them benefit from the collaboration of others while letting people "customize" it for their own use by attaching their own private notes/categorization.
[edit] What is it? Some ideas...
Perhaps it is a framework to tie together tables and wikitext.
Perhaps it is a plugin architecture and set of standard plugins for life hacking and information acquisition/organization.
Perhaps it is a brand-new idea for wikis...to make them completely object oriented.
[edit] Questions / unresolved problems
[edit] How to display links
[edit] Sections of page
[edit] Problem: Can't remember the "official" name of the category
In my current wiki, I attempt to solve this in the following less-than-ideal way:
- By listing possible alternatives and the preferred option from among them on pages dedicated to that purpose: Preferred synonyms, Naming conventions, WhyNotWiki:Conventions
- By using to my advantage the "red links" that mean the category doesn't exist yet that appear after I save an article that references possibly non-existent categories: when I see that, I ask myself "is that simply because this is the first time I'm trying to use that category or because the category exists but I just didn't spell it correctly / use the preferred/correct synonym?"
- The Aliases template. Even though it's only used on article pages now (because I don't want to duplicate on the category page, the aliases for a category can be assumed to be equivalent (or nearly so) to those for its corresponding main article page.
But in the new system, I want to do better... I want to actually plan for/prevent this problem rather than reacting to it by means of ad hoc workarounds...
[edit] Solution 1: Make it easier to find the preferred/correct category name
This means things like:
- Selection via intelligent text boxes. Completion/suggestion menus as you are typing the name of category: in other words, if we use a text box at all to help people locate a category, it will act like a real-time search. Probably will end up using Lance's "RecordSelect" plugin for this? Also allow the creation of a new category by means of this same search box (in the event that no suitable match is found)?
- Selection via intelligent "guess" lists: Provide handy lists of the categories the software thinks you are most likely to want to use (its "best guesses").
"Best guess" lists might contain:
- recently created (by me | by anyone)
- recently used (by me | by anyone)
- important / highly weighted categories/topics/tags
[edit] Solution 2: allow usage of aliases/synonyms
In other words, don't focus so much on guiding the user to the "one correct" spelling/name, but rather allow multiple correct spellings.
There could still be one "correct" spelling for every category/topic/tag. But we would provide easy access to it via "aliases". So you could type in your alias (whichever one came to mind as you the user used the system) or choose it from a list and it would work just the same as if you'd used the "preferred" name.
[edit] My wiki-text idea
I might compose articles using a sort of wiki-text:
<h1>Some catchy title</h1>
{{include_photo :id=>3551, :size=>"main article image"}}
Introduction text blah blah blah...
{{include_photo :id=>1390, :class=>"floated side image"}}
...more paragraph text...
{{text_snippet :id=>34}}
...more paragraph text...
Here are some more examples of this concept:
{{list_of_links :in_category => 14, :order_by => "my_rating", :limit => 8}}
See also:
{{list_of_links :in_category => 91}}
You can see that it's pieced together from multiple tables/database: I can reference my database of "random thoughts"/"text snippets", my database of nicely-categorized hyperlinks, or even my photos--all of which can be managed using a very suitable tool (rather than from the wiki itself). The wiki would be just to pull stuff together into more "publishable", human-reader-digestable, blog-friendly format.
"text_snippet 34" might be reused in a number of articles. It might be some really well-written paragraph or a quotation from some famous guy named Hed.
[edit] Links
Maybe have some easy, consistent way to link to any sort of object...?
<%= link_to Quote.find(13) %> <%= link_to Source.find(91) %>
[edit] Source references
Information management system / Sources
[edit] Easy-to-use UI
[edit]
Of course, you wouldn't be expected to just know the ID of each record you want to reference, nor should you have to manually type the "text_snippet" tag. Instead, you'd use an AJAX-powered sidebar. There might be a list of the main includable-record databases, like "Sources", "Songs", "Movies", "To-do items". When you clicked one of those, the sidebar would expand to show a search form. You'd search for the name of the movie, for example, and all matches would appear below, in the sidebar. You'd click one of the results and a reference to it would be inserted into the textarea on the left.
[edit] Interface to promote words into keywords
Sure, of course there will full-text searching, so maybe it would even index all (non-useless, so not 'a' and 'the') words automatically, to enable speedy searching...
However, it still seems like there ought to be some concept of keywords. Each article has a collection of keywords that help to make it more findable when doing searching. Perhaps this feature is nothing more than another name for the tagging feature.
The interface could be folgendes: Either double click on the word or click for a context menu and then select "add as keyword"... You could very quickly pick out the words that you thought were key and just rapidly click on a bunch of them... And you're done.
This would be equivalent/similar to my current practice of using {{section category}}, except it wouldn't remember which occurence of the word in the text was selected; it would only care about the spelling of the word, not its position in the document.
So it would store this list of keywords in a separate table from the article text, associated with this article, sort of like tags (if not identical to tags).
[edit] Smart UI
[edit] Should be easy to post an "Answer" that links to a "Question"
If an article is in the Questions category, have it automatically generate a "post an answer" form/link/button. This would automatically be linked to the question with a "answers this question" relationship.
[edit] Types of content
Obviously we're going to have text. The text should be able to be formatted, so now we're looking at rich text/hypertext.how should we store that text? Probably as wiki text so that it's easy to edit. But allow some HTML tags.
We also need to be able to generate:
- flowcharts/digraphs: GraphViz for MediaWiki can do that
- Timelines
- Maps, with: roads, lakes, rivers, and points of interest that I define.
[edit] URLs/addresses/paths/routes
[edit] For articles
Each wiki article has exactly 1 primary/wiki address associated with it.
But may, however, have other/alternate addresses/paths associated with it. Each category that it's in will have its own path.
Example:
- Primary: Transportation :: Ideas
- Others: Transportation :: By land :: By automobile :: Ideas
[edit] Permalinks
The only way to implement them would be by some ID number that never changes. That shouldn't involve categories, because the categories as an article is assigned to may change.
[edit] Revisions
[edit] Explicit revisions
In some ways... I like how MediaWiki automatically saves every revision that is made. But most of the time those are minor edits that should be hidden most of the time.
I think I'd want the default to be "minor edit" and then be able to choose from:
- Significant revision
- Additions (possibly combined with possibly minor revisions)
On each page/article/section, I could (optionally) display a condensed revision history:
- Created 2006-06-02
- Revised [significant, not minor] 2006-06-15
- ... (2 more revisions)
- Revised 2006-07-09
[edit] Tag revisions
Sometimes I want the ability to explicitly tag a revision like I do with Subversion.
Why?
- For instance, before doing a major rewrite of a page. Want an explicit tag that I can roll back to if my rewrite goes awray.
- Or if I want to use the snapshot of how the page is right now as an example that I can refer to (and not worry about it changing under me).
[edit] use Subversion??
Just a crazy idea, but could Subversion somehow be modified/used to handle the versioning?
Maybe make Subversion store its version data to a database instead of a file.
And have:
- the wiki save command actually do an svn commit
- the wiki rollback command actually do an svn merge
- etc.
[edit] Features/To-do list: High
Wiki features edit (Category edit)
[edit] "What's new since the last time I checked out this article" / Pretty/simple diffs / highlighting changes/additions
See also: Change notifications
Let's say I just finished doing some significant additions to my list of reasons why Ruby rules... I've added 14 new reasons and added new examples to 9 of the reasons I had on there before (the last time I announced / presented that document).
I want to let everyone (to whom I showed/presented the previsions version) know about the cool new additions. But I don't want to force them to wade through a big long list that contains most of the same items as before and have to search for what I might have added since last time. Because the new stuff might be few and far between (especially for a large document).
I don't really think people would want to look at a diff...would they? A diff would only show the changes, not the context (or at least not very much context).
Or maybe it's me who would prefer visitors to not just see a diff but to see the whole document again. So I'd want to show them the whole document but I'd want all the changes to be highlighted so they can skim through and find them. My hope would be (?) that they'd get more out of their read if they saw things in context... And also that they might see some of the "old" content this time that they skimmed over the last time...
So it would sort of by a diff, but with full context. Additions could be in green and changes in orange or something? Also, I probably wouldn't want to show deletes (too embarrassing?), unless they were very important.
Also, things should be pretty coarse. Maybe. So instead of just highlighting each new word that has been added, I would mark the whole paragraph as modified. But only if it is worth mentioning, otherwise I would not draw any attention to it.
Another advantage: minor edits would not clutter things up for the reader... (This could be solved trivially be just doing a diff that excludes minor edits, but I'm currently thinking that a bit more human (author) screening/tweaking of the diff would be beneficial...)
[edit] (Viewing as database table) Drag and drop of tags/categories
Say you are browsing a page of Rails plugins (perhaps a specific subcategory of "Rails plugins", since you'd be insane just to browse all of them at once) and you saw that acts_as_activated was tagged with "acts_as" but acts_as_locateable wasn't.
You could simply drag and drop from the one plugin to the other and it would add it to the target record!
This would be especially useful in conjunction with the feature that lets you hide all details except the fields you wish to drag and drop between (in our case, it would mean hiding all details except name of project and tags).
[edit] (Viewing as database table) Comparisons made easy
There will be features to make it really easy to compare two homogeneous (same type) records (or even non-homogeneous records if you want to push your luck).
This would mostly be accomplished in the view-level so that they are able to collapse/customize the details that are displayed so that they can see several records "side-by-side" and only show the fields they're interested in comparing (not cluttering up the view/list by showing all fields).
(Have I started an article about this yet?).
[edit] (Viewing as database table) Expand/collapse (show/hide) details
This feature was inspired by Firefox's Web developer toolbar plugin's recent (I first noticed it in 1.1.3, around 2007-03-14) Collapse All/Expand All innovation, which makes it easy to browse the included CSS by CSS file filename. Assuming you're only interested in looking at one particular file, you just have to first click Collapse All and then expand the one file you are interested in (rather than having to do a Find or simply scroll down the huge page, past all the details (file contents) that you don't care about right now!). Several things to note about their implementation and what makes it work so well:
- Everything is done client-side with JavaScript which makes it blazing fast and responsive.
- Default state is all expanded. Can switch to "titles only" mode with a simple click of the "Collapse all" button and then expand the individual item you are interested in by clicking the + icon beside that title (the title itself is a link to a new page containing the contents of that file alone).
In our case, we would have:
- a "collapse details" link/button (causes it to only show names/titles)
- and then a bunch of "sublinks" (configurable) which work the same as "collapse details" only they like one additional section expanded (these be abbreviated/iconated rather than spelling out all the words):
- collapse but show tags (keeps tags section expanded but hides all the other details)
- collapse but show licenses (if you wanted to compare, or drag and drop between, license)
- collapse but show implementation language
- collapse but show user ratings/comments
- expand all
[edit] Using a desktop GUI frontend
Why?
- To significantly increase speed/latency
- Off-line usage (traveling with your laptop, etc., where you won't have access to the web server)
[edit] Stand-alone desktop app
This could either be used to access/modify the remote database or it could be used with a local/offline copy of the database.
Either way, it needs to be
- high-performance
- fully featured (having all the features that the Web version has)
- fully editable (not read-only, even if you use a local/offline copy of database
[edit] Integration with Firefox
Maybe sort of like Zotero (Firefox extension) does it... As in, maybe at least one frontend to my database could be via a Firefox extension. That way, you'll have access to all web-page-related features of my application right from your browser, right where it makes the most sense to have them.
Like Zotero, you should be be able to create a "bibliography entry" for the web page you're currently looking at -- and add whatever metadata you want -- and also create a snapshot of the page -- all with a single click.
Doing so should post that information to my wiki/database. Or would that be too high-latency, having a remote DB? Might need to have a local database and do two-way synchronization (see below).
[edit] Two-way synchronization
To allow offline usage, we'd need to have -- and for speed reasons, we may want to have, even if you do have access to the Internet -- a local copy of the database. The main problem with this is that you need to do some kind of Two-way synchronization, which can be a very difficult problem.
One idea: have/use a distributed database like darcs has
Or just do your regular two-way synchronization algorithm...
[edit] Offline usage
Queue additions for later synchronization to the master databas...
[edit] It should be very easy to reuse/include a section/snippet in two different places
See also: Small pieces
Contrast with MediaWiki, where you have to:
- edit the article that has the content you wish to reuse; cut to clipboard; replace with a transclusion directive "{{:ReusableSnippet}}"; save article
- click on ReusableSnippet link, which lets you edit and create a new "article"; paste from clipboard; save article
- navigate to other page where you want to reuse it; add transclusion directive "{{:ReusableSnippet}}"; save article
Phase 1 plan: for pre-existing content:
- identify (in your head) the content that you want to reuse
- if it's already a standard section/paragraph entity, click a little icon (or drag the icon) beside the existing entity and choose "copy reference to" from the menu; it will copy the id of that section to the app clipboard via Ajax
- (if it's not a standard section, you'll need to wrap the text in something like a span tag, or maybe insert a breakpoint tag at the beginning and end of the text you want to use)
- identify the place where you want to reuse it
- click the little icon beside the section, choose "paste before" or "paste after" and it will use Ajax to add it to the document (database) at that point and update/reload the view to reflect that.
Phase 1 plan: for new section:
- ?
Phase 2 plan:
- drag and drop over text you want to reuse: it will automatically create breakpoints if they aren't at standard breakpoints
- drag and drop to icon representing "new snippet/section"; it is created and saved immediately and the source of the drag replaced with an include for the snippet
- drag and drop to destination
[edit] Category editing
In addition to letting you type in the name of the category you wish to add to this page, also let the user select the category from a list.
Why? Because it can become tedious to have to manually type in a list of categories on each page. And for those of us who use a pointing device, it would be nice to be able to use the pointing device to add categories.
This feature would try to help you by listing categories that you have a high likelihood of wanting to assign to this article. It will list those categories that it thinks are probable in a list so that you can simply click on them to add them, rather than having to type them out.
But don't just list all categories -- there may be too many to list. Instead, just list those categories that the user is most likely to want:
- Most-commonly-used categories: the categories that this user has (historically) used the most in the past
- Recently-used categories: the categories that this user has used in the recent past
- Nearby categories: all categories on all pages that are within one step away (pages that it links to or pages that are in categories that this page is already in). (similar to MediaWiki's "related changes" feature)
[edit] Intelligent adjustments to heading levels
For example, if I transclude "Rake in the context of Rails" into a h2 titled "Command line tools" on the page "Rails", it should fix the heading levels so that the top-level heading of "Rake in the context of Rails" becomes an h3 on the containing page.
But if it's transcluded into a different containing section that has a h3 level, it should reset itself to start at h4.
MediaWiki doesn't do this. But it does correctly handle section editing, which is impressive:
- even if the transcluded section is an h2 and the containing section on the containing page is an h2, it will still include all the content after the transcluded section.
- clicking the Edit link for the transcluded section goes to the transcluded page not the containing page.
[edit] Single in-article annotation (source details, etc.) edited on that article, but stored elsewhere
For example, I want to have a single database table with all my sources and only my sources. I don't think the MediaWiki Cite extension (or any other?) lets you do this.
Instead, Cite stores your list of sources cited in that article within that article's wikitext!
That works... but what if you cite the same source on a different page? What's to tie them together? What's to ensure that the citations are consistent on both pages?
I can only think of one solution: store the list of sources centrally (in a sources table) and let all articles which want to cite a source actually reference a record in the sources table.
However, I think it might be good to still create the illusion that the source information is stored locally. (?)
That is, when you start editing a page, maybe have the details pulled from the source record and displayed as wikitext. But when you save, parse the wikitext and store any changes back in the source record.
Or, have a separate link to inline-Ajax-edit the associated source ... using separate text boxes for each field. I think that might be less error-prone and actually easier to use. (?)
Would need to warn the user, "you are editing a source record, which may be used on other articles".
Another example: collect notes/annotations centrally
I want to collect notes about planned metadata... I write those comments in the pages/sections themselves. That's where it makes the most sense to write them -- because what I'm commenting about is right there in front of me, easy to refer to and read as I'm writing.
But I want to aggregate those all those notes on one central page. There appears to be no way to do that in MediaWiki currently.
I could enclose my notes in a template, Template:Meta, which would cause the notes to be displayed in a pretty box (or hidden completely in an HTML comment perhaps). The template could also cause the section containing the notes to be added to a category, Category:Pages with metadata notes ... Oh wait, no it wouldn't, because MediaWiki can only add whole articles to a category, not individual sections!
All right, so I could then go to Category:Pages with metadata notes and see a list of all pages containing sections that had notes in them. But it wouldn't show the notes themselves.
So, maybe we need a feature that lets you put markup like this on a page:
<annotation store_in_category="notes about metadata"> My comment... </annotation>
and when we saved the page, it would actually store it in a separate table.
Then when we went to Category:Notes about metadata, it would show a list of all those comments, along with a link back to the page/section with which they were associated.
Another example: centralized to-do list that pulls from individual entries
I should be able to have (what appears to be just) a local to-do list for every article/project/etc., but actually have it pulled into one centralized master to-do list, where I can see all the pending things that need to be done.
Why? Because otherwise I may forget that I jotted down a to-do item on some obscure page and I'll never run across it again for another 5 years.
Again, I could use templates/categories to at least get a list of all pages that contain local to-do lists... but I want to actually be able to combine those local to-do lists into one giant list!
Another example: be able to review all citations
I want to look at all the citations I've made, observe how wildly inconsistent I've been, see if I've tended to use one style more than another, see which one jumps out at me as a favorite, and then maybe adopt a convention. After choosing a convention, I then need to be able to go through and fix all of the citations that aren't following the convention!
I need an easy way to allow processes like that!!
Again, we could just use a template for all citations and have the template include a category like, but that would only give a list of pages that included the citations...
I want to be able to pull in the actual text of the citation -- from every page in that list -- all on one page.
[edit] Features/To-do list: Low
[edit] Templating (page "type") features to promote consistency and save time
By templating, I don't mean like the templates that MediaWiki has, where you have to pass in arguments and it very deterministically returns a resulting chunk of HTML.
I'm thinking more of a fill-in-the-blanks-as-you-go in-page kind of template.
You will be able to specify that a page uses a template (or multiple templates), which will give hints to your page editing interface that will help it to help you more intelligently.
[edit] Page content:
It might give you one-click access to commonly-used headings/sections or other boilerplate text that makes sense for this type of page.
[edit] Categories:
- Certain categories will be inherited automatically
- Others might be optional/suggested categories that users of this template are likely to commonly want. These will be listed in a ghosty/grayed-out state that you can just click on to activate/use. (?)
[edit] Expando-sectons
See also: Information management system / Section objects
Each visible section (block of text, usually with a heading, but not necessarily (code examples, for example) ) can be collapsed (hidden) by the user.
Collapsed sections still show the heading, but not the rest of the contents of the section. Each collapsed section (block of text with a heading) can be expanded (made visible) by the user.
Rationale:
- Sometimes a section logically belongs as part of the page but it is somewhat secondary in relation to the main content of the page and it would make it too cluttered to include on the page by default. So rather than including it by default, we include just a link to it by default but give the user the option to include it on the page if they want.
- This flexibility might be particularly handy when a reader wants to save or print an article by wants to choose specifically which sections should be included: don't make the user download and edit the page by hand!
The author can choose the initial state of each section (extended or collapsed).
Solves: Temptation in MediaWiki to make my headline also be a link.
Why am I tempted to do that? Because I want:
- Don't want contents inline
- But do want it listed within the heading/outline hierarchy
[edit] Expando-links
Similar to an expando-section, an "expando-link" is a link that, when clicked, uses Ajax/JavaScript to display the target of the link inline on the current page. Every link on the page can be used as an expando-link: just click the "expand" icon beside the link and it will expand.
Applications:
- polling in the contents of a related internal page
- comparing two pages (that the current page links to) "side by side" without having to open them in new windows/tabs (this example is a bit of a stretch)
- supposing we link to an external example, the reader might want to pull the example into the current page so that it appears in the context, rather than open the external example in a new window/tab. (This would be technically challenging to do well, however, because we would need to strip off the layout of the external page and just pull in the content.)
Design details:
- If the link is in the middle of a sentence/paragraph (which it normally would be), then we would want to pull in the contents of the target to a new paragraph below the current paragraph.
- We should add source information (as much information as we have about the source) in addition to just the information from the source.
- Always show a link/button for the the non-default behavior. So if the default is :expand_inline, show another link (as a small icon) that will open the page normally (or in a new tab/window if the user uses that feature of his browser).
The author can choose the default behavior of the link from:
:expand_inline-- use Ajax to load the target and display it inline below the link:normal-- normal link that causes the browser's URL to change,
Example of when you'd want the default to be an "expando-link":
==How to write to a file== [[Ruby / Example of opening a file in the temp dir | :behavior => :expand_inline]]
[edit] Renaming a page will also fix all references to it
When you rename a page, it should automatically find all internal links to it and ask you which of them you want to also rename (default to all)
[edit] Hierarchical category display
Category pages: option to show hierarchical display (subcategories and articles), so you don't have to to click subcategory to see its articles. Remove the temptation to manually create a category index page that has some hierarchical organization.
http://meta.wikimedia.org/wiki/CategoryTree_extension
[edit] Restricted-access pages
Idea: I want to be able to send friends a link to an article/page that is accessible only to my friends.
Problem: I need to authenticate them in order to see if they are on the list of allowed viewers. So they need to log and first. But they don't have a login/account yet -- how do they login?
Solution: Give them a separate link (in the same e-mail with a link to the article of interest) to a registration page, passing a special token in the URL.
- The token grants this user a one-time registration for an account with their name only. So if I sent the invitation to Terry Smith, the real name field would be filled and with the name "Terry Smith" and could not be edited. And once the token has been used, he cannot be reused, thus practically eliminating the possibility that someone other than the intended recipient will be granted a privileged user account.
[edit] object/node type: Hypothesis
have a Hypothesis object/type to store the theories/hypotheses that I have. It would have a "certainty" attribute.
[edit] Concerning its multi-user, collaborative nature
[edit] [Feature] E-mail notification of changes
- "E-mail me when anyone changes any text that I authored"
- "E-mail me when this page changes."
Include a full diff, of course.
[edit] [Feature] blamemap
[edit] Timeline / History / Meta
— Tyler (2006-07-07 22:22)
- This is one of my favorite projects, since I think it will be immensely helpful to me for my writing and organizational needs. I think it could be helpful to others, too.
- The project started in the summer of 2004 (actually, the first backup copy I see is for 2004-03-31). I first created it as an Access application (Access 2000). But after not too long, I realized that Access wasn't going to be the final platform I would leave the application in. Access let me create a prototype fairly quickly, but so much time was wasted debugging silly VBA bugs and overcoming shortcomings that it soon became a maintenance headache.
- It looks like a pretty much abandoned that version of the project around 2004-09-07. My next task (— Tyler (2006-07-07 22:22)) is to migrate all the data and features from that prototype into a real, maintenable project: a Rails application, of course!
- I intended from the beginning for that data to be served on the Web. My naive plan was to use Access as a backend for managing the data/content (since it was such a "nice interface") and then to regularly export to a MySQL database and host that on the Web. It didn't work out though.... which is probably for the better, because that's not the best way to do it.
- I think Rails was just the thing I was waiting for with this project. It's a perfect fit.
- With Rails's ActiveRecord for quick development of database-driven application and Ajax for slick user interface design, I've got everything I need. Access, I no longer need you: goodbye.
[edit] Unsorted
"Aspect-oriented writing" (non-linear; branching); like aspect-oriented programming
[edit] Article metadata
[edit] To do
Split out the writing-related stuff to its own aspect/project/topic/article, even though it will be integral to the wiki...?
[edit]
Aliases: Information management system, Content management system, Thoughts database, Thought organizer, CMS, Wiki replacement, Ruby Wiki, Wrinkle
Information acquisition edit (Category edit) .
Information organization edit (Category edit)
Information management system edit (Category edit) .
Categories: Pages with an associated category | Wrinkle | Motivation | Wrinkle / Problems it attempts to solve | Change notifications | Software features | Wiki software | Wiki features | List of all citations | Articles that have aliases | Information acquisition | Information acquisition and organization | Information | Information management | Information organization | Information management system | Rails projects | Software problems | Organizing | Writing | MediaWiki | Organizing information | My software projects | Semantic web
