[wiki-standards] Hello - request comments on Creole

Mon Jun 2 21:37:00 CEST 2008

Mike Haseler wrote:
> Marc Laporte wrote:
>> Hello Mike,
>>
>> I am not sure I understand your aim ("to create a basic form of 
>> format that can be used across a wide range of applications from 
>> wikis, to blogs, to message boards, to private messages, to adverts 
>> for houses, to address lists for scouts").
>>
>> That sounds like a Content Management System. There are over a 
>> hundred Open Source systems that you could work with:
>> http://www.opensourcecms.com/
>
> My aim is fairly simple to have:
>

Hello Mike,

I will throw some links for the system I am working on (TikiWiki 
CMS/Groupware). Some other people may have some links handy for other 
solutions.

> 1. one (or many) bulletin boards

http://doc.tikiwiki.org/Forum

>
> 2. one (or many) simple wikis

http://doc.tikiwiki.org/Wiki

> 3. An events calendar (AS A LIST!!!)
http://doc.tikiwiki.org/Calendar

You can list upcoming events as a list in a wiki page or in the calendar 
interface
http://dev.tikiwiki.org/Upcoming+Events
http://dev.tikiwiki.org/tiki-calendar.php?viewlist=list
http://dev.tikiwiki.org/tiki-calendar.php?viewlist=table

> 4. a directory of local organisations/company

http://doc.tikiwiki.org/Tracker
Can also be used as bug/issue tracker

> 5. email groups

http://doc.tikiwiki.org/Newsletters

> 6. Web statistics

http://doc.tikiwiki.org/Stats

> 7. Games

http://doc.tikiwiki.org/Games

> 8. Pictures

http://doc.tikiwiki.org/Image+Gallery

> 9. Games

Again? :-)

Above, you mentioned:
http://doc.tikiwiki.org/Inter-User+Messages
http://doc.tikiwiki.org/Blog

And hundreds of other features and options. More than you'll ever need :-)
http://doc.tikiwiki.org/Features

>
> This is going to be reproduced half a dozen times over a number of 
> small sites I produce.
>

To manage a large number of instances: TikiWiki Remote Instance Manager
http://dev.tikiwiki.org/TRIM

If you want to share logins, groups and preferences throughout many 
TikiWiki sites, you can use InterTiki.
http://doc.tikiwiki.org/InterTiki

> The aim is to have all the applications protected (or enabled in the 
> case of games with user-highscores) by a single username/password with 
> a central interface for decide which groups have what privileges for 
> which applications. E.g. only scouter leaders can post emails but 
> anyone who belongs to the group "scout parent" can see and subscribe 
> to the scout newsletter.

http://doc.tikiwiki.org/Permission

>
> Also anyone who registers for the scout email newsletter automatically 
> joins the group and can use their password to post on the bulletin board.

http://doc.tikiwiki.org/Tutorial:+Registration+and+Login

>
> If you are mad enough to want to play one for games on the website, 
> you will get your own highscore.

hehe

>
> YES the idea includes aspects of a content management system, but if 
> there is a content management system that plays dungeons and dragons, 
> then it ain't a content management system. To repeat, the central core 
> of the system will be one username, one password.
>

You should focus your energy on the D & D aspect. Using the CMS for what 
it does and using it as a framework for what it doesn't (templates, user 
system, etc)

It don't think it can get much easier than this:
http://dev.tikiwiki.org/Hello+World

> Secure once - play many!
>
>>
>> By choosing an existing system, you'll get already mostly debugged 
>> code. You also have the opportunity to share your work & experience 
>> with a community.
>>
>
> If only people had started by writing a universal password 
> authentication system and then most wikis, bulletin boards, etc. etc. 
> worked with one password and it was simple to add your own 
> application. Then I would be extremely happy.
>

Yes, me too. But I gave up on waiting for this about 5 years ago. Maybe 
OpenID will help here...

I think the simplest way to single sign on (SSO) is to have an 
all-in-one system. Besides, it's not just for the login. Other problems 
include:
1- Different look & feel, different User Interfaces (UI)
2- Many applications to manage, with different release schedules
3- Several search engines
4- Several navigations
5- Different category systems which make it very difficult to have a 
"what's related" system or tags
6- Very difficult to have a what's new since your last visit (for all 
the features)

Fight back against "Frankensite"!

More on this topic here:
http://www.marclaporte.com/TikiSucks

>> Your analogy to a toupee made me laugh. On a related note, here is to 
>> encourage you to pursue your quest to offer wiki syntax:
>> http://dev.tikiwiki.org/Why+Wiki+Syntax+is+Important
>>
>
> The way I see it a wiki is just a bulletin post with a history and 
> without the replies. A content management system is just a wiki. A 
> directory is just a bulletin board with some added bits of information 
> like name, address.
>

I think you are oversimplifying. A wiki has plenty of subtle 
functionality which give it its magic. Be it backlinks, the syntax, 
basic programming functionality (ex.: different content per group), wiki 
history, notification of changes, section editing, etc

Please see here for a nice list:
http://www.wikimatrix.org/

> I already use the bulletin board as a directory and as an events 
> calendar. To be honest it is utterly crap, but whenever I look at the 
> bulletin board (PHPBB) I just find mods to put calendars on the 
> bulletin board, and if I look elsewhere I find unknown software, with 
> new text entering syntax, new user-interfaces and with a TOTALLY NEW 
> PASSWORDS and totally incompatible authentication methods.
>
> AND MY RULE OF THUMB IS THAT USERS WILL BE PUT OFF USING MY SITE IF 
> THEY HAVE TO ENTER EVEN ONE PASSWORD - LET ALONE ENTER SEVERAL 
> DIFFERENT ONES AND REGISTER SEVERAL TIMES!

Yes, and it's chaos because your users don't follow and group management 
is too much work. Some systems don't support embedded groups (groups in 
groups)

I think adding certain functionality as an afterthought will be 
fragile/clunky forever. Which is why, early on in TikiWiki's history, I 
pushed the idea of adding many features. Even if the features were very 
incomplete or buggy at first, over time, they evolved, improved and the 
integration with the rest is very tight.

5 years ago, TikiWiki documentation was already 350 pages.
http://doc.tikiwiki.org/files/Tiki.pdf

It's now nearly 1000 pages
http://doc.tikiwiki.org/files/Tiki19beta.pdf

We have about 30 Use Cases at various level of quality. Within 2-3 
years, they will all be pretty good (As & Bs)
http://info.tikiwiki.org/Use+Cases

>
> Obviously PHPBB doesn't have the right markup for a wiki, but there is 
> no reason why wiki markup should not be used on a bulletin board.
>

Agreed, which is why the wiki markup works throughout the application, 
from the forum to the bug trackers to the blog, etc

> Of course, the biggest problems relate to how the applications all 
> work together. The biggest headache is just letting each application 
> know that the other applications exist. The other real headache is 
> trying to force pre-written applications that assume that the world 
> revolves around them to accept that they are just a cog in the site 
> and not the whole site and E.g. if a user "joins" the site, the system 
> has to allow the user to be a "site member" without having initialised 
> their individual application data.

I came to that conclusion 5 years ago. Sometimes, it's less work and 
more future-proof to re-write than to integrate.

>
>> IMHO, you should not be trying to write a parser from the specs. You 
>> should join an existing initiative, be it a wiki engine or a parser:
>> http://www.wikicreole.org/wiki/Engines
>>
>> Best regards,
>>
> YOU ARE QUITE RIGHT AND I MUST UTTERLY MAD EVEN TO ATTEMPT WHAT I AM 
> DOING.
>

Take it as a learning experience.

Now, I suggest you learn from other people's experience and join an 
existing project. These are very popular, full-featured, open source 
projects:

Drupal
Joomla
Xoops/Impress CMS
Plone
Typo3
ezPublish
TikiWiki CMS/Groupware

> THEN AGAIN, ONE OF MY FIRST APPLICATIONS WILL BE A VIRTUAL GRASS 
> GROWING APPLICATION, WHERE YOU WATCH VIRTUAL GRASS GROWING (NO I AM 
> NOT BEING KIDDING - AND YES IT IS ADDICTIVE AND I'VE GOT SHEEP EATING 
> THE GRASS, AND PLANS TO INCLUDE WOLVES EATING THE SHEEP, AND PERHAPS 
> MEMBERS WILL BE ABLE TO SEND MESSAGES TO EAT OTHER AND POST ADVERTS, 
> AND GUESS WHAT - THEY'LL BE USING MARKUP!!

LOL

Which programming language(s) are you using?

Best regards,

M ;-)

>
> Mike
> _______________________________________________
>
> wiki-standards mailing list. wiki-standards at wikisym.org
> http://www.wikisym.org/cgi-bin/mailman/listinfo/wiki-standards
>
> For the wiki-research, wiki-standards, wikisym-announce mailing lists, 
> please see:
> http://www.wikisym.org/cgi-bin/mailman/listinfo

-- 
M ;-)

//////////////////////////////////////////////////////////////
/                                                            /
/ Marc Laporte           <|>          http://marclaporte.com /
/ Avantech.net           <|>             http://avantech.net /
/ TikiWiki CMS/Groupware <|> http://tikiwiki.org/marclaporte /
/                                                            /
//////////////////////////////////////////////////////////////