Alternative TWiki Targets
Alternative TWiki Targets is the first title that came to mind that seemed to work. Right now, the real mission is to start a this PAGE, gateway topic
within Codev, aimed to serve as a focus for discussion of issues related to TWiki installations that fall outside
of the core TWiki target market.
for the last 3+ years, TWiki founder/lead developer PeterThoeny
's amazingly tight dev focus on the high-end corporate intranet market
, combined with the support of the CoreTeam
developers and other contributors with their own interests in this direction, we now have this incredibly flexible, feature-packed Web platform. And if you strip out just about everything - easily done by anyone - you STILL END UP WITH A CLASSIC WIKICLONE
. It's a clearly unconvential platform.
So to the point: TWiki has amazing potential in many other areas, more now than every before. Millions of smaller businesses are half-shackled by their own insane, semi-functional office networks (whether they know it or not). On the personal and org side, Nuke-type sites for one seem to concentrate site masters on content
(which is The King), but in fact take much of the building
sense out of Web publishing. TWiki, on the other hand, is fresh, radical, perhaps even too weird
for a lot of people just...out there.
FREEFORM EDITING. Write not in BOXES, but ALL OVER THE SCREEN. Spread wide and with input from all over, the TWiki effect just might be kinda massive.
So, keeping the core mision firmly foremost, hopefully we can generate additional input, including non-programmer questions (like some of my own!) and other topics, that otherwise might not seem to fit in the normal, higher level core Codev stream. I'm psyched, totally up to see what happens. Whatever - all, or nothing - making changes for the right reeasons is half the fun, right here...
- 20 Jan 2002
See also: CollaborationSituations
The following thread was surgically sliced out of TaggingRelatedTopics - it'll be further edited, and some bits put back. There's more energy thant thought - RIGHT AT THIS MOMENT - in organizing this page. But I'll work it out. Speak your mind...
We have been converting a public 'gaming, and general nonsense' website from LotusNotes
to Twiki and came across similar issues. The original notes site used a 'psuedoheirarchy' of keywords to organise topics. We have managed to replicate the classification and heirarchy using twiki and a plugin which we are developing.
The idea is their is a keyword field which is 'freeform' you can enter in any topics that are relevent to the topic. For example you could type in Games, Quake, News
clicking on Quake does a search for all documents with Quake as a keyword (not Games, Quake although this could be done)...
It works really well for us. One thing we are yet to implement (the notes site does this currently) is have a drop down list of ALL the existing documents keywords - when one is selected it automatically fills in the keywords text field so you can edit it or add to it (ie Games, Quake, News would be one item in the drop down). What we have found is that because the users select the most appropriate keywords as a set, and usually just add an extra keyword on the end or modify the last keyword, the list becomes very organise and a 'Heirarchy of Keywords' develops.
eg. The drop down would look like (we strip out any duplicates automatically):
- Games, Quake
- Games, Quake, News
- Games, Quake, News, Clans
- Games, Quake, News, Competitions
- Games, Tribes
We then display them as a set of links at the top of each topic as Games > Quake > News
Not sure if this brings up any new ideas.
You can see the original website at http://evem.org.au
or the new TWiki development site at http://www2.evem.org.au
Click on an article to see the keyword navigation at the top of each article (this is created automaticaly by our plugin). If the development site is dead it's because we are working on it....
- 03 Jan 2002
I think my idea of MakeCategoryAndTopicDropdowns
is related to this. Let's say that each page had an "update" button to go with the topic category. Create a new category, merrily surf about TWiki putting updating the cateogry of selected topics and thus create a list of topics in the subject of interest.
This has nothing to do with this topic, but - Holy Wombats Batman! - Adrian's site is fantastic - hard to believe it's a TWiki! I want your skin!
- 05 Jan 2002
: You gamers are all fanatics, so I wasn't SURPRISED by the look - it's excellent, the cloning looks on point, and it's actually the first time I've seen a real break in the TWiki look, like, just basing it on black is a Big Change <g>.
Overall, I'm...totally psyched. I looked around both versions for a few minutes. Didn't see much of the keyword stuff, except some links, but it was just a quick pass. I'll go back.
I have one quick question right off:
- Why did you pick TWiki??? There are endless open source CMS systems out there, some sorta-Nuke-style, some with their own mad interesting structures (...phpCMS). Plus Slash, Scoop, half a dozen mature news/poll/weblog/etc in classic Perl.. ONE of those had to fit, SO WHY TWIKI?!
Hope you like answering questions! Also, I copied two bits of your post to CollaborationSituations
- if that's not good, sorry, just delete!
- 05 Jan 2002
First off, thanks! But all credit should really go to AndrewTetlaw
(aka Xtro) who is the driving force behind 90% of anything to do with EvEm
. Reasons for choosing Twiki? I have implemented an intranet/job/task database for work and was impressed with Twiki. I think the main reason is how flexible the wiki concept is, where as the majority of those nuke sites are just weblog/news posting sites. We wanted something more flexible and I suppose free form.
The ability to build a site using the site itself to build it (I think this is refered to as metacircular) was important as well. Twiki is almost
ideal in this regard, and we believe is fundemental in a good content management system and therefore a good site.
There are quite a few elements we would really want to change if we stick with TWiki, for me these are probably CSS
for all style (ie NO
font tags etc in the programming, purely div/span if need be) and XML
I am sure AndrewTetlaw
could comment more and answer the above better.
- 06 Jan 2002
Regarding Why Twiki
I hope people don't get annoyed with this off-topic stuff, but here goes:
has explained some technical reasons for choosing Twiki but there are some other concept related reasons too. Most gaming websites are defined by the weblog model where users with editorial rights post an article then regular users are able to post responses and generally discuss the item in question.
For Evil Empire I was toying with the idea of a user driven website, mainly because I'm lazy and don't want to have to go searching for news to post! A few reasons made me choose Twiki (or the wiki concept)
a) Some regular readers of the site regularly submitted content so I just wanted to be able to give them the ability to do it directly
b) I've seen sites based around messageboards that have succeeded in creating a compelling user experience. The Battlefield 1942 and Codename Eagle Community message board is one of them (I'll get the URL). Via a standard message board they create guides, have polls and other voting types, post news and interviews (collect questions to ask) and so on. I wanted to create that kind of user experience with something a bit more sophisticated than a message board.
Thus Twiki was a suitably advanced platform to do this mainly because it had registrations and versioning (and as AdrianLynch
indicated a structure flexible enough to suit our design ideas).
I want to build a site that is maintained by the people that read it, so that they can produce their own value, basically.
The idea was to create a system where the user could build their own navigational indexes rather than force them to follow the site creators ideas of classification. Thus a topic can have any number of keywords and a user can choose to list all topics that have a particular keyword or a combination of keywords.
e.g. one topic has games > quake > maps and one has games > halflife > maps
thus some of the choices are to list all topics with games, all topics with maps or all topics with games AND maps... the choice can be as wide or as narrow as the user likes, all that is needed is the simple interface to allow them to do it.
Easiest interface is a series of links to click on, but then I also saw the need for some sort of widget to allow the user to select the specific kewords and click 'go' or something.
Hope that answers some questions!
- 06 Jan 2002
Thanks for the answers! (Sorry to take so long to get back, it's not out of lack of INTEREST...just time.)
Andrew, Your core reasons for picking TWiki as the Wiki - authentication and revision control - are there exactly because of TWiki's corporate intranet target, along with the whole flexible base. I'm interested in TWiki for basically the same reasons you are - TWiki seems to me like a fundamental kind of Web evolution, along the old style personal site building where you learnt HTML
, and then how to include Perl CGI
, and at least tweak them if you weren't a programmer, then streaming audio, etc, but all still left the structure to the users and site builders. "Now" - all of three-four years later - it seems to've split down the Flash side (including anything proprietary, multimedia, etc), and the open source massive ready-to-go application: the Nukes, weblog stuff, CMS, etc, etc... which are cool, and mostly easy for anyone to use, but kind of lock you in. Wikis don't, but TWiki is the only one that gives you that open base, and still keeps you in the...21st century, you can add whatever you like...
Anyhow, I dunno how to put this exactly, but it would be cool to get other types of TWiki implementations than the main corporate targets collaborating around TWiki itself. Like, Adrian, you say, "There are quite a few elements we would really want to change if we stick with TWiki" - well, those may be minor or major, in any case, somehow expanding the scope here in a way that at the same time maintains the existing dev flow, could be interesting. Trying to push TWiki in different directions from the same base would be good.
This is a total topic tangent - I'll move it - but what do you think? Are you using Codev - this web/site - as a dev resource, or more changing things up on your own as you move ahead with TWiki?
- 12 Jan 2002
We both prefer to stick with core twiki and not fork our changes so that we can no longer benefit from the larger twiki development effort. It would also be hugely satisfying to have suggestions or even code incorporated into the core if it is good enough!
Ideally most the changes we will make would be plugins, but there are issues such as the following that I would see as the most in need of change.
- All meta and preferences to be stored as XML. I do not see this adding any greater functionality than the current methods, but I believe it is important for the longevity of twiki. It would allow more interaction with additional programs, and would ensure the content developed on a twiki site would have a greater 'value' due to it's portability.
- CSS. All 'style' formatting using html tags should be removed from the program itself. Currently it is still tricky to implement css positioning tags consistantly accross older browsers so I still see table tags being used, but font tags, table colors etc should be removed and replaced with div/span tags.
- Templates need to be cleaned up completly and possibly replaced with only 3-4 templates total (CSS would help a lot here as well).
- Access to META information (see VariableForCategoryDropdown)
- Plugin access to write directly to topics
Reading through codev most of these issues are being tackled in one form or another, so it is encouraging that twiki is really developing from a being a good solution
to an ideal solution
- 15 Jan 2002
Here's my few to add to Adrian's list:
- if-then structures in templates. (ConditionalRendering) I'd love to be able to say if %TOPIC% = "WebHome" then display "xxxxxx". Or if authenticated user is member of group X then display "xxxxx". On http://evem.org.au I want to display the home page with no edit/action links. But to do this I have to make a special template and use skin=home on all my home links. Using skin="xxx" is not really useful enough since a user can just remove the query string and I have to maintain it manually for every home link I create (I can't expect all other users to start maintaining it either). I also want the option to display special admin only action links but I want it conditional on authentication and membership of a special user group.
- notification recipients in BCC field, please
- remove content presentation from core code (e.g. edit link is rendered with bold tags ) this way users get to control presentation without haveing to modify Twiki
- definable user roles. I have a LotusNotes background and love user roles in the Notes security model. In notes you can configure the display of elements, avaiability of actions or general read/edit access on the basis of a specified role. You can then assign that role to users or groups. This gives you far more granular control over security. You can add remove users/groups at will from your application without having to make any design changes because you haven't had to specify specific users or groups. It also allows you to mix and match access levels amoungst users easily.
I'm aware that some of the above may seem to break the wiki way of the world but I think Twiki could be the basis of a great many applications, not only of the wiki variety.
Now we've really headed south from this topic! Apologies to those more interested in TaggingRelatedTopics
. Mike, you were going to move this conversation?
- 19 Jan 2002
Revisiting a year later...
I don't feel talk about alternative targets is necessary for the core code. There are still opportunities for improvement such as documentation, plugins, skins and add-ons. Plugins and skins may help for TWiki to serve other communities well, but I think the vision crafted by Peter as expressed in the TWikiMission
has helped to define and focus effort in a certain direction that has helped make TWiki what it is today.
- 21 Jan 2003
Going carefully here since I am very new. Please read the following as suggestions not criticism.
I have read the TWikiMission
and it certainly is focused on the CorporateIntranetWorld
(as I write this, that last term has been used and not defined in the Codev web since PeterThoeny
used it in 2001 in the Feedback to the TWikiMission
statement). This focus on the Intranet reminds me of Novell that prospered by doing that one thing very well. Its a good business model, focus and deliver to a large market with constrained complexity.
There may be a benefit, however, in serving the Internet wiki market. It is apparent that many of you supporting TWiki see it as a platform to deliver broad functionality; witness the many TWikiPlugins
as evidence. I suggest that the Intranet and Internet demands on TWiki are not in conflict if you view making TWiki-for-Internet as pre-marketing TWiki for the corporate Intranet.
Blogging is only one Internet application for TWiki (wikis); there will be others and Twiki is certainly flexible enough to serve the next Internet (and Intranet), "new thing" whatever that may be. I suggest that positioning TWiki for the next "new thing" may be well served by:
- A newbie's suggestion page (I don't yet presume to make that a WikiWord), with links riddled throughout the documentation - TWiki experts cannot easily see the barriers that well-meaning but fleeting newbie users face. Capture their knowledge while you can and before they get frustrated by putting links to a newbie suggestion page in all the documentation. Make collecting new-user experiences a priority and it helps avoid the innovator's dilemma by not over-focusing on past success while getting data on where to expend your development energy to promote TWiki to new users and building the next success. Perhaps just pulling together all the TWikiGuest edits/comments in one location will meet this need. Nonetheless, my personal experience is that comments have to be repeatedly solicited to be gleaned. Just having an Edit link at the top of every page may not get the desired results.
- Making TWiki Internet secure with guidance on how to remove that security if needed for Intranet capabilities. This is not in conflict with the wiki-philosophy because it merely requires that speech cannot be imposed by hacking but only by wiki-ing.
By tightening the default Internet security of TWiki and focusing even more on the priorities of newbie users I hope TWiki will entice even more of them to stay, convert to contributors and promoters; and so grow Twiki's market presence.
- 24 Jan 2005
Richard there is nothing in your comment which is overly presumptuous. In fact it is quite welcome. For awhile we were putting and collecting specific newbie-type observations into UsabilityIdeas
. It got very big and unweildly and unfortunately the effort to refactor it into something more manageable has run out of steam. Part of the problem was/is that it is pretty easy to drum up a big list of what's wrong and what could be impoved, but it's a lot harder to a) decide what the best cure is, b) find someone interested enough to implement it in code it, and most importantly c) get the improvements into twiki.
- 26 Jan 2005
Thanks for the response Matt; glad to know about UsabilityIdeas
- I read it through and it is unwieldy as the last comment on Sep 24, 2004 noted.
It may be that the Support web is the "newbie suggestion page" for which I am looking. Putting links from appropriate parts of the documentation to the matching parts of the Support web should have the desired effect of both drawing in newbies while classifying
Support questions from those uses most likely to misclassify their questions. I will look into this further - thanks.
- 26 Jan 2005