|
Size: 3379
Comment:
|
Size: 4736
Comment: Don't make work for me.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 13: | Line 13: |
| . PriceBook | |
| Line 31: | Line 32: |
| * 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 creates data cruft that I need to somehow sort through lest it crop up. And I object to being saddled with that. |
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:
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 creates data cruft that I need to somehow sort through lest it crop up. And I object to being saddled with that.
