"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) .
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:
...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...
This project is still in the early planning stages.
In my case, this has as much to do with Category:Organizing and Writing as anything. I want something to:
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:
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:
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.
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...
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.
Wrinkle / Problems it attempts to solve edit
Why? Because it facilitates/promotes the following good things:
In MediaWiki, you can make lots of tiny objects ("articles"), but it doesn't work well... Why not?
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?
(Negative) side-effects of this design decision:
Positive implications:
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.
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.
— 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.
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.
In my current wiki, I attempt to solve this in the following less-than-ideal way:
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...
This means things like:
"Best guess" lists might contain:
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.
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.
Maybe have some easy, consistent way to link to any sort of object...?
<%= link_to Quote.find(13) %> <%= link_to Source.find(91) %>
Information management system / Sources
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.
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).
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.
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:
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:
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.
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:
On each page/article/section, I could (optionally) display a condensed revision history:
Sometimes I want the ability to explicitly tag a revision like I do with Subversion.
Why?
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:
Wiki features edit (Category edit)
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...)
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).
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?).
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:
In our case, we would have:
Why?
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
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).
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...
Queue additions for later synchronization to the master databas...
See also: Small pieces
Contrast with MediaWiki, where you have to:
Phase 1 plan: for pre-existing content:
Phase 1 plan: for new section:
Phase 2 plan:
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:
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:
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.
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.
It might give you one-click access to commonly-used headings/sections or other boilerplate text that makes sense for this type of page.
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:
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:
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:
Design details:
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]]
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)
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
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.
have a Hypothesis object/type to store the theories/hypotheses that I have. It would have a "certainty" attribute.
Include a full diff, of course.
— Tyler (2006-07-07 22:22)
"Aspect-oriented writing" (non-linear; branching); like aspect-oriented programming
Split out the writing-related stuff to its own aspect/project/topic/article, even though it will be integral to the wiki...?
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) .