Differences between revisions 76 and 77
Revision 76 as of 2011-04-04 23:07:03
Size: 5650
Editor: BtTempleton
Comment:
Revision 77 as of 2011-04-04 23:08:43
Size: 5767
Editor: BtTempleton
Comment: PeriPeri link
Deletions are marked like this. Additions are marked like this.
Line 37: Line 37:
        * You might find ChrisPurcell's [[http://meatballwiki.org/wiki/PeriPeri|PeriPeri]] wiki engine interesting.

Being the wiki home of Steve Killen,

or

A place to collaborate in an arbitrary number of projects.

Greetings and welcome! I invite you to participate to whatever extent you feel comfortable in this experiment of mine. The About page will tell you what's going on, including how to edit.

-- SteveKillen

Admin to-do (requests taken here!)

  • Style footnotes
  • Linking to "tel:" URIs doesn't work. I think this could be fixed by changing the value of url_schemas, as described in HelpOnConfiguration

  • Can someone make a favicon? Here's a first attempt: BtTempleton/CalefactionFavicon.png

  • Fix your logo css -- ClintonEbadi

    • Inserting manual newlines to avoid covering page content with the logo is a sign of bad style ;) If you want to keep the logo floating into the content area you have a few options... (installing firebug makes it pretty easy to mess around with the css in the browser with immediate effect welcome to the future).

    • Add clear: left to either #page or #content. #page is uglier: the page border also moves below the logo. In either case there is some whitespace to the right of the logo.

    • Add clear: left to at least div.contents. This would solve the immediate issue of obscured TOC lines, but then what about e.g. the horizontal rule below a heading and other cases?

    • Add clear: left to #content div. I'm not sure what the overall effect of that would be, but it would make most things that need to clear around the image do so.

    • Another suggestion: Move the logo (and search box?) into the sidebar, something like CommunityWiki's layout.

  • 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 (last edited 2020-01-21 12:07:00 by SteveKillen)