marketing1Add my vote for this tag create new tag
, view all tags

Create a plugin demo installation on twiki.org

A proposal to give (potential) users more insight in the capabilities of TWiki, and advice them how to employ TWiki to the fullest.

From HowDoWeGetToWhereWeWantToBe:

... what about some kind of form/survey for the user to fill out that will return a list of suggested plugins that they might consider depending on needs? "Will your TWiki be internet accessible?" if so there is an entire series of plugins they should probably consider that are basically useless if it is to be a LAN site. This is just one example, I'm sure you see my point. Making TWiki more user friendly means helping narrow down the options a bit, making it easier for the user to filter through the noise and get at the bits they want/need. -- TravisBarker

The real problem is that plugins do not give good insight in what they actually do. Because on twiki.org most plugins are disabled, the plugins cannot be seen in action and thus give no insight. Few have screenshots.

This is strange, because one of the strengths of twiki are the plugins. But they are nowhere advocated.

Something along these lines has been discussed before (also by me, but not followed upon):

What "adds value"? See TWikiWhatWillYouBeWhenYouGrowUp for some thoughts. What is "cool" and "fun" for coders is not always what sells. Applications sell. Yes, TWiki has plugins that have allowed people to build applications ... but ... those are not applications. At the very least we need cook-books and detailed examples. Even better would be to have the ConsultantsForHire realte what applications they work with and put up demos.

-- AntonAylward - 05 Nov 2004 (TWikiRoadMap)

Yes, we definitely need good examples of applications and websites/intranets. And working examples of plugins, not targeted towards collegue TWiki users, but towards laymen, managers, etc.

-- ArthurClemens - 10 Aug 2004 (TWikiApplicationsShowcase)

Now that other wiki systems are gaining pace it is even more important that TWiki starts to 'sell' itself.*

By that I mean the selling of ideas (key features, Unique Selling Points):

  • What can you do with TWiki (with a wiki in general)?
    • Most people when I tell about twiki don't have a clue why you would want to edit pages...
  • Why TWiki?
    • Something about the ease of creating and linking pages.
    • Costs saving: Why invest in a separate CMS for an intranet?

Of course this is all on the twiki.org homepage. But the message isn't told in a compelling way. There is not one illustration. Show me the Calendar plugin!. The Slideshow plugin. The Chart plugin. Give me screenshots. Show me how easy it is to implement. Show me example usages from real sites. Give me ideas so I can develop my own.

Show me great skin examples.

Give me a FAQ.

More: Access control is pleading for a short text that tells me how you can set up a Workflow scheme.

Show me how TWiki can take on the role of CMS.

Documentation generally lacks a "How to" approach, seen from a higher problem level:
  • I have an Intranet noone uses.
  • I believe in Open Source Content. Can I tweak TWiki for my site?
  • I need an extranet solution to share corporate pictures.
  • We develop technical books.
  • I need a website for artists that do not know HTML.

What is important is to get real world examples from all of us. Not big companies success stories per se, but smart solutions to everyday's small problems.

-- ArthurClemens - 01 Oct 2003 (CommunicatingTWiki)

So we need to show examples.

I want to focus here on the plugins.

What we need to do:

  • Ask plugin authors to write an introduction for dummies, no knowledge required, with the format:
    1. What problem does the plugin solve
    2. Where can it be used
    3. What is special about it
    4. ... please add
  • Use the descriptions to generate lists (manually) to the Plugins homepage
  • Create a Demo installation (demo.twiki.org) with all plugins enabled. Each twiki.org plugin page should have a link to a demo page.
  • Use the demo installation to create screenshots.

-- ArthurClemens - 10 Apr 2005

"Applications sell" . This is the starting point for what has been happening on the Twikis I manage. Much of the power (from a user point of view) IMHO lies in the plugins. But the plugin pages and naming are very off putting for users. The documentation, good as it is, is I think mainly aimed at the TWiki web manager. So I've taken to creating a monthly "Cool Twing" in my sites that comes in at the plugins from a user angle, I never mention the name of the plugin, and give some basic how-tos and examples of using the application. This has been working. Having a demo plugin page that works froma user point of view - what does this plugin solve/do - is a good suggestion. I'll be interested to see how it goes.

-- SueLocke - 10 Apr 2005

Why not use the existing twikiplugins.sourceforge.net as demonstration platform?

-- FranzJosefSilli - 11 Apr 2005

Good points Arthur, Sue and Franz.

The first part of the existing Plugin template (NewPluginTemplate) is supposed to be user centric: Short description, syntax rules, examples. We can fine tune that as Arthur suggests.

Plugins authors are encouraged to create and ship a tip-of-the-day for their Plugin, see TipOfTheDayFeatureRequest.

I do not want to install many Plugins on TWiki.org's main TWiki engine for performance reasons. Another reason is that SourceForge does not allow us to install some of the required Perl modules of some Plugins.

-- PeterThoeny - 11 Apr 2005

Wouldn't it be more flexible to have a PluginIntroduction topic included in the main plugin topic, so that the PluginIntroduction text can be re-used on other pages? Also existing plugin topics can be left as is for the time being, only have the (example) %INCLUDE{Plugins.EmbedFlashPluginIntroduction}% included at the top.

-- ArthurClemens - 11 Apr 2005

I don't want to get trapped in a chicken-egg deadpan. What do we need to create an installation to show plugins working? A new server? If needed I can create one on my dreamhost account, I also have one unused domain left.

-- ArthurClemens - 11 Apr 2005

That would be good, Arthur. The fact that Peter didn't mention ntwiki suggests that it is not an option, so we are left with your dreamhost account.

I think installing all the plugins will lead to problems, though, for two reasons:

  1. Several plugins simply don't work
  2. There may be conflicts between plugins
  3. Some plugins have excessive external dependencies
So you need a shortlist of those plugins that you think need to be shown.

(Note: it might be an idea to have N parallel installations of basic twiki, one for each plugin, to ensure crossover isn't an issue. Not as hard as it sounds. You could offer a new installation for each plugin author who wants to set up a demo.)

I'm ready to help with installation and configuration of plugins, as far as I'm able.

-- CrawfordCurrie - 11 Apr 2005

I think it is better to have all plugins installed at a single server. This will

  • ferret out the incompatabilities between plugins, in case there are any;
  • show which plugins work in the current release and which do not;
  • make it clear which plugins have documentation or installation problems.

I think it would be really great if we could have as many plugins as possible live.

And, yes, I expect there to be some growing pains. But seeing your plugin working is a great incentive to make it work...

-- ThomasWeigert - 11 Apr 2005

Some practical questions:

  • Should plugin authors then need to have access to the plugins demo site (FTP)?
  • What would be a good url? Is something like demo.twiki.org possible with another web server?
  • I am thinking of creating a web for each plugin. That way each plugin can have its own test topics, and it will be easy to toggle problematic plugins off.

-- ArthurClemens - 11 Apr 2005

and... how / who has to validate the plugins & each change to them to ensure the security of the server?

What if we move the plugins to svn, and gave PluginAuthors DEVELOP access, and then set up auto checkouts to a chrooted virtual host running off a CD?

if all the plugins had the necessary topics in svn, similar to how Crawford has done for the DEVELOP plugins, (rather than sandboxing the plugins in seperate webs), it would reduce conflicts - with the current layout, it is simple for two or more plugins to supply 2 files with the same name, and if you work form twikipluginscvs, you have to move files around to get the to run, reducing the chance that people test with other plugins.

-- SvenDowideit - 11 Apr 2005

Having demo.twiki.org on another web server is indeed possible.

-- MartinCleaver - 11 Apr 2005

Sven, you're talking abacadabra to me. Could you explain each line smile ?

-- ArthurClemens - 12 Apr 2005

I would love to take this on. Martin: how? Sven: I am still groping.

-- ArthurClemens - 13 Apr 2005

Arthur - you need to

  1. add a DNS entry for your hosting account to handle requests for demo.twiki.org
  2. get Peter to point the DNS entry for demo.twiki.org to your server.

-- MartinCleaver - 13 Apr 2005

mmm, i suspect i'm not goong to do a better job of explaining it this time either

  • the biggest problem I see is that as you add plugins to demo.twiki.org, you will need to do a security audit of the plugin
    • this will obviously be a good thing in the long term, but is somethign that will have to happen every time an update to the plugin is made
  • the ntwiki server is set up to automatically mirror the code in svn - a similar mechanism could be used to automatically track plugins
  • this in combination with a restricted server (either a virtual host, or running of a CD would simplify things
    • ie, set up a host that regularly (nightly?) get zapped back to a known good state

I was also wondering if we shouldn't move twikiplugins to ntwiki svn.

I have more thoughts, but i have to get ready to go to work - I'll edit this later

-- SvenDowideit - 13 Apr 2005

Arthur, the gobblededook is important; I will try to decode.

  1. There is a high risk of a fatal security breach if you just load up plugins without checking them out first. This could impact the integrity of the site, or the integrity of your account. So Sven is suggesting you need to audit every plugin for security before loading it up. You cannot afford to trust that plugins authors have done a good job of security, as many plugins are designed to work in intranets and have not been checked.
  2. The basic TWiki code used as the base for the plugins can come from a couple of places; it can come from the most recent TWiki release, or it could come from the head of the DEVELOP branch. The latter would make most sense if plugin releases were themselves checked into SVN after they had been audited. The former makes sense for most people, I think.
  3. The last point is that we have to work out how to stop plugins from running into eachother. This may work just fine, but there are associated risks:
    1. Two plugins may try to interpret the same TWiki syntax (e.g. TablePlugin and EditTablePlugin), or otherwise confuse eachothers functionality.
    2. One or both of the plugins may only work when the other plugin is installed.
    3. Plugin A may trigger a bug in plugin B, which wouldn't happen if plugin B were used in isolation
    4. The plugins may have mutually-exclusive configuration requirements.
    5. It is hard for a reviewer to work out which plugin is providing what functionality.
    6. Some plugins are performance hogs, and will make the other plugins look bad.
My opinions: On security, I think you just have to bite the bullet and audit the plugins. I think the base code should be the most recent release. And I think you need a page on the server somewhere that lets people enable/disable plugins at will. A BROADCAST_MESSAGE should say what plugins are currently active, and give instructions for enabling/disabling plugins. If the enable/disable process can be done using a webform, and use an external script to completely uninstall and re-install each plugin, so much the better.

-- CrawfordCurrie - 14 Apr 2005

So first audit the plugins when putting them in SVN, then use SVN to upload to the demo server.

How much work is involved in performing a plugin audit?

About enabling/disabling plugins: my understanding is that this can be done in WebPreferences, so that's why I had the idea to create a separate web for each plugin.

Uninstall en re-install: you mean physically removing and putting files?

-- ArthurClemens - 14 Apr 2005

Edit | Attach | Watch | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r19 - 2008-09-16 - 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.