SlideWikiO

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Discussion of SlideWiki

Thank you Chris for adding the "challenging" Disadvantages part, giving me the opportunity to expand the argumentation:

Tight space ... From my earlier experience in programming Forth Blockpages, I learned to refactor early refactor often. There may be other peers who too experienced, that this means less work, than programming huge chunks for later refactoring.
Harder to refactor DocumentMode . When always using incremental refactoring (Wiki:MercilessRefactoring) on the slide page, there is nothing left in the OverflowPage but the history of discussion, where each author gets credit.
Pages will be too large .You won't believe it. The original Forth block pages had only 16 lines and refactoring worked (if you didn't use too much inline Assembler). Even peers with small monitors benefit from slide pages, because they need not scroll so much.
Pages will be very small. Here the same less-scrolling argument holds.

The initiating author opened this separate OverflowPage for discussion of the SlideWiki concept, at the same time giving a living example of the concept.

There are corresponding concepts:

current CMS systems routinely offer a news display, which show a collection of article introductions from which you can click to the complete article, typically through a "more..." link.
the MicroArticle? is a concept to have actual small units of thinking that are limited in size.
HyperCard was a system with a dedicated community build on this slide model.

One problem is that there is no given slide size with HTML. -- HelmutLeitner

Thank you Helmut,

you de-noised the page, by the smaller, more uniform and more familiar "more.." link to the OverflowPage.
Do you mean Micro Content Management systems like Bliki? It would be interesting to have MicroArticle? expanded.
I would love to find links to the meanwhile (hopefully) evolved Google:HyperCard dedicated community.

-- FridemarPache

<= SlideWiki

What's the advantage over a page with an appropriately-sized amount of DocumentMode at the top, and overflow further down? The only difference seems to me to be that the overflow is accessed via the scroll bar on one, and via a link (and then a scroll bar if long) on the other; they both have the text AboveTheFold. If all that's on the overflow page is a list of credits, I can see some point, but why not just a simple contributors list on the page? c.f. AttachedEgo

Alternatively, if the hidden-text idea is useful, why not take a leaf out of LiveJournal, and let the user mark text as hidden-by-default (lj-cuts)? This keeps all the related text together on one edit page, easing refactoring. -- ChrisPurcell

Hi Chris,

Document Mode Above The Fold, is indeed an option, however rarely seen. In my opinion it has not the self-enforcing magic of a slide. But as main advantages I see:
Speed
- Faster transfer of the shorter slides (this could be even conveniently accelerated by a Browser add-on, that preloads in advance all linked local slides in the client cache.)
- Faster reading the slides (including marked portions of text, that are [ DiiGo- ] annotated.)
Hidden Text. This reminds me on folding browser add-ons, like those realized in a Bliki, for Micro Content Management. -- FridemarPache

I submit that the simpler technological option — cuts — coupled with a CommunityExpectation would be just as effective as, and more flexible than, a hard-coded TwinWiki design. In general, the simpler and more flexible the better — you may find other page design patterns fall neatly out of a more flexible approach. -- ChrisPurcell