From

IbisWiki

Type

Question

Name

QzHowShouldAnIbisWikiBeImplemented

Text

How Should An IbisWiki Be Implemented?

Context:

QzHowShouldAnIbisWikiBeImplemented < - < YOU ARE HERE
IzEncodeNodeTypesInWikiNames
APzWikiNameEncodingIsUnambiguous
ACzWikiNameEncodingIsCryptic

-- RichMorin - 22 Aug 2000

I don't like too much the proliferation of very small pages that comes up from the Ibis idea, they are too static ... instead we could find "the right Wiki Way" to do Ibis.

I propose to introduce a simple tag to write SectionTitles inside a topic (e.g. H1..H6 html tags) such that the rendering rules collect automatically the at the beginning of the topic the index of the section titles that follows. (similarly to a mail digest in the mailing-lists world)

The index could be indented along some rule (Ibis rules or simpler) so that we could have a simple nice threaded discussion index.

-- AndreaSterbini - 23 Aug 2000

I understand the concern about too many little pieces, but I'd rather try to address it by some means which does not change the content nor the links. What would it take to give the user some viewing parameters to let her choose how far to go in dragging in small linked pages into this one as it is generated? This leaves the semantics of the links unchanged, I think.

I just stuck in the links as Context above, to make this clearer and easier to use.

-- DickKarpinski - 26 Aug 2000

Although I like the idea of giving the user some context, I am afraid of how theis would scale in a large wiki. It would be easy to use up too much space in each page on context information. Also, the maintenance headaches could become fierce (unless the links are maintained automagically :-).

One way to deal with the first issue would be to only give partial context (e.g., strongly-related links). FWIW, there is a reasonable way to do this automagically (written up in a paper several years ago about a "fish-eye" browser). You walk the tree in a "neighborhood" of the current node, counting each node transition. If you get too many transitions, you abandon that particular path. In a "family tree", this method might show ancestors, siblings, aunts, uncles, and cousins, but not more distant relatives...

-- RichMorin - 28 Aug 2000

Scaling. I think we should address scaling directly by letting the reader specify how much context to maintain in view on each page. That is the same sort of facility I would propose so that the too-many-tiny-pieces problem can be addressed. In effect, my idea would be to use a fish-eye view which can be customized to rank links for inclusion on both the depth and the type of links available to select the content of the generated page.

The page is going to be assembled, in general from templates and the results of one or more database inquiries. There is no noticeable cost for doing each page to the likes of its recipient. This may well include such tasks as loading up to three levels of specializing ideas at one time and at another time loading all the supporting (or all the refuting) arguments for a single idea.

What can obviously be automated is both the construction of such a page and a consistent visual appearance of the linking markers without regard to whether they refer to something on this page or not. Thus, I claim, the reader can have complete control over the size and content of the pages she's reading.

On the other hand, why am I writing this here? Shouldn't these remarks instead be in several linked notes as ideas and supporting arguments? Aha! A Question:

Qz How should text be put into an IBIS structure?
Iz Add markers to existing text in short form, like Qz.

ISz The reader can see them in her personal choice of form as specified in her viewing parameters.

ISz Let the writer choose her own marks which can be recognized once and converted to a standard form.

-- DickKarpinski - 28 Aug 2000

I discussed this briefly with an IBIS expert. His main concern was that since a Wiki allows any page to be extended, people won't make the links which make IBIS work. His approach, as I understand it, would be to replace the Edit button with a button for each kind of link to a new page which IBIS employs.

This triggered a different question for me. How can we make it easy for a subsequent reader to revise a single page into several that are IBIS linked together? If the wiki makes it easy to add information, then the IBIS wiki should make it easy to reformat a page into a proper IBIS hierarchy. When I get that clear in my head, I shall try to rerender these pages to conform.

-- DickKarpinski - 02 Sep 2000

I have a rather different TWiki-like IBIS InquiryTree proposal under active development as an idea.

-- DickKarpinski - 14 Sep 2000