create new tag
, view all tags
Simpler default templates needs to be created for a better out-of-the-box experience. The current template can be reassigned to ClassicTWikiSkin. (This needs to be documented so that power users can switch over to the classic skin)

Ideas/opinions on what should be included/omitted in the simplified templates?

  • TWiki webs list (Main | TWiki | Know | ...) :
    • PeterThoeny: Remove
    • RandyKramer: Remove
    • PeterMasiar: Keep. Maybe we can add some simple mechanism to remove it, like special TWikiPreferences SET value EMPTY on NONE or something. So you can multiple webs right out of the box, and if you don't, link is easy to disable.
    • LesOrchard: Keep.
    • JohnRouillard: Keep, but provide removal mechanism.
    • PeterMasiar: Another idea: can we have SELECT box for webs? So web list will not eat too much screen space... If we do, I'll propose to put it on the right-side of the web action list. Then, let's put topic name and topic actions below web actions. And if possible, expand spaces in topic name. Because this is done manually in most topics I've seen: to put Topic name as title again on top left part of the rendered page, below web action menu.
    • DougPhilips: Select boxes too cluttery, IMHO. I like this bit, it helps you feel like the site is connected, at a high level, no matter where you are.
    • JamesCollins: Keep. I agree with Doug. We have separate webs for different groups, but want it to remain easy for users to browse their peers' webs and feel that they're under a common umbrella.
    • LynnwoodBrown: Keep. Webs are fundamental to TWiki structual/navigational architecture. Need quick way to navigate BUT need to minimize space requirement as webs multiply. I support PeterMasiar 's suggestion of SELECT box but would call it JUMP TO.
    • PeterKlausner: Keep WIKIWEBLIST; pull in all text, so you don't have to fiddle with prefs + templates for major change like turning off; remove C-ish curly braces
    • ColasNahaboo: Keep functionality, but with a "standard" look (tabs a la amazon, or items in a column on the left). Now naive users do not realize they are "webs".
  • Web action list (Home | Changes | Index | ...) :
    • PeterThoeny: Keep
    • RandyKramer: Keep
    • PeterMasiar: Keep. But we may drop Home if web name will be a link in topic action - just above. I do not agree with LesOrchard's proposal below: [ Edit, Attach etc ] are Topic action and they should not be mixed with Web actions like ( Changes | Index ).
    • LesOrchard: Keep, add Edit, Attach, Printable since they're well used (at least in my group). Maybe turn topic title into link to Ref-by like UseModWiki does.
    • JohnRouillard: Keep
    • RandyKramer: (voting twice? wink Comment: IIUC, having edit at the bottom of the page provides the additional benefit of preventing loss of data if edit is pressed too soon -- if edit is moved to the top of the page, this potential problem should be addressed somehow. (Can the edit be rendered last even if it at the top of the page?) The problem I am concerned about definitely exists on some other wikis, IIRC, this includes WardsWiki. If you click the edit before the page is entirely loaded, you lose some of the text. (Or maybe I am mixed up, maybe it occurs when you press save too soon??)
    • DougPhilips: Keep.
    • LynnwoodBrown: Keep. Could we combine with web list JUMP TO drop-down? Perhaps have small font for Home, Changes, Index under each web.
    • PeterKlausner: Keep, do not repeat WebHome link, which should be in breadcrumb
    • ColasNahaboo: Keep, but visually like a "sublevel" of the webs

  • Bread crumb (as indicated in the RoundEdgeSkinExperiments) :
    • PeterThoeny: Add
    • RandyKramer: Not sure -- is the bread crumb the idea of showing <site> . <web> . <parent(s)> . <topic>? If we show all parents it could get long. I haven't reconciled in my mind when I'd want to use parents as opposed to a subweb. In the long term it would be nice if a web and a parent were indistinguishable. At that point I'd like to show the entire bread crumb.
    • PeterMasiar: If we have logo linking to Main.WebHome just left from %WIKITOOLNAME%, I guess we may drop it in textual link, so it will be just Web.TopicName. To make it simple, can we show parents in footer?
    • PeterKlausner: absolutely yes; people know that, people love that - in the header
    • ColasNahaboo: as a variation, I have put them as a vertical table on links in the left marging. But the current proposition is nice.

  • Topic action list (Edit | Attach | ...) :
    • PeterThoeny: Reduce to (Edit | Attach | Printable | More)
    • RandyKramer: Keep "| Diffs | r1.7 | > | r1.6 |", i.e., diffs, current version, diff to previous version, previous version. At the very minimum keep diffs. "Attach" can go AFAIC -- it's a special thing that should be done rarely by the "normal reader". (I use diff and > too often to have to switch to another page to use them.)
    • PeterMasiar: Reduce to (Edit | Print | More). Attach is complicated action, requiring menu. [ More ] page can have two sections: "simple actions" like Attach, view raw (current version), and "advanced actions", so simple users will avoid even readig it smile . And because Topic action is so short, it could be placed right after Topic name. So we will have all actions (Topic, Web, and Site) in one area: on the top of the page.
    • PeterMasiar: Update: Misunderstanding here. My proposal for Topic Action menu is:
      1. place Topic menu at the top of the page (right after Topic Name, where text (edit) resides in edit mode), not at bottom. Goal is, to have all action (Site, Web, and Topic) in one area - at the top, where all users get used to expect menu to be.
      2. Topic menu should have only simple no-brain one-click actions: [ Edit Print More ] and possibly Diff, and rest will be in More page.
      3. More page will have two sections: Standard actions [ Diff, Attach, ViewRaw, Ref-By ] and advanced actions: view particular version, and current More actions.
    • So there are no actions on bottom of view page. Really, newbie users are scared of too many commands which they do not want to learn, use and understand, and of too many places to look for these commands. Classic TWiki interface is clearly aimed at power users (most commands are right on the surface). As a result, newbie user percieve Twiki as complicated -- when we all know it is simply powerfull smile . More than one user complained to me about that.
    • My proposed solution is to hide more advanced options (one click away) to insure painless out-of-the-box experience for newbies from default distribution templates. Newbies do not want to learn one more web publishing tool. They want easy way to edit simple pages, and learn more when they feel so.
    • LesOrchard: Move most common options to the top, leave lesser used options on the bottom or behind an "advanced options" link or some such.
    • JohnRouillard: I like LesOrchard's suggestion. Print, Edit, Attach File, at top, but not mixed in with web action list. Maybe web actions on left, topic actions on right. Put Ref-by, Difference options, More at bottom.
    • DougPhilips: Simplify, but I'm not wedded to which way. wink
    • LynnwoodBrown: Keep and move to top. It's annoying to have to scroll down long topic to get to Edit. Propose drop-down menu with options. This would allow interface to remain the same for listing basic actions versus more complex. Advanced settings would simply offer more options in drop down. Another option would be to have Edit and Printable only and then a drop-down menu for More... that includes additional basic or advanced options, depending on user-level setting. I never liked having to go to another page for More options. Perhaps have topic specific preferences for including certain actions. In this way, something like Attach could be included only for topics where such action is likely to be appropriate.
    • PeterKlausner: Keep in footer, shorten, remove C-ish curly braces
    • ColasNahaboo In KoalaSkin I have put the common ones in the header (Home Edit Attach Sitemape Help), and put the whole list in the footer: Edit Attach Refby Printableview Rawview Diffs Help More...

PeterThoeny: One idea is to make Topic Action more graphical, e.g. to have icons for some functions like Edit, Attach, Printable etc.

  • RandyKramer: Icons are something I want to avoid -- I want a minimum bandwidth template. I envision only one icon per page, except perhaps the first pages where I need to display the SourceForge logo.
  • PeterMasiar: Icons, right after Topic name -- I like it! They are cached, no bandwidth implications, IMHO.
  • JohnRouillard: As a per web settable option proide graphics, but provide alt text for it so I can use links, or lynx as a browser.
  • DougPhilips: Definitely alt text. I have many blind friends who are shut out of the web enough as it is by fsck'in image maps, ad nauseousness. 1/2 wink
  • ColasNahaboo I have put icon + text in the header for KoalaSkin, but it is optional for low-bandwidth sites

It is common practice to use HTML tables for layout purposes. To avoid trouble with clipped text on the right side I do not recommend to place the main topic TEXT in a table cell. This has been discussed in BetterHtmlTableLayout.

  • RandyKramer: I agree. I put my main topic TEXT in a div where I set the width to 90% -- for me it makes it much easier to read as my eyes take in the whole line at once -- less eye movement. We could make the width a user settable variable.

  • JohnRouillard: Also text in a table cell can't be rendered untill the entire table is done, so I would agree that the main text should be kept out of the cell.
  • ColasNahaboo: I used tables for KoalaSkin, why?
    • most users are used to margins, and they feel more confortable with them
    • reading too long lines is stressful for the eye, hence the multicolumn use in newspapers
    • table cell can't be rendered untill the entire table is done, avoiding bugs of people clicking edit or save before the page is fully loaded

Brainstorming is open!

-- PeterThoeny - 28 Jan 2002

I suggest looking again at the MikebSkin. This skin presents the main functions of TWiki right at the top using icons & text. They are: Edit, Attach, Printable. The "Ref-by" could be removed. A More button/text could be added. These icons are at the top because people often look up towards toolbars and menus to perform a function. At the bottom, I left things like versions, etc.

For this skin, I would remove the left-hand navigation frame to get the TEXT out of the table.

-- MikeBarton - 30 Jan 2002

I collected here my proposals from above. Sorry my graphic design skills are not good enough to present my idea in real graphics, but I hope ASCII graphics will give you an idea what I am aiming for.

I propose to have all actions gathered on only 2 lines (colored by Web color). So no actions on footer.

  • 1st line will have web actions on the left, and SELECT box with list of webs on the right.
  • 2nd line will have web name (linking to WebHome) and topic name (with increased font), and right after basic topic actions ( Edit, Print, Diff, More). Rest of the actions will be on More page. No parent topics either: leave it to footer.

|.Company.|..{Web Action menu:} Index Changes Search Go ] ........... Web: [select] [Go]
|.logo....|..Web . Topic Name {Topic action: Edit Print Diff More} ........[User][TWiki]

08 Mar 2002: I implemented my proposal, see more details here. Because I do not have SELECT pop-up for webs, I used WIKIWEBLIST variable as classic template. PeterMasiar.

Company logo in top left corner can link to Main=TWIKITOOLNAME web, and we can drop TWIKITOOLNAME completely - it will be only as graphic logo, and in "Main" web as webname.

I also propose to drop required TWiki logo on such prominent place where company logo and TWIKITOOLNAME is expected. Instead, on the right side of 2nd line might be small logo [powered by TWiki], pointing to TWiki web, with nice big TWiki logo in TWiki web.

If we can decide that users deserve own web, we can have graphic button [human head] pointing to user's own UserName topic. And we can remove TWiki and User webs from web SELECT list in first line, so only user-defined webs and Sandbox will be there.

Then, if we will call Main web (now without users) same name as WIKITOOLNAME, all pieces (IMveryHO) will fit together.

Now I can feell PeterThoeny will miss all this TWiki logos, but most of them are installed behind the firewall anyway, invisible to him... smile

I can imagine that my proposed implementation will be big change, something users with long TWiki experience will need to get used to, but for newbie users I believe it will be substantially simpler to comprehend.

I'll try to create templates like I described and test-drive it on my colleagues: some are biologists with craving for plain simple GUI and very limited need for advanced features... smile

-- PeterMasiar - 31 Jan 2002

Added some votes above, but probably nothing that'll sway the outcome. wink

-- DougPhilips - 01 Feb 2002

I think giving a full layout with a rationale is better than collecting feature and voting on them. You can't judge a single feature, it's necessary to judge whether a set of features makes a consistent ensemble.

(Links are encoded

_like this_

.................................................................................. |===========|
_AreaName_ ...... [ _List_of_Webs_ _Search_All_Webs_ _More_Actions_ ] ............ | .Company. |
Web _WebName_ ... [ _List_of_Topics_ _Search_web_ _More_Actions_ ] ............... | ......... |
Topic _TopicName_ [ _Printable_View_ _Edit_Topic_ _Topic_Changes_ _More_Actions_ ] | ..logo... |
.................................................................................. |===========|


The bar should be repeated on the bottom of the page (helpful for long topics). The company logo should be omitted on the bottom (once is enough).

The TWiki logo should not be present everywhere. People will want to apply the corporate identity, the TWiki logo would just be annoying. (It should be prominent on the initial WebHome, and a smaller version for a Kudos page should be provided as well.)
(Take a look at the delivery state of Apache and the look of most Apache websites. I'd stick with that pattern, it doesn't leave much doubt who's powering the site without being obtrusive.)

The left area is the the Location area. It tells the user where he is.
The first line identifies the TWiki area of the site, because sites will often have non-TWiki areas and it's useful to give the TWiki area a name (e.g. "Speaker's Corner", "Contributions Area", "Customer Support", "Knowledge Base",

or whatever is appropriate for a specific site). If a site is TWiki-only, this could be the site name itself. Clicking the link should bring up the site's entry page (usually Main.WebHome).
The second line identifies the Web. Clicking on WebName should bring up the web's WebHome.
The third line identifies the topic. Clicking it will just return to the topic (useless in View, but helpful in Edit).

The middle area has the actions.
The first line is for area-wide actions (i.e. those that relate to the entire TWiki), the second for stuff that's related to the current web, the third for stuff that's related to the current topic.

should bring up the entire list of online webs (this is essentially the wiki webs table as already present on most WebHomes).
should bring up the search page with "Search all Webs" already activated by default.
should bring up a full list of actions that related to the entire TWiki (including Login/Logout, User management, Web creation and deletion, user management, global statistics, or whatever - this is just a list of things that could go here, I'm aware that most don't exist at this time smile ).
should bring up a list of all topics in the current Web (this is what has been called "Index", but I consider "Index" a misnomer: it doesn't make clear what is being indexed, and it's not an index but a table of contents).
should bring up the search page with "Search all Webs" not activated by default.
is for the remaining actions (list of changed topics, Web statistics, etc.)
displays the topic in a form that's suited for printing (essentially omitting the header and footer bar - the differences might be more marked for more elaborate skins).
is what TWiki is all about wink
is what's been called "Diffs" (sorry, guys, nobody outside the tech and freak community understands what a "diff" is, but everybody (including freaks) knows what recent changes are).
is for topic-specific actions like topic rename, topic deletion, full topic history, etc.

I have consciously omitted the

button. First, because buttons don't have an "open in new window" facility (at least in most current-day browsers). Second, because a single mistyped letter will take me to the Create New Topic page, which is something that we don't want (users might think they should create the page - after all, the site prompts them to do so... this might be the reason behind the empty pages that have been popping up in TWiki).


Related and maybe usefull: SimpleSite.

-- JaneJennings - 04 Feb 2002

No new ideas here? Simpler templates should also use SavemultiCgiScript, IMO.

Another great idea I found is to have EDITBOX area right in preview, as described in SavemultiCgiScript. We can eliminate need to go BACK from preview to continue EDIT, and completely avoid nasty IE bug, and add new feature.

-- PeterMasiar - 11 Feb 2002

I agree about SavemultiCgiScript and simpler templates. However, the various nasty IE bugs mentioned in SaveAndContinueWorkingFromPreview are now fixed quite cleanly - please see BrowserIssues - so there's no need to adopt user interface changes for that reason at least.

-- RichardDonkin - 11 Feb 2002

You can check how simple templates might be. This is live site, please be gentle! Also, I am not a graphic designer, my TWiki logo is not transparent. I know.

I created HELP skin, which almost completely hides fact that site is powered by TWiki. Users have internet-based help system and that is all they care about. HTML link from CGI script points to required help page. Users can see only YMDhelp web, web for help for YMD application. see here HELP skin.

Developers have Menu link on HELP skin to get the same page with more options - but still much simpler that classic TWiki skin. see here SIMPLE skin. This is my attempt to implement my proposal at #SimpleSkin. All actions are on the top, and most of them are hidden in [ More ]. Also, TWiki is represented by logo only.

I liked idea of having different logo for every web mentioned elsewhere, I'll do it next time. smile

-- PeterMasiar - 27 Feb 2002

I comment it myself, if nobody else is interested... smile

Comparing with other popular nice skins (like TigerSkin, KoalaSkin, DallasSkin, MikebSkin ) my SIMPLE does not render topic body as table cell. Header and footer are tables, as in "classic" skin template, but page body is just plain text between them, IMHO. Should be easier to render for any browser. Should be reasonably close to "classic" skin, and has one common feature from advanced skins -- smaller number of page actions placed on top of the page (right to page name). Is it good step towards default skin for distribution? Or something more fancy is better?

There is some issues in SIMPLE skin what I did not solved (was too busy/too lazy to study all details), like SavemultiCgiScript. If we decide SIMPLE skin is way to go for distribution default, I promise to find out and fix it (with your help, of course). If not, I hope BeijingRelease will have nice enough simple skin so I can dump mine. wink

Does anybody like it? If yes, we may need a page for it, maybe SimpleSkin is not too pretentious name. Current then can become ClassicSkin. Does skin need be in Plugins web? Why, if no .pm code is needed?

-- PeterMasiar - 08 Mar 2002

Peter - I took some time to study your SimpleSkin and want to commend your work on it! For one thing, just having a working prototype to study really helps me to ground this topic's meanders and loose threads. Anyway, here's my short feed back on what works and doesn't quite work for me (with suggestions).

  1. Very clean, simple "basic" header. Nothing to confuse the user there (except maybe use of "Menu" but more on that below.)
  2. In "enhanced" header, I really like having all the commands at the top. I'm getting real tired to scrolling to the bottom to get to recent entries or Edit and Diffs.
  3. It's also "makes sense" to me having the "topic functions" (Edit, Diffs, etc) beside the topic name. Hadn't thought of it before but it just seems right.
  4. I also like the "link to top of page" variable and would like to know the details of how that works. The switch between the two headers is a bit jarring. Several factors seem to contribute to this:
    1. The enhanced header is a crowded. Some more attention to detail of layout could make a difference here. The arrangement of advanced commands is not very intuitive to me. And why is "Webs:" listed twice?
    2. Having commands change location from one header to the other is confusing. How about having page title at the very top with "About, feedback, etc" directly under it in both versions? Then the other commands could roll out to the right side. Does this make sense?
  5. I know you're not a graphic designer and some help with graphic details like the icons could help.
  6. The use of "Menu" to trigger the switch doesn't seem quite right. How about "Options" or "Advanced options" or maybe even just a small tool icon of some sort tucked over on the right site.

Just a few thoughts... and encouragement to keep working on it.

-- LynnwoodBrown - 31 May 2002

Thank you for your feedback, Lynwood! My answers, by points (I renumbered your bullet list above):

  1. Re 1: I like name, basic skin it really is! And you need Menu link - basic skin is default skin for the web, so you need action to change skin somehow.
  2. Re 2: All new skins have commands on top. Maybe a pattern? wink I am thinking about adding button/link pointing to end of page. When I hold mouse, is easier to click than pres Ctrl-End. WDYT?
  3. Re 4: link to "top of the page": I'll add it into TWikiAdminCookBook (soon wink )
  4. Re 4: "advanced" header: You are right, it is crowded (and I do not have Bread crumb, see RoundEdgeSkinExperiments), but good enough for me frown . I ceased my template experiments, because I am the only TWiki user here right now frown . I need to remove web name before page name.
    1. Webs are listed twice, because I have "hierarchical" webs: YMD web has also related sub-webs YMDhelp and YMDbugs. I did not want to overcrowd main web list. Same might be case for other webs from the top row. KoalaSkin has script to generate templates, I was not that fancy.
    2. I do not like page title on the top. On top should be web action (specific, but same for whole web), and page title close to page body. I might try to put actions ("About...) to the top, good idea, because they are web actions.
  5. Re 5: Yes, I am definitely not graphic designer. But my users told me strong words about usability of overcrowded classic template (and decided to avoid using TWiki). This is not production release, but pfroof of concept. I was hoping to screate a skin with most good features from best skins, but still simple enough to resemble Classic TWiki skin, to use as default. I read somewhere here at TWiki discussion that skins based on tables are less preferable than header/footer only skins. And I tried to create header/footer skin for other, better skin designers to start with and improve. But you are first person to inquiry.
  6. Re 6: Menu: I had Advanced before, looked too long and scary. Nice tool icon might do it.

Next thing I would like to do is to add SavemultiCgiScript. It's annoying to save in two steps. But as I said, is good enough for me, and nobody else even considers to look at it, so it seems not worth the trouble.

I have some plans with my coming web site, but not enough time/experience to get it running...

-- PeterMasiar - 31 May 2002

Aside: I accidentally stepped on PeterMasiar's last edit -- I've now restored it.

I just want to ask a question that I hope has been considered with respect to placing the actions like "edit" at the top of a page:

Background: At one time, I spent time looking at a lot of WikiEngines. IIRC, on at least some of those, the actions like edit (or save on the edit page) were placed at the bottom of the page to avoid a problem. The problem was this -- the save button could be clicked before the entire page was "loaded". If that was done, content was lost -- only the content that had been "downloaded" (IIUC) before the button was pressed was saved.

Having written that, I don't really recall if there was a similar problem if the edit button was pressed on the view page before the entire page was visible.

Question: Does anybody know for sure that there will not be a similar problem with TWiki? (And, if you do know, I'd be interested in what is different about TWiki that avoids any such problem.)

BTW: If this question looks familiar, I'm quite sure I raised it before, but apparently not on this page, and, IIRC, it did not get a response.

-- RandyKramer - 31 May 2002

TWiki has version control. Next time somebody (author) does diff, can see what was deleted by mistake, and restore it. Maybe JavaScript can enable Save button, if we want to be too fancy...

-- PeterMasiar - 01 Jun 2002

I would have a major problem if moving the edit, preview, or save buttons to the top of the page resulted in a potential for loss of content if somebody pressed them too early.

This might be another issue that depends on the user's Internet connection -- if he's got a high speed connection it may be much less of an issue than if he has a low speed connection. I work on a low speed connection, and expect to run a TWiki site on the Internet that has to allow for user's with low speed connections.

BTW, I started Wikilearn.UsabilityTOC to start raising some other usability issues, including issues that are related to the speed of a user's connection. It's pretty ugly at this point, but you're welcome to look at it, add to it, and comment on it (in true wiki fashion).

-- RandyKramer - 12 Jul 2002

With ContentBeforeStructure, the topic action and navigation controls are always at the end of the html code, and therefore we never encounter a situation where a user can edit too early. With CSS, the menus can be positioned anywhere in the page. I've implemented this in SeeSkin , see a working example http://freedata.ca/~twiki no longer online --MW

-- MattWilkie - 12 Jul 2002

See my proposal for a simple default template header attached below. Features + rationale:

  1. one consistent color per hierarchical level
    1. the site - grey here, should blend with your site's style
    2. the web - use WEBBGCOLOR only for web level stuff, i.e. most notably not for the topic action bar.
    3. the topic - white here, should blend wiht your site's style
    4. actions - depending on your site style, not WEBBGCOLOR
  2. Complete yahoo style breadcrump trail
  3. Search instead of Go box. While I appreciate its usefulness for experts, it totally confuses beginners. Everybody expects a box at this location to be a search box. Really.
  4. Could be beautified like RoundEdgeSkin
  5. Clearly show the topic name as page title - no manual re-write with ---+ should be necessary
-- PeterKlausner - 13 Aug 2002

Peter, the attached sample page is incomplete. It stops at "Variables that can be used in the format string:" ,with no closing <body> or <html> tags. -- MattWilkie - 19 Dec 2002

PICK Related pages: TWikiSetUpTroubles, EZUsabilityUpgradePlan, TWikiToolChest, TWikiAdminCookBook.

-- MikeMannix - 19 May 2002, -- PeterMasiar - 01 Jun 2002

Changed to FeatureUnderConstruction, since it seems a large number of these suggestions have already made it into the current beta.

-- WalterMundt - 08 Jan 2003

Should the progress fields in the form be updated to reflect the suggestions that have already been implemented. If not, should what is left still be considered for the current release?

-- SamHasler - 13 Jan 2004 - bump - 13 Feb 2004

Bump feature topic marked as scheduled for CairoRelease with 0% SpecProgress

-- SamHasler - 20 Apr 2004

Feature bumped to Dakaar release due to lack of progress.

-- CrawfordCurrie - 30 Jun 2004

I think we could learn something from the way MediaWiki implemented their skins, see http://meta.wikimedia.org/wiki/Skins#Two_generic_xhtml_skins. I think we're most of the way there with PatternSkin. What I think we need to do now is encourage more skins to be made purely in CSS for the PatternSkin templates, perhaps with javascripts linked in via the patternskin template to allow authors to use it without having to change the skin.

-- SamHasler - 13 Aug 2004

If the default (PatternSkin) templates need further simplification, this should be handled in other topics that this rather generic, unspecific topic.

-- CrawfordCurrie - 15 Feb 2005

Edit | Attach | Watch | Print version | History: r45 < r44 < r43 < r42 < r41 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r45 - 2005-03-20 - MeredithLesly
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.