create new tag
, view all tags

Better Defaults Project

I plan to repackage Twiki to make it easier to install and use. Basically, I envision to add a script in each of main directories (data, pub, lib, bin, templates), which will do there what needs to be done, so I can forget it ;-).

I want to create distro which will not fork code from Twiki.org, just be more usable and easier to install. If I can bribe some coders along, I'll like to add some code changes (e.g. NoBumpyCase, split preferences)

I plan some changes in docs, too, as I learned from my users and from discussions here. All changes will be made with goal to enhance usability especially for new users. Twiki is AFACT best perl wiki (most feature-rich), but is known to be hard to install and customize. So before we get run over by python and PHP wikis, lets do something about it.

I am looking for input and hopefully consensus on what needs to be done, and checking to see if somebody else wants to join me. Is anybody interested in creating something more oriented to easier installation and usability? What features are important for you to get in?

RuleOne: Everything should be simple and no surprises, do as other websites do.

It will not be easy - I have MidnightCommander and root password, but I am far from Linux guru. No promises of quick solutions (at least from me wink ), but I noticed many Twiki adopters have the same problems as I have - why not pool our skills and resources in the spirit of OpenSource?

BTW my Linux is Red Hat. In the future, I plan to add install scripts for non-root, because I plan to install Twiki at a hosting service. I did not decided yet which one - possibly at Eryxma or DreamHost or another good deal for TWikiOnWebHostingSites, whichever gets more support here.

Proposed Changes

What do you guys think?

-- PeterMasiar - 11 May 2003


Kramer: RandyKramer Masiar: PeterMasiar Norris: WillNorris
Thoeny: PeterThoeny Wilkie: MattWilkie    

Rename topic to page

Thoeny: IMO, a small detail. Could be made configurable.

Masiar: Yes, it is a small detail for technical people, and it could be made configurable.
But it is important for non-technical users. Small little non-intuitive barriers in the entrance - and they never bother to enter.

Norris: from a software engineering point of view, i would say topic is a good abstract name, whereas page is too concrete. but this is user interface space, so it doesn't really matter what the variables should be called---it's about the user's mental mental model of how things work. as people are very familiar and comfortable with the term "webpage," i would recommend leveraging this knowledge and applying terms that people already know (when it can be done effectively, as in this case); page is very natural.

Rename web to zone (RenameWebToZone)

Kramer: I don't buy into the "zone" and so would prefer to see that name be an administrator set option. (Currently, I'm leaning towards "dir" being short for "directory".)

Thoeny: Controversial name, has been discssed in lengh in other topics. Could be made configurable. "Web" associates with spider webs, aka linked web pages and is a well understood term. I do not think that many people understand what a "Zone" is intuitively; to me it associates with "construction zone".

Masiar: IMHO best term is "section", but "zone" will be in the end of PageList. For non-tech users, web == internet. When they seen WebNotify page, they asked me to remove it - they do not want to notify whole web about anything. When instructed that web is like a folder, they asked why Twiki calls obvious common concept like page or folder differently. And joked about hackers. Not very corporate approach, is it?

Cleaver: I agree about liking Section. The name 'Web' is confusing and Zone is a bit too amusing. Section/Subsection is very corporate and is therefore in alignment with TWikiMission.

I add another vote in favor of Section / Subsection, or maybe Sec(t?) / Sub for short (but my "underlying vote" is that it be an administrator option). Digression: Naa, I shouldn't digress, but ... — if we use surnames as attribution, I'd rather not see Kramer in bold face — maybe just plain italics. I've changed one above, I won't worry about the rest. wink -- RandyKramer - 01 Jun 2003

Norris: i know i'm commenting on this point quite late in the process, but at my work, we don't call them webs or zones---they're called "wikis" here! all of the "webs" are "the wiki," and each "web" is a wiki (kind of like money and money?). in contrast to my argument for page vs. topic, "wiki" has the advantage of being a new, "made up" word, so there are no pre-existing connotations. plus, referring to a "wiki page" seems like a specific kind of "web page." this nomenclature seems quite natural, and has never led to any confusion or ambiguity when talking about things.

user homepages go to User zone and Main will be for real main stuff

Thoeny: TWiki targets corporate use. What about TWikiGroups and OfficeLocations? At work we also have other general info in the Main web like EmailAliases, AimScreenNames.

Masiar: All this info is clearly user-related and IMO will feel as comfortably in User zone.

Cleaver: I agree, I think that User.AimScreenNames and User.EmailAddresses works nicely.

Adding more skins

like GnuSkin, FlexibleSkin, HelpSkinDev

Thoeny: This is the goal for upcoming TWiki releases. First we need to have an enhanced API so that the skins can be listed and selected.

Masiar: I do not agree here. We have some mechanism to select skins. Even I managed to change skin wink . We need to pack existing stable skins now so tech-chalenged admins (like me) can unpack default distro and have nice skin enabled. Better API could come later. I can wait if I have nice skin by default. How much longer we need to wait for better standard distro? I am not able to use half of the advanced features anyway. I bet there are many new admins like me. Why wait and push them away to other wiki engines?

Create separate newbie docs from twiki docs

Creating better newbie docs (separated from TWiki docs) which are IMO for admins and gurus, and customized by skins, possibly with presentations PowerPoint => HTML.

Thoeny: Some structural changes have already been done in the TWiki web: "TWiki Quick Start" is for new users; "One-Page Primers" and "TWiki Help FAQs" are for end users; "TWiki Reference Manual" is for site administrators. The docs should be improved for new users if they are not good enough.

Masiar: I meant separate docs zone for newbies. IMHO it is important for them to remove everything non relevant. I want to tell: "read these pages and you know all you need to know". And I plan to access full Twiki docs on twiki.org

Adding more default plugins

(like SlideShowPlugin, CommentPlugin)

Thoeny: Agreed, will be done in upcoming TWiki releases.

Add more variables for icons to create nice pages

Thoeny: Simple do do in the existing TWiki

Masiar: yes, but why not do it in distro and save lot of work new admins? And I disagree with variable names as used on twiki.org: %WARN% and %HELP% is much easier to use, than %X% for ALERT! and %H% for HELP
Maybe all these small icons should go to SmiliesPlugin, have easy to remember mnemonics like :help: :warn: and be installed in standard distro?

Changing logo as in HighResolutionLogos

Thoeny: Needs to be reviewed when the TWiki default template changes to a more corporate look (the existing templates will be made available as the ClassicTWikiSkin)

Change TWiki to Twiki

(if I can get it)

Thoeny: Not in the official release smile

make WikiWord link without BumpyCase

see NoBumpyCase

Split preferences between TWiki.TWikiPreferences and Custom.SitePreferences

To simplify customization, some preferences will go to two pages: TWiki.TWikiPreferences, and Custom.SitePreferences, so some could be overwriten, but on upgrade, I do not have to merge my custom changes with page from new version. We will see how to handle this one. Comment and code welcome wink

No forks please!

Kramer: I also don't really want to fork from TWiki, but I think it really would be a fork — there would be the original TWiki and what you create — if you want to give a name to it, it's a fork. (Isn't MegaTWiki a fork, even though it has no other / separate home page / public web site (AFAIK).)

Thoeny: Not sure that generating a fork that needs to be updated with each release is the right approach. We have seen in the past that forks come and go. Helping in improving the docs here at TWiki.org sounds like a better use of time to me.

Masiar: As I stated above, I do not want to fork. Let's see how much I can get without fork. When it comes down to it I cannot fork wink - I can look into perl code, but not have time to do much coding.

Cleaver: I've commented on this in ThankYouPeterThoeny

General Comments

Kramer: You can bribe me, but I'm not a coder (so far) so it won't help much. wink Actually, I have some similar ideas. I'll make a few comments:

  • I see other things as more important to deal with (no offense), and the first step I thought of taking was to spend quite a while writing a spec, describing both how TWiki works now, and then, where appropriate, describing how "we" (whoever we might be) want to change it. (Those sections would, at least initially) need to be carefully marked.)

I guess the reason I feel that way is that, if we rewrite TWiki (or refactor it piecemeal), we should have a reasonably well defined goal so that we can:

  • Make a reasonably well defined plan based on the goal(s)
  • And we take the most important steps (or allow for them) from the beginning, so that we don't have to redesign again partway through.

Some of the things that I'd list as most important include the following:

  • A design that, from the beginning, plans for greatly improved performance. (When I do a Google search on Wikilearn I am almost overwhelmed by the response, even over my dial up connection.) Here are some of the alternatives that should be planned for right from the beginning:
    • using modPerl or some other language faster than Perl
      • Wilkie: the best approach here is probably just optimising twiki's way of doing things; something along the lines of MetadataSucks_

    • serving pages as static HTML pages, using dynamic pages only for editing, searches, or similar (and deciding how do support skins with static HTML pages).
      • Wilkie: which leads to questions of when to update the static pages, which is a non-trivial problem (anybody remember what page RichardDonkin talked about this in?)

    • allowing for mirror sites including addressing how to handle editing. Maybe all editing is forced back to a single home site? Or do we allow for some sort of semi-automatic merge with a conflict resolution mechanism?
    • allowing from the beginning for a variety of back end storage mechanisms, plain text files (as today), databases, or databases for metadata only
    • understanding the (forget the right name but I mean the) issues around losing edits after a refresh and designing the HTML headings from the beginning to avoid that problem

I'm not sure all of these need to be done. Or to say it differently, maybe the next iteration of TWiki (or fork, or whatever) should specifically target public wiki sites (instead of intranet sites), and thus some of the decisions about the items above should be based on this. Even so, maybe the next target might be "medium" sized public wikis (can we quantify? maybe 100,000 users and 1000 contributors) versus immense public wikis (5,000,000,000 intermittent users, all of them potential contributors).

Anyway that's my $.02. I planned to start writing a specification combining present TWiki behavior and desired changes over on Wikilearn.TWikiSpec. I'm not in any big hurry to do so (there are some other things ahead of it on my ToDo list), but help is welcome. IMHO, each TWiki support request, bug, plugin, Codev topic, etc., needs to be reviewed for what it might imply for a new version of TWiki.

Sorry, I don't intend to discourage this effort — if you itch, scratch. wink (And don't wait for my scratching to relieve your itch — unless a lot of other people are interested, it will be years if not decades before such a new version of TWiki comes into being.)

-- RandyKramer - 11 May 2003

Peter, it is good to have you on board to drive the usability of TWiki. Some comments on your proposal: [refactored above]

-- PeterThoeny - 13 May 2003

Thank you Peter for taking time to response to something which looks for you as minor complaints.

I was unable to start Twiki in our group, with many complaints about poor usability. And obviously I am not alone. My heart hurts when I read reviews about Twiki, complaining about hard to install feature, or when I see many Twiki installed with IMNSHO user-unfriendly "original" skin.

I am not guru admin, so I can tell what hurts others like me wink And I contemplated many times to switch to another, simpler to install wiki - but I keep returning for best features available here. I invested to tweaking Twiki much more time I should.

I think that focus exclusively on corporate use is the culprit. Twiki is so feature-rich that became popular. Many would-be admins with less than adequate skills would like to use it for simple wiki all over the place - universities, SIGs, community websites.

Now, Twiki community needs to decide if it wants to

  • accomodate also interests of these non-corporate tech-challenged users, and gain:
    • much wider installed base and bigger developers contributors base,
    • better usability for corporate, but less-technicaly advanced users,
  • or let tech-wimps struggle along or even push them avay to other wiki engines.

We will see.

-- PeterMasiar - 13 May 2003

I would like to use this space to remind you of the discussion in TooUglyForNonTechnicalUsers.

-- ArthurClemens - 13 May 2003

  • Thank you, Matt, for refactoring - it's easier even to me to follow up wink
  • Thank you, Arthur, for reminding the link above. You did excellent job in explaining issues there. I added my comments in TooUglyForNonTechnicalUsers. It's page name is too ugly wink

-- PeterMasiar - 14 May 2003

I liked idea of AntonAylward from AllowWebViewVersusAllowTopicView

He re-wrote the templates so that the Main.username automatically has a setting so its not editable, and a link to the "Home" web - "Home.UserName". That is only editable by the user. This losens up the "home page" concept to what many users would expect. We needed this to accept contribution by email (authorise user by email address) in MailToTWikiAddOn, IIRC.

So I want to have "User" web for system-owned user info, and "Home" web for user's homepages.

-- PeterMasiar - 16 May 2003

I'm not sure why the subject of forking TWiki even came up - I don't see that the proposed changes should be especially controversial or in conflict with the idea of targeting corporate use. User and Home webs (or zones) would simplify access control even if the ideas of AllowWebViewVersusAllowTopicView are not implemented. And the suggestion of providing Custom.SitePreferences would reduce the need / desire for a forked TWiki - it would give administrators a lot of confidence that they can customize their site and still be able to apply the next TWiki upgrade without clobbering their previous settings.

On the issue of providing more skins in the default distro - why on earth would this depend on an enhanced API? The skins mentioned above (plus (blatant plug) VoidSkin) adhere to the existing API - why shouldn't they be part of the distro? If/when the API changes in the future, the skin developers should be given opportunity to make the necessary changes in time for the next distribution.

About "Web" vs. "Zone" - I actually like zone better, mostly for the same reasons given above by PeterMasiar. One problem, though: WebHome would become ZoneHome which sounds distressingly like a line from a very bad science fiction movie. wink

-- DaleBrayden - 16 May 2003

Multiple skins can easily be supplied with the standard distro, but how can end users easily know they are there and try them out? Much of the debate above relates to ease of use - this surely points to easy selection of skins.

-- JohnTalintyre - 16 May 2003

Skins could be easily supplied, but they are not. Admin has easy way to setup default skin for the web already in WebPreferences. My complaint is: it's easy, but it's not happening, and so scores of happles newbie Twiki admins are forced to use default ugly skin, or struggle to customize it. Or drop Twiki and then either badmouth it, or say - "I liked Twiki the best, but was not able to make it working, so I installed UseModWiki (or CgiWiki, or ...) wiki".

And my time will be possibly be also better spent trying to install KoalaSkin (or UseModWiki wink ) than trying to persuade gurus.

-- PeterMasiar - 16 May 2003

One key is where to focus. Another is how much effort is available to get stuff done.

I agree that the defaults are critical to incrementally (radically?) increasing the usability of TWiki overall and for new installations specifically. How can the TWiki release process be improved to ensure that these defaults get into the release? Without real effort put into the fit and finish of TWiki I fear it will some day get passed up for something that's better. It's important that I don't know of any system that is better. smile

Perhaps without real competition there is somehow less motivation for changes of an incremental nature? What if M$ did a wiki add-on to Exchange? Should the people doing the real work wait for some external motivating factor? Can more be safely & reliably delegated?

-- GrantBow - 21 May 2003

I am not so sure there is no real competition. In example, I installed MovableType (in a hour or so - Twiki took me a week frown ) . I heard there is a wiki plugin. Or somebody will add it. MT has thousands of users, hundreds of plugin developers, and OO architecture. And MT is really easy to install.

-- PeterMasiar - 26 May 2003

I've factored in a couple of points above, adding support for 'Section' over 'Zone'. Hopefully Peter T will get time to follow-up. If anyone reading has time, it would be worth cleaning up and refactoring RenameWebToZone; that topic is a bit of a mess but contains lots of good ideas.

The JavaScript based HtmlAreaEditor, with its ability to work on both Mozilla and IE and its functionality of providing true WYSIWYG support could revolutionise usability, but I need more opinions on it. Perhaps Arthur and others could comment? Although not packaged as a plugin it takes about 10 mins if you follow the instructions I posted on HtmlAreaEditor.

-- MartinCleaver - 01 Jun 2003

I've made a list of pros and cons, see HtmlAreaEditor#Pros_and_cons

-- ArthurClemens - 01 Jun 2003

I hate to comment when I haven't read the entire topic yet, but I wanted to comment on the concept of using an HtmlAreaEditor at all: On one side, a formatting toolbar is nice to have for inserting my signature and such. On the other side, living without too much formatting keeps the focus on the content rather than the formatting. This is important.

TWiki is a tool used for communicating, not for painting. Remember when desktop publishing, nay, fonts, became available to the pc users? I'd honestly hate to see that happen to TWiki. I'd rather limit the formatting choices in exchange for sufficient focus on the contents. KISS applies. Besides, without font formatting etc. in TWiki, every user can set his browser to use whatever font he prefers (I appreciate this as a feature of TWiki, and a lack in most sites).

-- TorbenGB - 04 Jun 2003

A HTML editor means we don't have Wiki markup - I see this as a real issue. There may be a small subset of topics and/or users who would want an HTML editor off a TWiki site, but I wouldn't think this was really the user base we best address with TWiki.

An WYSIWYG editor would be a real boon for TWiki, but I think this will be hard work, however much we borrow from other developments. I guess I'd like to see the existing facility work, but that a Java Web Start based editor would also be available if users wanted it. Ideally this would communicate with the TWiki via WebServices. A real issue here is that you really want the rending code in Java ...

-- JohnTalintyre - 04 Jun 2003

%W% Just a word of warning: I think that customizability can be harmful for an end-user product, in that it makes documenting it and making training material and tutorials very hard. For instance, I had to write a tutorial for Wiki in my company, as the current end-user TWiki docs suppose the user sees the standard skin on his screen, not the KoalaSkin...

Imagine what it would be to have the documentation cope with the fact that Webs could be called "Zones", "Folders", "Endroits"... at the local admin whim. It will not be a big deal for the perl code, but it will make hell on the users. Documentation, samples, examples, and imitation (seeing how it is done elsewhere) are very important for an end user

So, if we may change names for Topic, Webs, Main, etc... so be it, but I encourage you all to:

  • really ponder the pros and cons to be sure to get the right name (I would like to upgrade my users brains only once smile
  • do not make it a variable. All the TWiki in the world should use the same conventions, once we decide on a name change, everybody should have to obey it.

On HTML markup, I think also it should be kept to a minimum. Our previous intranet died because as soon somebody edited an HTML page, there was a flamewar on his/her choice of fonts and colors...

-- ColasNahaboo - 04 Jun 2003

Is somebody interested is putting together a distro with better defaults? I have an account on Eryxma which I do not use - I can donate it if somebody is interested to install a twiki there and some skins and stuff to make better distro. I'll contribute with SimpleSkin, CommentPlugin, and AdminTools. I'll be interested to add examples of TWiki-based applications, like bug tracking, help forum, etc. We may have as many webs as we want there. smile

-- PeterMasiar - 02 Oct 2003

Edit | Attach | Watch | Print version | History: r25 < r24 < r23 < r22 < r21 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r25 - 2008-08-23 - TWikiJanitor
  • 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.