Summary: Short intro added for this substantial topic. Main addition in a separated page.
> There are *many* ways to structure content *globally*. All of GlobalContentStructuringMethods can be relevant in wikis.
> There are only *few* ways to structure content *locally*, in a WikiPage.
> == From unstructured to structured information ==
There are many ways to structure content globally. All of GlobalContentStructuringMethods can be relevant in wikis.
There are only few ways to structure content locally, in a WikiPage?.
Amit Patel writes about the move from unstructured to structured information. He says he loved to start writing in an unstructured environment such as Google Wave, work, comment, threads – but at the very end it was hard to move towards a structured set of documents:
Alex commented on the page and said: As a wiki developer I’m interested in this how to move unstructured page content into a structure.
He came up with a few use-cases:
I started to think of things I use that are already somewhat there.
I wrote a front-end for a wiki that essentially collects bookmarks. Note the link to a bookmarklet and the source code at the bottom. Take a look at the actual wiki collecting all these links. Note how the links on its HomePage and the unordered lists on the linked pages define the outline that is shown by the add-link script. Note that the wiki can be told to reassemble all these top-level pages, too. (Look for the “All In One” page.)
What do you think—is this a way out of the impasse?
People keep saying “reworking is hard” (→ LackOfReworking, AttackTheDocumentMode). And it is. People don’t do it. But imagine people trying to “rework” a conversation they’re having. Nobody does this! People sometimes “rework” conversations when they record interviews and rework those into articles to publish. But it’s rare compared to the gazillion of other forms of communications we have.
Let’s think of some:
People will summarize – and selecting parts of a page and saving it under a new name supports that. There’s an unsolved problem, unfortunately. The summary doesn’t belong to the LinkLanguage, since the old, messy page gets to keep the page name. Perhaps our support for summarizing should move the current page to the discussion page and just keep the summary.
People will reorder information – and moving pages to nodes on an outline supports that. The page itself remains untouched, of course. All we’re doing is putting a link into the appropriate nested list.
People will categorize
People will subscribe (or “follow”, or mark in some way to stay abreast)
People will share in a broadcasting way (think of “retweeting” etc).
In WikiPedia, refactoring can be frequent, especially on pages where many people want to control the narrative. Or. where rules tend to dictate a structure. WikiPedia appears to be a rare exception among wiki sites, however.
Why does it happen? Why is refactoring not common in wikis?
Do people see the activity as a “defecting” in cooperation dynamics? (meaning, do people see refactoring your work as a non-cooperative activity, and leaving your contribution/“voice” intact as a cooperative approach?). Do people need permission to change contents of wikis, in order to feel “ok” doing it?
Is there a way to set a recurring example, where at least 3 or more people consistently refactor as a primary activity?
OrganicStructures links to tools that help make transitions from unstructured texts to structured texts. These tools usually go beyond simple wikis.
Sam, these are just my quick thoughts, because I’m racing out the door at this very moment:
One part of the public conversation these days (it’s 2012 now,) and has been for a couple years now, is the focus on curating of content, which it would be nice to include somewhere in our network of pages now.
A novel idea in this page is the focus on exporting content from the unstructured forum to a structured forum. A page for that would be nice.
I invite you to disassemble this page? Or perhaps let me do it? I would made StructuredFromUnstructured?, copy that idea to there, and then work in links to these other pages (LackOfReworking, TechnicalSupportForReworking…) I would include an anchor section in StructuredFromUnstructured? that is titled StructureExportTool?.
If you don’t have time for it, would you grant me permission to do this?
So good to see you here!
Also – perhaps something about looking at the types of refactoring maneuvers that are performed.
I absolutely wanted a place to write about moving text from an unstructured format to a structured format – I wanted to claim the LackOfReworking is a problem ordinary people don’t have because you never rework a conversation, and where as you might rework an article or a presentation in order to improve it, most of our interactions with text involve organizing it, labeling it, ordering it, summarizing it – and wikis tend to have absolutely no support for those kinds of tasks.
How about this: do just that and have the result on a new page and we’ll develop the idea as we use it.
Ok, LionKimbro will come back and dedicate time to this page. Incidentally, I am also adding a feature to the new version of SocialMediaClassroom that will allow users to push replies from discussion forum into a wiki page (or eventually a real time editor) and refactor it into a wiki page. It’s an experiment at this point, but we think it could be useful and I’ve not seen it done very much in the past.
Okay, I’ll move parts of the page out, and organize the ideas of StructuredFromUnstructured?.
Alex, are you saying that you are interested in exploring how a wiki can support organizing, labeling, ordering, and summarizing pages more specifically? Maybe: OrganizingPages?, which is subtly different than (or a specific kind of) reworking pages.
Nope, nope; I take it all back. I’ve spent more time with this page, and it’s reshaping my mind.
I’m really impressed by Alex’s link store thing. I’ve been wanting something like what he’s created for a long time. What I think is really valuable here is that the link is contextualized – the best “search” is no search, because the information you need is “right there.” That’s what organizing stuff lets us do.
I’m moved by the observation that people don’t “rework” conversations, but that they do summarize them, categories them, etc., etc.,.
Perhaps the idea that is shining to me here is this: reworking is not the objective. However, there is some kind of manipulation of the artifacts that is valuable. It’s just not “reworking,” as we have conceived it.
For the sake of completeness: “What is the reworking that we are not convinced is valuable?”
Getting more specific about what we mean by reworking seems pretty valuable to me.
Let me start with my existing example.
Some authors of books or screenplays will start with an outline and a bunch of notes. Now they want to assemble them into a timeline. The Links to Wisdom example starts with the outline of an existing book, allows users to extend this outline by editing wiki pages and add annotated links (0-5 stars) to the outline. Now, how might we extend this without overengineering it?
Flexible link outlines: Yes, it’s very limited, but links are the backbone of the Internet – thus, if every page on a wiki could potentially be an outline, and there’s a frontend where you could submit a link (a bookmarklet taking the current page you’re looking at), presents you with a list of outlines on the wiki (all pages tagged outline), the presents you with the outline itself (built by extracting the unnumbered list from the outline start page and (recursively?) includes all the pages linked from it), a comment field (using wiki markup to be added to the list item), and saves it.
Manipulating the outline: Perhaps we want an easy interface to delete, copy, and move (copy & delete) nodes around. To initiate it, click something, which starts a process like the one above, but based on the link you’re pointing at). This would allow you to copy and move it to different outlines or to different branches.
Reordering items: Also important: moving elements up and down in the hierarchy. At first, this can be done by page editing, but later it would be nice to have user interface support.
Local pages instead of links: Once this works for links, why not do it for local pages as well? When looking at the outline, you should be able to inline the linked page. Much like you can inline the comment pages on my blog. The comment appears in a div that is invisible with a link that does nothing but toggle the div’s visibility. Maybe these pages need to be loaded on request because these outlines might be big.
The above is a pragmatic approach to assembling wiki pages. Once these outlines exist, they can be used to improve navigation on the individual pages (as these remain useful wiki pages in their own right). We can generate previous and next linkes, up links and a table of contents for child nodes.
Perhaps this will reduce the feeling many people have when they visit a wiki. It’s a mess.
As for other things. Here are some more ideas.
Some tricky ideas:
Ted Nelson’s idea of TransClusion. Yes, it’s cool. Oddmuse provides the
include tag with which to do it, but I rarely see it used. I use it quite a bit when building dedicated wikis (eg. on my RPG sites). Perhaps if a better, more obvious interfaces existed? Click inline another page here, get a list of all the pages of the wiki (something akin to Self:action=index including the filtering, but maybe with a live preview? Have the HTML be inlined automatically via jquery. Click save and the appropriate include tag is inserted into the wiki source text. Every included text should also include a little floating bubble or icon that you can click in order to visit the source page inlined here or to remove the page being inlined here. What about recursive inlining? Maybe postpone a solution to this problem until we get the first step right.
Layout: If we were really awesome CSS hackers, we might offer the ability to transclude pages into floating pieces of text: sidebars, post-it notes, that kind of thing. Again, without users having to edit the page themselves. The CSS would include a number of ready made layout ideas such as “width 20em, float right, background-color yellow” and the like. Maybe also work with rotation, backgrounding and foregrounding like some of the pinboard web applications out there. Look at what this guy did on a generic Oddmuse WikiFarm?: post-it effects.
Well, you all know I like building things when it comes to wikis. Do you think I should build something from the above list? Do you have other features you’d love to see? (Do any of you even use Oddmuse? I think only Mattis does, but who knows.) Do you have other ideas for how people work with text that doesn’t fall into the wiki “refactoring” meme which I’m trying to replace?
For the record, I use OddMuse a LOT!! UI think I’m now running at least a dozen different instances.
Yes, probably. “Jemandem das Wort im Munde umdrehen” a German idiom = ~ to turn somebody’s word around while it’s still in his mouth.
There is something sacred about every original conversation in written text. Printed interviews are often reworked conversations but every journalist does keep the original recording tapes for good reason. It might be the fear to destroy the original conversation - the fear to turn turn somebody’s word around while it’s still in his mouth - that keeps people from reworking conversations on wiki. Highlight, save to a new page, having an automatic link to the original, and rework without guilt-trip. Probably, yes.
Ok, I hear on you LionKimbro and AlexSchroeder on people not reworking/refactoring discussions. (Actually, in a learning context, they will do it if assigned to do it, but that is kind of beside the point).
I like the direction of the ideas Alex discusses above in regards to link storing, too. I like Alex’s idea of thinking of the actions that people will do, to think about how to improve the design of such a system. We were doing a crude version of this with “Culturing” for a couple of years http://holocene.cc/culturing/ . Then, we moved the activity into a mediawiki instance to try and turn it into a publication. In the end, there are actions that people are trying to “do”, and because the actions are not oftensupported very well by a given piece of software, people an lose sight of the desired actions in the face of what is possible with software. I wonder if it would be better to try things out with index cards, notebook, sticky notes, a white board, etc before moving to software. Moreover, putting the actions in context of problems people really care about should really make difference.
I agree for the most part, and would be interested in material world experiments. I’m going to think about how to create experiences/games for that kind of exploration.
Two features of SmallestFederatedWiki? are clearly focussed on refactoring :
The combination of which allows quick drag and drop refactoring from one page to another.
Until I saw these in action I would have dismissed them as nice-to-have rather than essential. But I’m finding them extremely useful. Suddenly wiki refactoring opportunities become more visible to me as I contemplate two pages side-by-side. And dragging paragraphs around lets you quickly play at different layouts.
After some experience of this, I’m won over : drag and drop refactoring between pages is an extremely important capability for wiki to be able to grow persistent, useful structure.
I registered on github and surfed around in the smallest federated wiki a bit having had the movement of entire paragraphs from one page to another in the same browser tab under my clicked mouse finger already. I agree, that’s it. Is there any sand-box or even a wiki-hive for the smallest federated wiki to try it out without disturbing somebody? I watched all the videos on http://wardcunningham.github.com/ straight in a line btw, just as Ward recommends it. So do I.
SFW seems extremely powerful, still, so is the muse.
Let’s combine that.
@Mattis : by definition, your browser becomes a kind of sandbox for an sfw because any page you start editing on an existing SFW, unless you claimed the page, will be forked into local storage within your browser. (Assuming your browser has local storage)