Tags:
create new tag
, view all tags
The Request: use zone instead of web . In the wild web has nothing to do with organisation, and everything to with chaos. Using "zone" avoids the confusion of meanings in the term "web" while keeping system pages like ZoneHome and ZonePreferences at the end of the topic list.

Justification: Having web as the word describing TWiki's primary grouping mechanism is a bad idea. The word web, as it is used by TWiki, has a very specific meaning about how information is categorised. There is nothing wrong with that per se. The problem is that "in the wild" web has nothing to do with organisation, and everything to with chaos. It took me a great number of hours deploying to truly grok TWiki's version of the word. It will take much longer for me to educate my downstream users. There really should be another term used instead.

-- MattWilkie - 12 May 2002

Summary of discussion to date:

The discussion has been long (over a year) and very vigorous.

Nobody stood up to defend 'web' as the appropriate term except in the context of "it's too much work to change and there is a large user base already accustomed to the current usage". While this is not a "good" reason it is not one to be dismissed lightly.

    A TWiki Web is simply a collection of inter-related, interlinked Topics. Nothing more nothing less. If you took all the Topics in a Web and drew them on a whiteboard, and then put a link between Topics which reference the other, then very, very rapidly you'd have an image that resembles a spiders web of sorts. Different "zones"/etc doesn't convey the image of the interlinking aspect of TWiki (or wikis in general). They can be used as zones, channels, books, chapters, but they're first and foremost interlinked information. That's always been my understanding of the idea implicit in a "Web". Is this a justification ?

    -- MichaelSparks - 25 Jun 2003

While a number of people support 'zone' as a better label than web many alternatives have been put forward.

It was suggested that since the best term to use is very dependant on the specific use of the twiki deployment the web-label should be a variable (a preference) which can be set by the site administrator. No code to support this has been forthcoming to date.

There is a lot of overlap with related issues, chiefly: A topic is really a page as far as the rest of internet world things; TWiki should be twiki or Twiki; Local configuration and documentation belong somethere other than the TWiki web.

None of the CoreTeam participated in the discussion except MikeMannix who is no longer active.

I think it's pretty clear that consensus will not be reached. So for good or ill we are stuck with "web" as the primary category label for the forseeable future. In the words of SueBlake "At least 'web' is short. I'm going to tell users 'TWiki calls a project a web, but we can still refer to it as a project(web)' and be done with it. Life's too short."

-- MattWilkie - 23 Jun 2003


Everything beneath this line needs to be refactored, including a lot of it moved into other topics for more focussed discussion

web is bad nomenclature

In a startling amount of open discussion, your conclusion seems to be the consensus when it comes to the site=>web=>topic discussion. (In addition to the Web-web problem, the less-mentioned but likely quite as confusing is the TWiki site-web conflict. First, TWikiWeb went TWikiSite - site=>web better than web=>web - but a "site" is usually short for Web site, so that temp solution was only mildly better. There's also differing opinion on the use of topic instead of simply, page. But _site=>____=>topic would seem to solve it all. See TWikiGlossary - in comments for much on that, also, WikiTopic for the another part.

-- Main.MikeMannix - 12 May 2002

I hope that it is not suggested by the above to remove the feature of separating a Site into subunits (now termed "web"). I have no problem with a name change (I agree that there is a confusion as web is generally a very broad term not one that indicates an organized sub unit) but I would not want to give up the capability of dividing a site into smaller, but connectable pieces.

  • I was only referring to the name, not the function. -- MattWilkie 13 May 2002

-- ThomasWeigert - 12 May 2002

In TWikiSetUpTroubles MikeMannix suggests using zone instead of web . I'll have to think on it but I think this would work (and still keeps "system" pages like ZoneHome and ZonePreferences at the end of the topic list!)

-- MattWilkie - 14 May 2002

-- MattWilkie - 04 Jul 2002

I believe that with current internet nomenclature, the word Channel might be a bit more wired-esque. I know many management types like that word (especially in marketing & sales.. everything's a channel..)

-- TWikiGuest - 07 Jul 2002 (jcline at ieee.org) (Any reason you don't log in? - MC) (Tangent: Top three reasons I have not wanted to log in since Sept 2001: 1. my prefered login name, JCline, is not a wikiword. 2. my prefered login name, JCline, is not a wikiword. 3. my prefered login name, JCline, is not a wikiword. However, given these three (highly different as you can see) problems can't be resolved since usernames are defined to be wikiwords and wikiwords are not apt to be redefined just for me, I have finally logged in. -JC)

-- JonathanCline - 08 Jul 2002

Small pseudonym table for possible word replacement of 'web'. It has bugged me a while also. Not like I'm a dictionary or anything but this is what it brings to mind. many other infobases have used these in the past.. (I'll admit I don't like 'zone' much.)

possible replacement meaning or fuzzy feeling
zone geographical area, physical place artificially demarcated?
channel place where flow occurs, can be selected and contains content
trail kind of like a thread, a path of navigation, or "paper trail"
shelf small place where things are stored, like a bookshelf
room large place where people meet, like "chat room"
thread usually associated with messages..
directory builds on other knowledge of user (rhk)
folder builds on other knowledge of user (rhk)
path just trying to brainstorm (rhk)
area just trying to brainstorm (rhk)
project just trying to brainstorm (rhk) -- limited applicability
chapter builds on other knowledge of user -- fits well with "page" in place of "topic" (rhk)
book builds on other knowledge of user -- fits well with "page" in place of "topic" (rhk)
ring a circle of knowledge, stacked or interwoven? brings to mind "web ring"
chain somewhat like ring, but linked together
add yours to second table below --  

I named several things on my wiki to get more of a library feel.

-- JonathanCline - 08 Jul 2002

IMHO, a topic should be called a (web) page, and that goes hand in hand with this discussion. Once you call a topic a page, folder or directory seem more applicable (they fit together with page in a fairly well known "idiom" (well, "file" fits better than "page", but "page" fits better than "topic"). What goes together with "topic"?

Hmm, after I wrote some of the above, I added chapter and book to the list of "possible replacements". I like folder or directory better, but I can imagine some people might like chapter or book. One drawbook of chapter and book are that they usually are not applied to a hierarchical situation. (You don't see chapters within chapters within chapters -- folder and directory do have a hierarchical connotation.)

Actually, I think the ideal (t)wiki engine will allow easy administrator configuration of a few things including:

  • choice of user visible names for "web" and "topic"
  • OT -- prohibition of WikiWords -- all linking by square bracket syntax
  • OT -- leading to:
    • preservation of spaces in topic names in all situations
    • legality of lower case leading characters for links

And way OT -- it would be nice to have an import function that automatically escapes things like < when you "cut and paste" text into twiki. (Of course, there would probably have to be a means to disable it.)

-- (rhk) RandyKramer - 09 Jul 2002

I kind of like the "folder" approach, esp. when dealing with HierarchicallyNestedTwikiWebs. It's a more widely understood data management concept (Mac and Windows both use this). Folders are also known for containing all sorts of stuff, like Movies, Images, Documents, and (believe it or not) Discussions (See LiveLink), so people wouldn't be very suprised to find Topics in them. I don't necessarily have a problem with "topic", as it is a better description of original intent, implying a "topic for discussion".

-- PeterNixon - 09 Jul 2002

Any word which requires more syllables to express the same concept is, in my opinion, inherently more complicated than a word requiring less syllables or letters for its expression. Therefore, I would immediately rule out the following choices mentioned before: "channel", "directory", "folder", "area", "project", "chapter". Personally, the only problem I see with sticking with "web" is that fact that it's already taken. smile I like "Zone" because it puts it at the bottom of an alphabetically ordered list. "Zone" -> "Page" is what I'd pick.

Why not just make the name configurable? wink

-- TomKagan - 09 Jul 2002

Why not just make the name configurable?

I think elsewhere someone noted that most TWiki's tend to be used in their default install form (including myself). So at least the default would have to be the best choice.

Perhaps the best answer will come from a tech writer or content person (the audience), not a developer. Developers make choices based on if the word alphabetizes easily or has fewer letters.. which may or may not be the correct criteria to judge a solution by.

Off topic, the "ZoneHome" replacement reminds me of the famous quote from E.T...

-- JonathanCline - 09 Jul 2002

Just curious, are folks also considering changing all variables containing "WEB" to whatever it is we decide to call it, to finalize the semantics? This can also be configurable (administrator can set it to ZONE, FOLDER, or whatever, in the TWiki.cfg file, and TWiki.pm can be altered to use what's in the config file). The only problem the administrator will have is making sure all instances of WEB (or whatever TWiki is shipped with) are replaced with their favorite in all the templates, topics, and code... or, the default could just be dealt with in TWiki.pm, along with whatever the administrator chooses.

-- PeterNixon - 10 Jul 2002

That is my hope -- I'd like to have a TWiki with consistent terminology throughout. Maybe that would require that a short sed script be included to make the necessary changes. (Aside: Do Windows installations all require Cygwin (so that sed would work)?)

-- RandyKramer - 10 Jul 2002

Off topic, the "ZoneHome" replacement reminds me of the famous quote from E.T...

True. But, if I ran the zoo, I'd name it "ZoneTop." Personally, I wouldn't use "Home" for the same reason I wouldn't use "Web" - It's already taken. "Home" has enough of a connotation to mean only one single page at an entire website: the home page. There's only one "home" page at a website.

[ TomKagan 10 Jul 2002 ]

The terms "web" and "topic" have bugged me from day 1. And my users where thorougly confused by TWiki's wording. So my vote goes for:

  • "page" because for Joe and me it just is a "web page".
  • "area", maybe "zone"
  • decidedly against "folder" or "directory", because I automagically think directory hierarchy. And one big pluses of TWiki, hmmm, "areas" or "zones" is, that you can re-arrange your logical hierarchy without touching the physical hierarchy. There's always just one directory under the hood - and in the URL.
  • "top" because for Joe and me a homepage looks like http://www.home.pg

-- PeterKlausner - 10 Jul 2002

My new favorite to replace WebHome is Start.

New table for the complete deal.

The nice thing is that the site level token (i.e. TWiki) is already user definable.

Web Level Page Level First Page Pros Cons
Web Topic WebHome current implementation, Web implies linked threads Web is a generic term, so can be confusing when talked about. WebHome and other Web* like names poluute the namespace of topics, clashing with things the user might talk about that start with the word Web.
TopicGroup Topic TopicHome consistant in terminology, perhaps aligned with diff. topic / web TopicHome suffers same problem as WebHome, TopicGroup could be confused with a group of people that discuss a topic
WikiWeb WikiTopic WikiHome Generic, unambiguous We would probably never get around to altering the terms. (Say Wiki, or worse, tweeky to the IT department and see how far support for the tool goes; it would be preferable to have an enterprise-friendly convention. -JC)
Original list (please update empty cells as you like):      
Zone Topic ZoneHome physical area (and ET's favorite?)  
Zone Topic Top physical area kind of? is not confined to meanings of geography Good point: "Topics can be, and usually are, comprised of more than one page."
Zone Page FirstPage the "call a page a page" opinion, alphabetically last  
Area Page Top area has less geographic connotation than zone, alphabetically first  
Channel Topic Start more media-stream related yech. I hate TV. There's no end user control, too many ads and lots of dreck to choose from while you're escaping them, etc.
Directory File Readme hmm sounds like dos 3.3 (is that a plus?) Physically it's a directory/folder. But clearly, you organize it very differently from a regular file hierarchy. This invites for false transfer + usage.
Folder File FirstFile file system, more mac'ish with 'folder'  
Book Chapter Introduction like a book? Does not fit conversation / thread use
Book Page Preface? sounds like a book to me.  
Cabinet File Folder like a office filing system What about attachments? In a way, this changes the meaning from "file" to "directory"...
Path Trail Entrance physically traversing a path..  
Project ?? ?   must be a manager thing. ha.
Group Thread Welcome kind of conversational sounding What about document mode? How distinguish the term TWikiGroups?
Chain Ring FirstLink   ok bad pun sorry
Ring Link StartingLink   Pages have links, they aren't links. Ring???
Room Conversation Start chat system style Style matches only chat systems
Folder Page <later> (rhk)  
Chapter Page <later> (rhk) Assumes the "webs" are somehow related + ordered. They aren't (always)
Project Page <later> (rhk) Restricts context
* * Root ZoneRoot, WebRoot, FolderRoot, etc.  
Slash     'cause that's how you say "/" Way too techie!
    / Consistent parent path, consistent with other apache style index.htm behaviour Hacking, not just renaming necessary
    Index because it's an industry standard The apache term is not so common. The current WebIndex pages better match the non-webmaster meaning of "index".
  Page   Because a page is a page is a page ...  
Node       A texinfo node is ~ a page; definitely not a set of pages. A network node is one element, not a set elements. "web" ~ knot, point, terminal?
Set     Short Sounds too much like math!
Universe Space Thoughts this is akin to a mind-mapping scheme where different people would have their own mind mapping universes (which could link to others') 'space' is a bit ambiguous unless clearly defined by theme
Universe World Begin "go play in your own world," a co-worker once told me (meaning, go hack in your own directory, not mine.) smile  
Playground Sandbox Home has quite a nostalgic feel to it, eh?  
Theatre - -    
Arena - -    
Subject ? Page
? Subject Page
??? Add yours here ??        

-- JonathanCline - 10 Jul 2002 (bored at work, can you tell?)

Moreover I think that there may be validity in checking what the other Wikis call these things.

I don't have a massive problem with Web, at the end of the day unless we use some special characters (a proposal that I would object to) we always potentially clash with companies use of terms.

Perhaps the only way of avoiding this is to prefix everything with TWiki: TWikiWeb, TWikiTopic, TWikiHome. If we were being generic this would be WikiWeb, WikiTopic, WikiHome.

I think to have a useful conversation about the other terms it is useful to discuss nomenclamenture in terms of pros and cons rather than implications, and when someone brings up a criteria to go back and reevaluate the other options. -- MartinCleaver - 11 Jul 2002

Added a few options with <later> for First Page -- I hadn't thought much about that so far -- Home works for me, others might be OK. I don't (think I) have a problem with Home because each folder is in some sense a web site, especially when (for WikiLearn) I have folders like Linux, Perl, Python, Cpp, Oop, etc.

-- RandyKramer - 11 Jul 2002

Just my $0.02 here: I think the Zone/Page idea is best. Page is obvious, and Zone is better than Area because it's easy to say, it's a multilingual word, and it's last in the alphabet.

But the real point I want to make is against the wording TWiki-anything! "TWiki" is such a queer word and it's the only word that doesn't follow normal capitalization habits. "TWIKI", "twiki", Twiki. Select either one, and use it consistently in all names, codes, whatnot, but don't use the TWiki variation. Nobody understands why the "W" is capitalized, and it's definitely not a WikiWord. By the way, why don't you call it a TWikiWord?? Again, please be consistent throughout the system. Sometimes it's Wiki, sometimes TWiki, and sometimes twiki. Is it any wonder my users are getting confused?

COmments are very WElcome!

-- TorbenGB - 11 Jul 2002

Ok, thanks for the pro/con idea on the table, I should have done it that way originally.

Perhaps the only way of avoiding this is to prefix everything with TWiki: TWikiWeb, TWikiTopic, TWikiHome. If we were being generic this would be WikiWeb, WikiTopic, WikiHome.

One of the major problems in my attempt at TWiki on an intranet are written elsewhere.. I'll be concise: when I said it was called TWiki, everyone laughed (not in a good way). And explaining what wiki is? Um-- the bubble-hype dot-com-wired-world stuff ended in 2001. Managers want serious sounding (stuffy sounding?) products now.

Define who the audience is and then pick based on the audience.. In my case the audience is non-open-source-minded developers, managers, and field sales. Who are the primary mass users of TWiki?

-- JonathanCline - 11 Jul 2002

Whew. I never thought this would stir up such a vigorous dialog. : ) My thoughts so far:

  • TWiki - is a bad prefix because there is already confusion about what it is (the name of the software or the name of the site or ...), and what it means (it is a made up word). Adding more Twiki-prefixed pages is just going to increase the uncertainty. Same goes for Wiki.
  • Zone - does not confine itself to meanings of geography, ever been "in the zone, man!" ? http://www.dictionary.com/search?q=zone
  • the point about needing a single syllable word is a good one
  • Channel - yech. I hate TV. There's no end user control, too many ads and lots of dreck to choose from while you're escaping them, etc.
  • Room, Folder, Directory, Project, Cabinet, Ring - nope. Without getting analytical to figure out why, none of these "do it" for me.
  • Book, Chapter - could see it's usefulness for particular kinds of deployments, but not generally

  • Page or Topic? Single pages should be called pages. Topics can be, and usually are, comprised of more than one page.

    • On further reflection, a page can have many topics, as well as a topic having many pages. For example this 'page' has the topics: rename web to zone, use page instead of topic , system pages should all start with twiki, TWiki, Twiki or twiki?, among others. So in the final analysis I could live with either label to denote a single page - with preference to page. -- MattWilkie - 12 Jul 2002

Q: Why is a prefix necessary at all? Why not just have http://twiki.org/Codev/Home or /Plugins/Root or /Test/Top or just plain old /Support/ ?

A: The only real requirement, that I can see, is for WikiWord linking. But is this really a core necessity, given [ [bracket] ] linking?

A: Indeed, I've often argued for (and even implemented as the SingletonWikiWordPlugin) denotation of single word topics as .Word -- MartinCleaver - 12 Jul 2002

-- MattWilkie - 12 Jul 2002

Well, it's an important discussion to have; Good labels enable people to not think as hard about what information they're trying to find; it should be obvious to the customer what they can do next based on what he/she is looking at. See Don't Make Me Think by Steve Krug

For people who are used to looking at Microsoft-type shared directories or folders, Web should be Folder or Directory and Topic should be File or Page or something else.

For an audience comprised of unix users, the terms might be different. The point is that it should be obvious what these things are and what we can do with them at a first glance of the page; the names shouldn't be determined by their number of syllables or relative coolness or whether or not I had toast or waffles for breakfast.

How about Node instead of Web? It's cooler and its got only one syllable! wink .

-- PeterNixon - 12 Jul 2002

Messed a lot with the table above wink And come across this: Hide WebHome, or whatever is its name, from the URL and the parent path display. Much the same way Apache handles index.htm. Currently, the parent path often looks ugly. because it shows WebHome. Logically, it does not belong there.
-- PeterKlausner - 12 Jul 2002

Revised my earlier page/topic definition.

Node is the only alternative to Zone or Web proposed so far that I like. I still prefer Zone though smile

WRT to hiding WebHome (use / instead): I agree, but we still have WebIndex and WebTopicList. I suppose they would just become Codev/Index and Plugins/TopicList (or should that be Plugins/PageList?)

-- MattWilkie - 12 Jul 2002

I'm beginning to like the idea of deleting Web (and any prefix) from pages to make Index, Changes, Preferences, Statistics, etc. but note those are not wiki names (that does not bother me one bit). (I thought for a moment about prefixing them with what is currently known as the web name, to get things like CodevIndex, CodevChanges, etc. which could be OK, but is really totally unnecessary because the URL already includes the web name.

I'm still and expect to be forever stuck on calling them pages rather than topics. I could even imagine changing "web" to "topic" so we have a hierarchy of Topic / Pages, which even works hierarchicly -- Topic / (sub) Topic / (sub) Topic / ... / Pages.

In view of the hierarchical approach planned for wiki, we need to allow for a name which at least supports a hierarchy, like topic (above), folder, directory, web (?), zone (??).

I don't think we can choose a set of names that limits the levels in the hierarchy, like Book / Chapter / Page. (Which, I guess, could be extended to Book / Chapter / Section / SubSection / Page -- and in the other direction with Library / Room / Shelf / Book ... .) But, even though I don't expect to hierarchies with that many levels, it is messier and limiting.

I'd have to let node rattle around in my head for a while -- I immediately think of it as singular and don't usually call the headings in an outline a node. (I guess I might call the things in a tree diagram nodes.)

I still favor configurable names, including (now that it has been suggested) for the pages like Index, Changes, Preferences, Statistics, etc.

Just my (third or fourth?) $.02.

-- RandyKramer - 13 Jul 2002

Names are important things when forming people's first impressions. 'Web' clearly is confusing to some, and tends to mark TWiki as being somehow 'different' from normal experience. 'Web' already has a meaning, and TWiki is overloading it.

I'm not advocating this (I haven't decided what I think), but there is quite a lot of use of the term "Room" for the concept. (For example Lotus QuickPlace uses this metaphor.) Having a strong metaphor is good. TWiki as a location, a building with a Lobby, Wings, Floors, Hallways, Doors. This provides a lot more conceptual possibilities than "Zone", which is a very neutral term, and does not provide much to build on.

Of course, it's a matter of taste. I'm sure some people would find the "building" metaphor to be too cute for a proper business setting. Horses for Courses...

(Also, the term "chat room" brings along excess baggage.)

So, while not knowing what I think smile , I would suggest choosing a term that brings some sort of strong organizing metaphor with it.

-- DaveBoulton - 14 Jul 2002

A metaphor is good, when it helps you to do what you want (and what the system can do!) by using analogy. A metaphor is bad, when the analogy restricts your path of thinking to a subset of the system's capabilities. So what is the bonus of the room metaphor? Does it fit all purposes? TWiki "webs" maybe used for

  • Bulletin boards
  • Conversation - yes - rooms
  • Project documentation
  • Issue tracking
  • Books
  • System logbook
  • . . .
I doubt that "room" fits all these. A generic term better fits the diverse usage, like
Zone
common favorite, feels a bit hackerish to me, might be wrong
Area
my favorite
Directory
+ Folder: as mentioned above, these terms are not really generic any more. They make you think, you should organize your pages the way you organize regular files in regular dirs. You shouldn't!
Workspace
borrowed from Groove; the more I read it, the more I like it.

Ad node: as a foreign speaker, I cannot possibly know about all subtle meanings of words. But I do know 2 aereas (not zones, I guess), where the meaning is totally different from "web". (Yes, it's things in a tree [diagram].) The meanings map like this:

TWiki texinfo Network mgmt
topic node node
web document network
You can consider texinfo being Wiki's hypertext grandpa, so you shouldn't overload its terms.

Ad configurable terminology: I guess, sooner or later, you would topple over that much flexibility. Many places carry references to that term. You had to change them all to avoid further confusion. Actually, I'm afraid, we won't even get away from the "web"/"topic" terminology.
-- PeterKlausner - 15 Jul 2002

A Room is a space separated by partitions or walls. (Walls obscure vision and hearing. They create an information space).

I don't see any conflict with any of the usages you list. Conference rooms; Libraries; Lounges; Museums; Offices; Lobbies; Break rooms; Galleries; Attics; Board rooms; Theaters; File rooms; etc., etc. Rooms have a lot of uses, and there are a lot of descriptive words for them. It does not seem to be a restrictive analogy at all. The metaphor is to represent the Wiki as if it were a physical space.

I would really resist using something so nerdy as Node or Zone. Directory has too much of a legacy meaning (as does Web).

Workspace is also somewhat nerdy, and besides,I'm lazy and W-O-R-K-S-P-A-C-E is too may letters to type again and again. Terse is good.

Area is a fairly neutral term. There is no analogy advantage (or in Peter's eyes, disadvantage), but no strong legacy meaning either. It isn't NerdSpeak It would be a safe enough choice.

Even though it might not sound like it, I'm fairly agnostic about the choice. But it is important to think about, because once it is done, we are stuck with it pretty much forever.

-- DaveBoulton - 15 Jul 2002

It looks like we are stuck forever with web frown After my experience with page vs. topic, where page is (IMHO) obvious preference for most new users, I do not expect decision about renaming web any time soon, too.

I can understand that CoreTeam has more pressing worries, and they are lucky - TWiki is up and running, users accepted topic and web, and cannot be bothered to be retrained. What are supposed to do we newcomers? I suspect that one of reasons why TWiki failed to intrigue my users, is that my users did not get over initial frustration over unfamiliar concept of TWiki. page and web were small part of the problem, page templates other. All (and other) added together - and I am the lone Twiki user at my dept.

Maybe solution might be to create variables %TOPIC% and %WEB%, which you can set to your preferences. This can be expanded also in documentation. If created, I will be eager to edit all docs to accomodate it.

Yes, in my dreams... frown I am just so jealous and frustrated that someone's user accepted TWiki, and mine not...

Othet than that wink I prefer Zone. It is on the end of ZoneIndex, as Web... pages were.

I guess I'll just start using Zone and Page. Sue me wink

-- PeterMasiar - 16 Jul 2002

  • Nobody likes Web (I'm pretty sure I havn't seen anybody defending it, is that right?)
  • There is no candidate for replacement which everybody, or even most can agree, simply because the reasons for using Twiki vary greatly. It is a multipurpose tool.

Is this a fair characterization of the debate so far?

So then rather than the FeatureEnhancementRequest for this topic being 'Rename Web To Zone' should it be 'Turn Web Into A Variable' so that the administrator can easily change it to the moniker of their choice? (ditto for Topic2Page)

Is there another remedy which would better capture and resolve the core issues?

(Yes, I think there needs to be a theme setting (which also allows customization), which sets them all based on some pre-defined idea. This makes it much easier to install. i.e. suppose there were a set of five pre-configured choices to chose from, rather than the hardcoded(?) set now, Web, Topic, Page, WebHome. The individual words might be overridable, though not suggested, as it might change the meaning of the entire system. -- JonathanCline - 23 Jul 2002)

-- MattWilkie - 16 Jul 2002

An example of the use of "project", not by boring management types.

I'm setting up a TWiki as a teamwork tool, with a web for each project team. Team members come from diverse environments where all other proposed words like "node" and "area" have particular and diverse meanings. Some of them clutch to a very fragile but usable concept of a web page and couldn't handle two names for the same thing. The only new concept requiring invention of a new name is the grouping of web pages into what TWiki calls "webs".

TWiki presents only two new ideas (from the user's perspective, the one that matters): collections of web pages related to a specific project, and the web pages can be edited from within one's browser. Web pages should remain (web)pages, and the one common unambiguous term for a related set of them, is "project". Everyone immediately understands that term the same way, and they do not have to go off and crunch through their own imagination of some tissy metaphor which always makes more sense to the designer than the users.

Although project/page/projecthome is ideal for us, indeed the only naming that would make sense for us, as indicated by comments above it is the least happy choice of most other sites, for some very good reasons.

So you see, unless these names are fully configurable, few people will be advantaged by a change.

The term "topic" for a web page is going to create the most confusion for us. I mean, it looks feels smells like a web page, and it can contain topics within it. And why doesn't "change the topic" mean rename the web page? :-). Other sites might not have this difficutly.

At least "web" is short. I'm going to tell them "TWiki calls a project a web, but we can still refer to it as a project(web)" and be done with it. Life's too short.

-- SueBlake - 16 Jul 2002

Added some odd ones off the top of my head to the original table: universe, space, playground, sandbox..

-- JonathanCline - 23 Jul 2002

I vote Area, Topic, I don't care what the home page is.

This goes from the generic to the specific. Sometimes Topics logically have multiple pages, but are we aiming at more generic to specific, or something else? Perhaps then we are going from an axis of generality to an axis of sequence, reminding me of efforts like the NavPlugin.

Practically speaking, I don't think we are ever going to get around to changing the terminology, I would rather we concentrated on the architecture.

-- MartinCleaver - 28 Jul 2002

I know nobody cares to rename web, but still... I like room as a place to meet and have discussion (in pages). One syllable only, and has this roomy feeling - lot of pages will fit in. wink

-- PeterMasiar - 10 Sep 2002

ZoneHome, that has a ring to it. I have to continually trip over explaining the idea of a TWiki Web to users. It's very confusing to them. I noticed Peter Thoeny never weighed in here unless I missed something.

-- GrantBow - 14 Jan 2003

A few things:

  • Added a few (partial) variations to the table using the word "subject" -- not sure it sounds good even to me, but I thought it might spark some other thoughts. (I think someone did suggest "subject" but I didn't notice it in the table.)

  • I support (willing to vote for) the idea of making the names variables. Probably can't help with code anytime soon, but like someone else above, I'd be willing to help convert the documentation.

-- RandyKramer - 14 Jan 2003

Here's what I'd do:

  • Make Web and topic name variables, and refer to those variables everywhere in docs.
  • Keep WebPreferences, Web... topics the same...renaming topics when changing a variable is a pain. Alternatively, rename them to something constant. (I think the TWiki site admin should be able to handle a little terminology twisting.)
  • Keep *WEB* variables the same. Same point as above.
  • Add a variable %WEBHOMENAME% that represents the "home" topic of a Web, allowing that to get customized.

-- WalterMundt - 14 Jan 2003

If we're going to consider making these things variables, you may want to consider making the 'TWiki' web itself a variable. (Personally, I'd rather rename it to "Sys".) While we're at it, get the plugins on board. Some of them can't seem to make up their mind whether to store info under "TWiki" or "Plugins".

Since I'm on the subject, let's go hog-wild and make Twiki's guest user account name a variable, too. My personal preference is to call that user the same name as most other wikis do: AnonymousCoward. smile

-- TomKagan - 14 Jan 2003

Hmm, now that we can create webs with a script in Beijing, maybe we can dynamically assign the names when creating special "template webs" for what is now Main and TWiki! For a particular site, once the names are set it gets very hard to change since people hard code them all the time in topics they write.

I think we can also make a distinction between code (and Variable names) and the names as they are used for content and displayed to users. It would be cleanest (but a whole lot of work) to make the Change universal since users often start getting into advanced features over time. Yet the consistency that currently exists has value, but again I think the choice of "Web" in the beginning has caused confusion. I'll need to re-read the above comments more closely. There are many good points made above.

This is a tough issue because so many things depend on this one name and the consistency of use is important in different contexts. Jeff Conklin would call this a "wicked problem." Whatever is decided to do, following through and organizing the work will be key to success. The whole idea of a rename of this scale shakes the foundation of the development to date. Naming is important to human beings.

-- GrantBow - 15 Jan 2003

Finaly I might see some changes in this bad naming! wink Because Grant is right, Naming is important to human beings.

Users spent most of the time on other websites. We cannot expect that users will bother to read what we decided to call web. They know what web means to them. If our usage of common terms does not match their expectations, one click - and they are gone -- possibly forever. Or, on intranet, they will decide "this is too confusing to bother to learn it" - and will not contribute.

Yes, it will be pain to change it. And yes, while doing it, we may bundle whole lot of other parametrizations. Good part is, lot of work can be done by Twiki users who are not guru coders, like me. Warning: there are many of Twiki users like me! wink

This big renaming might be simplified, if we decide that old name for things was misleading, and we just want to use new one consistently. Some users will need to be re-trained, but there is less parameters to maintain.

And of course, PeterThoeny is silently working on BeijingRelease instead of wasting time here wink , and until he will say, how far is he ready to parametrize Twiki, it's all talk only. frown

-- PeterMasiar - 15 Jan 2003

Good reading about wicked problems, Grant. But I do not agree that changing name of entity 'directory' from web to zone is wicked problem, as defined in a link above. We understand what ranaming takes, know when to stop, and can see consequences. Yes, it is pain, and many old Twiki deployments may argue that name of entity is not important, and is is too late to change it, and there are more urgent problems to fix, etc. And they are right in certain degree. But it is not wicked - it does not change while being solved.

-- PeterMasiar - 16 Jan 2003

Wait a second, I just realized the rest of the world calls a part of a website a "Section"!

-- GrantBow - 19 Jan 2003

We seem to have called the entire site the Twiki, and each of the webs are the "Bugs Twiki", the "Main Twiki" and the "Support Twiki". Topics seem mostly to be refered to as Pages. This seems to me to be a naming system that best re-uses the current WWW nomenclature.

-- SvenDowideit - 19 Jan 2003

Let's stay focused on what a Web should be called in this topic. RenameTopic exists for discussion about topic vs. page. Another separate idea is about local terminology used for an installation site's effecitve or colloquial naming.

Grant - you are wrong about RenameTopic - that was a discussion and spec for the refactoring tool that allows you to rename a topic (when you refactor your comment , remove this one smile --Sven

Oops - sorry about that. smile --Grant

-- GrantBow - 19 Jan 2003

I agree with Grant, but want to remind everybody of two other things that should be considered when considering what to call a web:

  • Hierarchical / multi-level webs
  • The bread crumb trail

Brief discussion:

Frankly, this is confusing and giving me a headache. Some of the links above and below may be as or more relevant to the other topic.

-- RandyKramer - 19 Jan 2003

Just a typo fix and reordering of one link.

-- RandyKramer - 20 Jan 2003

Below is a drawing of my own site. This is just the way I've set it up currently; I'm still looking for improvements, before I dump a bunch of content on it. Things that are clear for my application:

  • the default data set could be drastically improved.
  • the name TWiki sticks out everywhere; sometimes it should, sometimes it should not.
    • The two capital letters TW in TWiki are a very unfortunate accident.
  • The TWiki web needs to be split, to seperate docs from administration.
  • with the below setup, I'll label my current choice of terminology
  • if you developer types would like me to hack twiki-current, let me know as by now I'm tired of merging & remerging my tweaks & changes...

Drawing is not editable here (insufficient permission or read-only site)

-- JonathanCline - 09 May 2003

Thank you for sharing your sitemap. While I would use different web labels the functional divisions make a lot of sense, especially splitting twiki documentation from site administration. There doesn't seem to be much agreement on renaming web/zone/area/section (or turning it into a variable) but I think a consensus on splitting the docs from local site configuration will be much easier to achieve. As far as I know nobody is actually against the idea, it's just how to accomplish it. I know there are at least two different topics discussing this very idea but I can't remember where they are. Perhaps there should be a SplitDocsFromConfigs feature request.

-- MattWilkie - 09 May 2003

An alternative convention.

Drawing is not editable here (insufficient permission or read-only site)

-- JonathanCline - 10 May 2003

I am struggling with my upgrade from AthensRelease to BeijingRelease, and making it usable for my users. While in that, I decided to try to create better distro with BetterDefaults. Changes will include renaming topic to page, web to zone, user will go to User zone and Main will be for real main stuff, adding more skins, creating better newbie docs, and many more. Please join me to discuss what should go there!

-- PeterMasiar - 11 May 2003

While I prefer 'zone' for it's behaviour -- all sytem pages appear at the end of the list -- I also think the best semantic alternative with the least amount of unwanted associative meanings is 'section'.

-- MattWilkie - 23 Jun 2003

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdraw jc-site1.draw r5 r4 r3 r2 r1 manage 9.6 K 2003-05-09 - 08:03 JonathanCline  
GIFgif jc-site1.gif r5 r4 r3 r2 r1 manage 11.9 K 2003-05-09 - 08:03 JonathanCline  
Unknown file formatdraw jc-site2.draw r2 r1 manage 9.8 K 2003-05-10 - 20:11 JonathanCline  
GIFgif jc-site2.gif r2 r1 manage 6.5 K 2003-05-10 - 20:11 JonathanCline  
Edit | Attach | Watch | Print version | History: r55 < r54 < r53 < r52 < r51 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r55 - 2003-06-25 - MichaelSparks
 
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.