Tags:
create new tag
view all tags

General need for naming standards

I think we need some TopicNamingStandards to lessen the chances of similar but differently named topics.

One of the Toronto PerlMongers commented to me once that there is "liberty in constraint", that is through having rules you free up people from dealing with uncertainty of what to call things.

These would be recommendations.

e.g. AllowMultipleForms, MultipleFormsPerTopic

See also http://c2.com/cgi/wiki?WikiNameAdvantages

-- MartinCleaver - 08 Dec 2003

Agreements

I think this is a very good idea. I believe that wiki's benefit from a gentle imposition of structure - just as a garden does. The standards are only guidelines anyway.

-- LynnwoodBrown - 01 Oct 2004

I don't think you can avoid similarly named topics. All you can do is deal with them when they occur, remembering that CoolURIsDontChange.

-- SamHasler - 02 Oct 2004

Well, yours is a classic example that renaming is inevitable.

-- MartinCleaver - 25 Oct 2004

Disagreements

Other

Isn't the imposition of naming standards a bit "unwiki"? After all, the idea is that, inspired to write a WikiWord into your text, there's a good chance it will AutomaticallyLink to another topic. An alternative might be to think in terms of synonyms; one topic title is synonymous with another. If someone spots synonymous topic titles, they tag one of the topics and an automatic 2-way link is established. Hey, I like that!

Note the first, italicised, sentence of http://c2.com/cgi/wiki?ChoosingWikiNames

See also: http://c2.com/cgi/wiki?WikiNameSynonyms

-- CrawfordCurrie - 13 Dec 2003

It seems to me that TopicNamingStandards is a facet of a couple of larger wiki-related questions I've been pondering of late. One is the broad question of how to gently encourage content organization to avoid the phenomena of WikiThickets. (BTW, this is exactly the problem inherent to hypertext systems that InformationMapping was designed to address.) TopicNamingStandards is one aspects of this.

The other question is where are WikiWord topic names really approapriate and where are they not. I know this may sound like wiki heresy but let me give an example. I have set up a quasi-weblog within my personal wiki and have found that I get tired of trying to come up with unique WikiWord titles for each weblog entry. Consequently, I'm leaning towards reworking it to use automatic naming (i.e. WebLog + time stamp). At the other end of the spectrum, the topics where WikiWords are best suited are key concepts that one might routinely insert in discussions. Another illustration of this dicotomy, IMHO, is provided right here on TWiki.org. In general WikiWord topic names work well for the content of Codev web but are less-than-ideal for the content in Support web. How many unique WikiWord topic names can you come up with for, say, installation problems? And yet you do want unique topics for individual help requests (I think). Again, I realize I fringing of WikiHeresy here but I think it's worth considering.

-- LynnwoodBrown - 01 Oct 2004

Just wanted to put in this reference as it's relevant to this discussion:
Microcontent: How to Write Headlines, Page Titles, and Subject Lines by Jakob Nielsen.

-- LynnwoodBrown - 12 Oct 2004

I think we need to install RedirectPlugin so that we can redirect similarly named topics.

-- SamHasler - 02 Oct 2004

This should be request on PleaseInstallPluginsAtTWikiDotOrg

-- MartinCleaver - 02 Oct 2004

Avoid naming topics containing the word "Of"

  • Avoid naming topics with "Of", e.g. AspectOfRegulation. Instead name this RegulationAspect. It pluralises naturally, is RegulationAspects instead of AspectsOfRegulation - TWiki would not autolink AspectsOf.. to AspectOf


Do you agree or disagree? Please select one of the radio buttons below and click the button.
I 1 - Strongly disagree   2 - Disagree   3 - am Neutral   4 - Agree   5 - Strongly Agree  


4 LynnwoodBrown 01 Oct 2004
4 MartinCleaver 01 Oct 2004

Agreements

Disagreements

Other

-- MartinCleaver - 01 Oct 2004

When referring to a known concept, use the whole topic name in the new topic.

  • If your topic is about the WebLeftBar, for example, your related conversation could be on WebLeftBarGraphicalIcons, or GraphicalIconsForWebLeftBar, but not GraphicEnhancedLeftWebBar
    • We should have tools that help with detecting possible matches - the user should not need to have knowledge about all topic names.
    • Can we make guidelines about the circumstances the drive the placement - e.g. suffix vs prefix?
    • Maybe this is what people are really aiming at: CommaSeparatedWikiWordRendering


Do you agree or disagree? Please select one of the radio buttons below and click the button.
I 1 - Strongly disagree   2 - Disagree   3 - am Neutral   4 - Agree   5 - Strongly Agree  


4 MartinCleaver 25 Oct 2004

Agreements

Disagreements

Other

-- MartinCleaver - 25 Oct 2004

Name in the singular

TWiki automatically links plural referrers (like TWikiForms) to singlar topics (TWikiForm) so there is little point making topics named in the plural. A reference of the singular TWikiForm, however, would not automatically link to plural name TWikiForms.

-- MartinCleaver - 02 Jan 2005

There are some other inconsistencies with the plural<->singular conversion.

  1. If you visit the singular url (type it in the address bar) you won't automatically be redirected to the plural topic name.
  2. the %INCLUDE% variable doesn't do the translation, but the error message it outputs does, causing confusion.
  3. Plural links as form field names do not link to the singular topic in edit mode. e.g. TWikiContributors on the new ChangeProposalForm

-- SamHasler - 07 Jan 2005

Edit | Attach | Watch | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r19 - 2005-01-07 - SamHasler
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.