Differences between revisions 1 and 2
Revision 1 as of 2011-04-06 15:27:08
Size: 41
Editor: SteveKillen
Comment:
Revision 2 as of 2011-04-06 15:31:48
Size: 3999
Editor: SteveKillen
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
<<TableOfContents>>
== Intertwingled Hypertexts ==
* Hierarchy is anti-wiki :( Is there some context in which you'd want to discuss a non-software-related "generic window manager"? If not, why the rename? Subpages may make sense for self-contained projects but they inhibit easy linking
  * There is no such thing as antiwiki except nonwiki. Categorizing it exposes the upstream trees to the user for easy viewing; is this not also a goal of wiki, of easily interrelating topics? Also, I guess I should reply to this comment on your user page instead of below if hierarchy is antiwiki :)
  * "Easily interrelating topics" requires easy linking which subpages break. I can no longer just smash words together and hope for a link to a relevant page; instead I have to make an explicit choice to make a link, remember which section the page was arbitrarily placed into (is GnuGo in Games or in Software?) and decide on the link text (since Section/SubSection/ActualPage isn't so good), and in the end I might as well be writing plain HTML. This problem was solved in 1996 with the category system -- for the GWM page, for instance, just add "CategorySoftware" to the bottom. Then looking at backlinks for CategorySoftware shows all software-related pages, and the page text can contain a manually-maintained index. (Some wikis define a special link type for category-membership links.) This provides a topic-based indexing system while conserving easy linking and permitting pages to belong to multiple topics. See [[http://c2.com/cgi/wiki?WikiCategories|WikiWiki:WikiCategories]].
 * Heaven forbid you should be required to put thought into the organization of a body of data. Or to search for a topic first before "smashing[ing] words together" to hope for a relevant link. The many-to-one/one-to-many argument holds some weight, though. Feel free to rename any pages you see fit.
  * That's exactly correct. It inhibits one's ability to easily create connections between disparate topics if the structure of the namespace is too complex. If I am writing about a concept which is pertinent to the mission of this wiki, I do want to be able to smash words together and have a fair chance of linking to the correct page if it exists. If it doesn't exist, I can always follow the link to create the page. I consider [[http://meatballwiki.org/wiki/AccidentalLinking|AccidentalLinking]] to be a feature, not a bug.
       * Except that you may not be the only person to formulate an idea for a page, and your idea may not take the same shape as that other person. So you may try to link to, e.g., ApplesAndBananas, but what if the other had already formulated it as BananasAndApples? There is merit in putting thought into data structures ahead of instantiation, and that's all I'm trying to say. AccidentalLinking is great and all, but encouraging users to link haphazardly without thought to the existing structure of the wiki creates cruft that I need to somehow sort through lest it crop up. And I object to being saddled with that.
       * I suppose I ''needn't'', actually. But all it does is shift the burden of work. The data still needs caring for. It's just a matter of which end the work is created on--the category side or the hierarchy side. I prefer to get my work overwith initially rather than leave it for someone else to clean up.
        * You're concerned that people will make links to the "wrong" page; I'm concerned that people will tend to omit useful links if linking is not very nearly effortless. I'm not arguing for thoughtlessness or disorganization. I'm only claiming that the affordances of Wiki's user interface make it uniquely suitable for deeply intertwingled hypertexts, and that it's silly to neglect those advantages in order to impose a strict page hierarchy for the sake of a tidier TitleIndex.
        * You might find ChrisPurcell's [[http://meatballwiki.org/wiki/PeriPeri|PeriPeri]] wiki engine interesting.

Discussions on the content of WikiHome.

Intertwingled Hypertexts

* Hierarchy is anti-wiki :( Is there some context in which you'd want to discuss a non-software-related "generic window manager"? If not, why the rename? Subpages may make sense for self-contained projects but they inhibit easy linking

  • There is no such thing as antiwiki except nonwiki. Categorizing it exposes the upstream trees to the user for easy viewing; is this not also a goal of wiki, of easily interrelating topics? Also, I guess I should reply to this comment on your user page instead of below if hierarchy is antiwiki :)

  • "Easily interrelating topics" requires easy linking which subpages break. I can no longer just smash words together and hope for a link to a relevant page; instead I have to make an explicit choice to make a link, remember which section the page was arbitrarily placed into (is GnuGo in Games or in Software?) and decide on the link text (since Section/SubSection/ActualPage isn't so good), and in the end I might as well be writing plain HTML. This problem was solved in 1996 with the category system -- for the GWM page, for instance, just add "CategorySoftware" to the bottom. Then looking at backlinks for CategorySoftware shows all software-related pages, and the page text can contain a manually-maintained index. (Some wikis define a special link type for category-membership links.) This provides a topic-based indexing system while conserving easy linking and permitting pages to belong to multiple topics. See WikiWiki:WikiCategories.

  • Heaven forbid you should be required to put thought into the organization of a body of data. Or to search for a topic first before "smashing[ing] words together" to hope for a relevant link. The many-to-one/one-to-many argument holds some weight, though. Feel free to rename any pages you see fit.
    • That's exactly correct. It inhibits one's ability to easily create connections between disparate topics if the structure of the namespace is too complex. If I am writing about a concept which is pertinent to the mission of this wiki, I do want to be able to smash words together and have a fair chance of linking to the correct page if it exists. If it doesn't exist, I can always follow the link to create the page. I consider AccidentalLinking to be a feature, not a bug.

      • Except that you may not be the only person to formulate an idea for a page, and your idea may not take the same shape as that other person. So you may try to link to, e.g., ApplesAndBananas, but what if the other had already formulated it as BananasAndApples? There is merit in putting thought into data structures ahead of instantiation, and that's all I'm trying to say. AccidentalLinking is great and all, but encouraging users to link haphazardly without thought to the existing structure of the wiki creates cruft that I need to somehow sort through lest it crop up. And I object to being saddled with that.

      • I suppose I needn't, actually. But all it does is shift the burden of work. The data still needs caring for. It's just a matter of which end the work is created on--the category side or the hierarchy side. I prefer to get my work overwith initially rather than leave it for someone else to clean up.

        • You're concerned that people will make links to the "wrong" page; I'm concerned that people will tend to omit useful links if linking is not very nearly effortless. I'm not arguing for thoughtlessness or disorganization. I'm only claiming that the affordances of Wiki's user interface make it uniquely suitable for deeply intertwingled hypertexts, and that it's silly to neglect those advantages in order to impose a strict page hierarchy for the sake of a tidier TitleIndex.

        • You might find ChrisPurcell's PeriPeri wiki engine interesting.

WikiHome/Discussion (last edited 2011-04-06 15:32:15 by SteveKillen)