Please make a Showcase web

A better name is fine.

There are numerous reasons for this web:

• A place for people who have done cool things with TWiki to show them off (I'm talking installs, not plugins)
• A place for people who are developing cool things using TWiki to show what they've done so far and ask for suggestions and help
• A place for people who wonder what kinds of things have been done and can be done with TWiki
• A place for the press to see how cool TWiki is

Probably more. Please feel free to add reasons.

See also CustomerFocusedTWikiOrg on a new scheme for twiki.org. "Showcases" could be a separate entrance. Competitors who actually sell their wiki software are clear about this:

• Wetpaint puts in on the homepage: "Wetpaint in action"
• eTouch SamePage has the section "Applications"
• Jotspot has a showcase page with a link "Don't see the app you need? Request it now!"

It is obvious that there needs to be a clear entrance for visitors/reviewers/users.

-- Contributors: MeredithLesly, -- ArthurClemens

Discussion

In contrast to the topic title I am asking you to put forward why not to create a new web. Before answering, please visit the competitor links above and ask yourself how twiki.org is going to match that.

-- ArthurClemens - 01 Apr 2006

In response to the idea that we set up a nested hierarchy called Showcase.Application1.WebHome Showcase.Application2.WebHome, etc, Will suggested that we need a separate installation rather than a set of webs for demoing apps as some apps would need plugins.

How about http://demo.twiki.org?

-- MartinCleaver - 02 Apr 2006

A demo web where applications can be shown and worked with is certainly welcome. However we still need an entrance and show off applications that do not have a demo installation.

-- ArthurClemens - 02 Apr 2006

I am curious about the what in this proposal - I am somehow not able to relate very well to the sketched "A place". Would it be possible to get some details? Are we talking for instance

1. (H)TML content of a somewhat static nature - of course including text, pictures, flash, live demos and other visual effects
2. working apps with requirements fulfilled by the twiki.org installation
3. working apps with requirements fulfilled by custom webpreferences settings
4. working apps with additional template/skin changes
5. working apps with additional plugin requirements
6. working apps with lib changes
7. working apps with apache virtual host customizations
8. working apps with additional CPAN requirements
9. working apps with additional generic binary FOSS dependencies
10. working apps with a combination of all of the above and further

If we are talking !a, we might as well talk separated twiki installs for each demo. Something that could be accomplished using a concept similar to TWikiVMDebianStable, where each app in the showcase has it's own /url and twiki installation directory.

The VM approach as I see it would help the following cases:

• Easy to revert to snapshot every 24h
• Easy to run the same installation in several places, i.e. have showcase1.twiki.org .. showcasex.twiki.org hosted in separate locations for failover / uptime / distribution of load purposes
• Easy to take offline if compromised
• Easy to offer visitors a binary copy, as a hands-on and behind-the-scene showcase VM

This is just meant as food-for-thought, I am just curious what this proposal is really about. If the intention is mostly a), starting out by evaluating and refactoring the initiatives that exist already might be an idea?

-- SteffenPoulsen - 02 Apr 2006

What made me think about it was when I found myself briefly describing the project I'm working on as part of an answer to one of your questions. Had there been somewhere more appropriate -- like a showcase web -- I probably would have put that part of the answer there, with a link to it, and then elaborated on it later on. Besides sharing with you guys -- and anyone else stumbling across it -- what I'm working on for my first major TWiki installation, it would also serve as a place to reference when it was relevant to something I was writing in an otherwise unrelated topic. Eventually I might write up stuff about how it was being used, people's reactions, and so forth.

This made me think about other related things, as wikis will often do. I know there are finished projects out there that would show some of what TWiki can do, and that there are probably people who are even earlier along than I am who might find it very helpful to sketch out what they're trying to do. And, of course, it would give a place to point journalists at who are wondering what this TWiki thing can do.

As is often the case with wikis, who knows where it would go? Perhaps no one would use it, in which case it would be a small-cost failure. I'd like to think, however, that people would enjoy a chance to show off what cool things they've done recently. It certainly would do TWiki more good if I were pointing people to a page of Lynnwood's describing how he developed his museumconnection site than what I do now, which is to point them directly to his site.

I understand why coding decisions often have to "prove" themselves. It feels dreadfully anti-wiki to have to have a long debate and/or to have to "prove" that a showcase web is a good idea rather than just creating.

-- MeredithLesly - 02 Apr 2006

I've created the new web: http://twiki.org/cgi-bin/view/Showcases/WebHome
It is hidden from the weblist.

-- ArthurClemens - 02 Apr 2006

I am just back from a day trip. In a speechless mode, puzzled that a new web has been created before getting clear on the needs, before getting more feedback, and inspite the fact that I stated several times that I do not favor new webs on twiki.org.

I studied the three competitor examples, they follow somewhat different goals:

• Wetpaint: The wiki hosting company lists 5 customer sites (out of many more), each with their own domain name. Purpose: "See how our customers use our hosting service; start your own site"
• eTouch: The application page lists applications, each with one paragraph for introduction and a link to more details. The "more detail" page lives in a "sandbox wiki" and shows a static view of what could be done (links not working). Visitors can browse top down, or from one detail to the next. Purpose: "See our pre-canned applications; sign up to use our service"
• Jotspot: Application gallery index page. Each application has a one paragraph summary, screenshots, bullets with values, and an "install now" button. Purpose: "See our pre-canned applications; install and pay for our service"

Wetpaint is simply highlighting a few customer sites. In TWiki's case, we could highlight a handful sites out of the large TWikiInstallation directory. This is of value, especially to give a good first time impression in the early evaluation phase. This can be a CoolTWikiSites SupplementalDocument topic, linked from the twiki.org home. Does this one topic warrant a new web?

eTouch and Jotspot are highlighting their applications in a gallery. TWiki.org does not have that yet for TWikiApplications, but we have that for Add-ons, Skins, Plugins and Contribs. So, this is a question how to package TWikiApplications, and how to present them nicely, where to store them, and how to install them easily. Related discussions are at TWikiAppPackageHowToDiscussion and TWikiExtensionInstaller, proposed index page at TWikiAppPackage. Does that warrant a new web? If so, is it intuitive to browse all skins, add-ons, plugins and contribs in web A, and the apps in web B? How does that affect linking? How does that affect listing all, say, "security" related apps/add-ons/skins/plugins/contribs? What about application components? How are lego-blocks packaged and assembled into an application?

Highlighting customer sites and packaging/presenting TWiki applications are both important. Do they warrant a new web?

Now, as for the stated goals, the question is to get "a place for". This is a good question, but is "place" = "web" the right approach? Lets see:

• "A place for people who have done cool things with TWiki to show them off (I'm talking installs, not plugins)"
  • This is adressed by the "packaging/presenting TWiki applications" question stated above. Proposed place is the Plugins web (since last summer). In addition, some cool apps can be highlighted in a CoolTWikiApplications gallery, done as a SupplementalDocument topic. Is the idea to highlight some apps, or list all apps? Is the idea to show just an introduction what the app does, or to show a live app? How to handle apps that require their own web(s)? How to handle apps that require special users? How to manage live application that have dependencies on CPAN etc? What about the performance of TWiki.org? What about the stability of TWiki.org?
• "A place for people who are developing cool things using TWiki to show what they've done so far and ask for suggestions and help"
  • In the early phase it is important to get feedback early. This results in better products. The right question to ask is: Where can we brainstorm and try out applications before they are packaged and presented? This has been the Sandbox web so far; there are already many sample applications. Some applications are packaged in the Plugins web as well, for example DiscussionForum in Sandbox web packaged as DiscussionForumAddOn. People are complaining that twiki.org is a maze. Doesn't the maze get bigger if we add a new web? Is it a good practice to mix work in progress stuff with presentable stuff?
• "A place for people who wonder what kinds of things have been done and can be done with TWiki"
  • In other words, browse a gallery of applications, e.g. the "packaging/presenting TWiki applications" question. If in a new web, how does that relate to compontents and plugins?
• "A place for the press to see how cool TWiki is"
  • This is stated in CustomerFocusedTWikiOrg, we need a place where press/analysts can see the benefits of TWiki. Key point is to make it short and precise, show facts and benefits, and positioning to competition. This can be done with a few SupplementalDocument topics, linked from the twiki.org home page. Do the few topics warrant a new web?

One customer facing point is missing: A TWikiTour, proposed in CustomerFocusedTWikiOrg. So PleaseCreateTWikiTour that will help sell TWiki to people who evaluate different wikis. Evaluators narrow down early on a few wikis, so a good first impression is very important to be in the game. This is a low hanging fruit that can be done relativly quickly.

On new webs, Crawford and I try to keep the number of webs to a minimum since many webs introduce a new set of problems, as stated elsewhere. My goal is to make it easier to find content on TWiki.org, and I am consistently working on this (with a clear doc entry point, SupplementalDocuments, tagging and more.) I am concerned that a new web will make the maze bigger.

Based on this research I removed the Showcase web (the web was empty.) Once we are getting clear on the needs and get feedback from a few more people, we can re-create the new web (if we see that this is the right approach.)

-- PeterThoeny - 03 Apr 2006

I wonder what is the need to remove the web already. You might be puzzled on finding a new web; I don't find this constructive either. Please keep in mind what the goal is for this web: to promote TWiki and to give existing TWiki work in the wild a place.

Forcing things seems to be the only way to get things done. This is true for coding and for ideas. Tags have been implemented on twiki.org without discussion either. This is not bad - it must be given a chance to see if it works or not. In my former occupation as visual artist I used to say "I don't know before I've seen it": all learning is by trial and error.

At one more attempt (see for other motivation CustomerFocusedTWikiOrg) I want you to look at the competitor's sites and see how the showcases have a very prominent position in the navigation. Now these sites are not a wiki, they have a wiki to showcase. So the situation is different. The TWiki equivalent to a navigation section is a web. A web makes sure it can be found in other webs through the web list. Merely a pointer to a page will get lost. At least a simple and lean main navigation is needed for twiki.org.

It might be clear that Codev is not the right place to show off TWiki. Speaking of mazes, I don't see that structured quickly. It might be good for developers or intranet, but it really does abhor the new and casual visitor.

-- ArthurClemens - 03 Apr 2006

Steffen, is your above list excluise or are any of the above methods of demonstrting and illustrating the application acceptable? How about adding a movie or flash as many 'marketing' sites do?

• This falls into a) in my view, updated description to avoid misunderstanding. -- SteffenPoulsen - 03 Apr 2006

-- AntonAylward - 03 Apr 2006

Quoting Peter, "Highlighting customer sites and packaging/presenting TWiki applications are both important. Do they warrant a new web?" My answer is a tentative yes. Every web on this site is cluttered and overloaded and most pages are unattractive and uninviting. If this were my product, I would be embarrassed to send people here. (Not to mention that two months after the release of the new version the site is still running the previous one.)

Peter: "People are complaining that twiki.org is a maze. Doesn't the maze get bigger if we add a new web?" No. New webs that are well-named create clear entry points on the sidebar that have a name that's meaningful, not ones are misnamed due to historical reasons that are meaningless to anyone who isn't deeply involved with TWiki.

Peter: "A place for people who wonder what kinds of things have been done and can be done with TWiki". I'm sorry I wasn't more clear in this bullet point, but it was written up hastily after more than an hour discussing it in the channel while you were logged in, although either silent or absent. I was referring to installs like Lynnwood's museumconnections site and what will shortly be a major install at Harvard, not plugins and the like.

Sites are very different from plugins or pre-packaged TWiki applications. They certainly don't belong in either a web named "Plugins" nor a Sandbox that might be raked at any time. The way twiki.org is set up and, apparently, will always be set up, means there is no appropriate place to show off (in words and images, not a full site!) interesting sites created using TWiki.

I am disappointed that you did not give this experiment a chance and relieved that it's gone before I wasted the time I intended to spend on (the start of) my contribution to it. It was empty because it was there a mere few hours before you removed it. Arthur intentionally made it invisible to the outside world so that people like me could experiment without it having an impact on users' experiences until it had proven itself or shown that it didn't work.

Those of us that have design and writing skills as well as programming skills will continue to create clean, uncluttered sites and rewrite existing TWiki documentation to make it understandable to the ordinary user. It's just too bad that none of this will be allowed to be contributed to the TWiki community via twiki.org.

-- MeredithLesly - 03 Apr 2006

Thanks for clearing up the "what". As Codev accepts both words and images, I don't see any problem embarking on the journey using that, and keep the namespace discussion going as a parallel track.

-- SteffenPoulsen - 03 Apr 2006

Sorry, Steffen, but I am not going to add to the rat's nest that is Codev. Not to mention that oft-quoted CoolUrisDontChange, which means anything that I did successfully would wind up having to live there forever, just like everything else in Codev and anything that wasn't successful quickly enough would be labeled "more cruft from Meredith". Lose-lose, and I'm very tired of that.

I don't get this terror of creating new webs. If you want to live in a loft where bedrooms, kitchen, living room, den, and everything else is in one place, fine. I happen to like having different rooms for different purposes.

Come to think of it, why is Bugs not in Codev too? Horrors, another web! Worse yet, another URL to another web.

-- MeredithLesly - 03 Apr 2006

Steffen, you're missing the point. Codev is not the place for showing off sites, Codev is about "CODing & DEVelopment" of TWiki, not a bag for all the homeless stuff that really belong to other place. Even the CoffeBreak, TWikiInThenNews and all that stuff DON'T belong here.

-- RafaelAlvarez - 03 Apr 2006

I just hate to see one thing blocking the other, hence the suggestion on parallel tracks. If this really belongs in a web by itself, I suspect it will be quite clear once it's done. And then even I will (hopeful|probab)ly be able to !miss the point.

What is emminent, is that current strategy seems to only lead to a deadlocked situation (I believe this is the third approach on the same template). I'm hoping that once threads are rolled back again, just a little bitlle something new will be tried for a fourth go.

-- SteffenPoulsen - 03 Apr 2006

Apps need a web each. They need web-level controls and the ability to customise templates etc without fear/planning that they will never clash with the names chosen by another developer.

Trying to fit them into one web is like saying you can demonstrate a set of holiday caravans by squashing the content of all of them into one room. Caravans (and apps) create space!

Caravans have fridges. To the caravan it has "the fridge" not MartinRJCleaversFridge: this is why we label things - to make space.

Webs are in fact called Spaces in Confluence.

-- MartinCleaver - 03 Apr 2006

Nested webs inside Showcase web would be fine for web apps.

-- ArthurClemens - 03 Apr 2006

A few key points:

• As Rafael stated, Codev is about "CODing and DEVelopment." However the Codev web has turned into a grab-bag, a "kitchen sink" web where anything that doesn't clearly live somewhere else has been deposited.
• Stop and think for a moment. If there were a web we could broadly name "Community", how much of what has been inaproately dunped in Codev would rightly be better there, both from the point of appropriateness - and hence ease to find - and from the POV of tighetening up Codev naviagation
  • CoffeBreak, TWikiInThenNews, AJA, ATasteOfTWiki, AccademicTWiki, AdoptTeamworkLogos, AbbeNormal, AcknowledgingTWikiContributors, AcroWiki, AccessibleTWiki, AlphaNews, AllTheWeb,
  • WouldLikeToCheckIn
  • B though Z topics that don't belong in Codev.
• Look at it this way: if we'd had a "Community" and "Shwocase" webs to start with to divide the focus, we woudln't be having this discussion, rather we would be discussion whether a topic had been inappropriately placed.
  • OOPS! We do. We have support topicsthat get placed in Codev and have to be moved to Support.
    • And that's because we give too much focus to Codev, and there's really a very blury line between what should be in Codev and what shouldn't. From the issue tracking POV, given the "old" workflow it makes more sense to post a bug here in Codev rather than in Support. -- RA
• Peter seems to think that more layers of categorization and indexing ppages makes Codev "cleaner". It may make it more navigable - but only to those who already know about these. Lacking a very clear "Main Portal" that is listed at the top of the left bar, along with outher key portals and a "list of all portals" its not going to be visible and of limited utility. The old timers know their way around anyway. The effort of "tagging"/"indexing" isn't going to be any less than the effort of moving to a "Community" web or a "Archive" web.
• When I present about TWiki I find that one of the main selling points is the webs. The Cunninghan model lacks this. From a business POV compartmentalization of function, focus, purpose and managability (and hence the ability to delegate responsibility) is of great value. Yet Peter seems obsessed with not using TWiki's great and distinhguishing strength.

Finally:

• At what point do people decide that Peter is doing "Its my ball so we play by MY rules and ONLY my rules no matter what the community (... of users, developers, admins...) thinks!" and so get pissed off and find something else to absorb their efforts and cotnribute to where they feel part of a community and feel their efforts and feedback are appreciated.

-- AntonAylward - 04 Apr 2006

Yes, a Community web would be great. It would solve a great deal of the rat's nest I keep referring to. It's also where I would put my page(s) about the project I'm developing, since it's far from a "Showcase" stage.

It would also be nice if the "It's my ball..." stuff were made explicit, so people coming in to contribute would know the rules ahead of time and be able to decide whether they wanted to play.

-- MeredithLesly - 04 Apr 2006

The trouble is that Peter's "inflexible" rules have been broken, so one wonders why he continues to act as if they were inviolate:

• There in the Webs list on the left menu bar you can see some recently created webs, archives to old versions of TWiki & documetnation.
• The 'backward compatability' that Peter obesses about has already been broken by the way Dakar interprets many constructs - the use of a blank content to ALLOW/DENY settigns being just one example.

Its not as if we are talking about spinning webs as if we were hordes of cocaine-hyped spiders out of a novel by John Whydham. We already archive topics in Codev and Plugins when they get too long and their early content gets out of date. The trouble is that the way we do so just clutters up the current webs even more! Having something like a shadow sub-web for this aged and now irrelevant content makes just the same decision point as moving documentation on old releases to separate webs. If one why not the other? When does this stop being 'conservatism' and start being a 'dog in a manger' attitude?

-- AntonAylward - 04 Apr 2006

And into which web exactly should we put this hypothetical ShowcaseHome topic? TWiki is for doc (god forbid we have our doc someplace sensible like a Doc web); Codev is for Code and Development; Sandbox is liable to get raked. Main is part of standard install.

Personally, I like the idea of Community better anyway. That would be a good place for ShowcaseHome.

-- MeredithLesly - 04 Apr 2006

New users would see "Community" and never figure out by themselves that there would be showcases under there. No, Community and Showcases both deserve their own space.

-- ArthurClemens - 04 Apr 2006

As someone pointed out, Showcases could be on the left bar (which needs to be considerably trimmed down, however). Either way is fine with me. Community is less flashy and so could be brought up to speed more quickly, however.

-- MeredithLesly - 04 Apr 2006

As an enthousiastic TWiki admin with under-average admin / coding / design skills I would love a Community web where people can show their TWiki-work. I can judge if something is useful for me, but only when I see it in action.

I have a feeling that people have built great things using tools like CommentPlugin which I would love but could never dream up.

That said, of course the usability of such a web is totally depending on people willing to share their stuff. Small examples like SearchPatternCookbook (which is 'just' about 'trivial' combinations of SEARCH and regexps) show the value of sharing examples ready for copy/paste by the less knowledgeable.

So if there are people who want to try to fill a Community web, they have my support!

-- JosMaccabiani - 15 Apr 2006

That's great! That's exactly the kind of thing I was talking about. We all have these little pellets of knowledge which would be great to share with others, knowing that we'll get pellets back as well.

-- MeredithLesly - 16 Apr 2006