A tikiwiki-based service is a web service using the tikiwiki software, as LivingPlatform.CA itself does.

Such a service has many advantages in building a mobile task support service?, e.g. a community emergency response team support interface? and a community emergency response team field interface? and a community emergency response team mobile interface? that might be able to do both support and field functions.

LP software requirements

However, a mediawiki-based service has many advantages, including some which are overwhelming, such as potential for live XML import of the GFDL corpus as a whole.

Before Living Platform itself can commit to using it long term to build LivingPlatform.CA itself, there are some significant requirements that are not yet met, i.e.

wikitext standard

Apparently there is now some momentum towards a wikitext standard that would make tikiwiki an effective worn device and intranet portal. Living Platform itself has become a significant driver of that demand.

This would address the worst tikiwiki flaw.

colon for name subspace?s

The "coloned" subspaces like LP: for the LP POV, and each language using its own naming conventions, i.e. English capitalizes first letter and proper nouns only, allow phrases in English to be case-insensitive on first letter only. So this must be the way one links to pages as well (again mediawiki does this correctly).

Also a hard coded solution to making the first letter after the / in any URL be case insensitive would help.

underscore for hard spaces

UNDERSCORE

Some solution must be found also for underscores being treated as spaces in
mediawiki and not in tikiwiki. If they are distinguished they can then be
used for information, as I have used them in the names of the LP menus like
http://livingplatform.ca/_I_will+menu
(using a leading underscore to indicate that this is an LP:control issue).

Solving the underscore problem is central to both mediwiki/Wikipedia
compatibility, and, since underscores make tokens readable without the
need for the horrible WikiWord convention, and are used universally in
both media-friendly URLs that include spaces (I don't see "+" on TV but
I sometimes see "_"), and in programming languages, and in Wikipedia...

That is probably the thing that must be tackled first. Please see this:
http://livingplatform.ca/URL+and+404+problem
or, if you wish the GPC to pay for it, then, this:
http://lp.greenparty.ca/tiki-index.php?page=URL+and+404+problem
http://lp.greenparty.ca/tiki-index.php?page=Green+URI
http://lp.greenparty.ca/tiki-index.php?page=list+of+Green+URIs (unheeded,
leading to massive breakdown in trust, and many bad links all over)

plurals (use of "s")

where the "s", or any plural, is reserved for an automatically compiled list.

http://lp.greenparty.ca/tiki-index.php?page=naming+conventions+for+international
+Green+Party+policy http://lp.greenparty.ca/tiki-index.php?page=reflexive+intranet
http://lp.greenparty.ca/tiki-index.php?page=Efficient+Politics

GFDL corpus-derived services

It would also make it possible to build derived services like wikinfo.org?, nationmaster.com? and wordiq.com? that rely on the GFDL corpus. As it is LivingPlatform.CA itself relies only on the GFDL corpus namespace for name precedents, not content.

This would require live XML import like getwiki.net?.

reflexive specification of menus? like twiki

The total failure of tikiwiki to provide a reflexive way to edit menus or modules is also a requirement. That is, the user interface for this, is a horrid form thing, that simply is not wiki, and does not express itself as wiki pages. Even if the forms remain, the final data structure must *ALSO* be visible as a wiki page, preferably one protected and perhaps only to be read by administrators, but, nonetheless, still within the wiki namespace at a formal default place like tikiwiki:modules? and tikiwiki:menus? and a top-level tikiwiki:control? description for ALL control options. In other words, a "configuration file format" that could be expressed as
an XML DTD?, so that tikiwiki configurations could ultimately be sharable and changeable with other tools.

The TWiki.com? best practice of a reflexive wiki? to show and change control features is making TWiki very popular now. The "control" wiki called "TWiki" provides a
set of wiki-editable variables:
TWikiV and TWikiAT.

short term solution

A near term solution is to replace tikiwiki admin form?s with carefully-templated wiki pages that can be compiled directly into menus - like twiki.com? which is tops for reflexivity.

Each module and menu and combination for a given class of users will have its own .tpl file, and this will be turned into a module, menu, and set of assignments to user groups at click of an Admin's button (under some item like "Compile", the menus/modules would be specified in a script language essentially).

long term solution

TWiki has a whole wiki just for this. Maybe that's a reasonable method if it's named like http://livingplatform.ca/tiki

so the URLs are
http://livingplatform.ca/tiki/wiki:menus
http://livingplatform.ca/tiki/blog:users
http://livingplatform.ca/tiki/wiki:modules
http://livingplatform.ca/tiki/poll:controls
http://livingplatform.ca/tiki/wiki:controls
as is done in LP:all space at Living Platform itself. This will be free-form but maybe provide some
guidance on how to structure the above.

who pays?

As Craig Hubley says: "This is tikiwiki's problem not the GPC's or LP's problem. I think if it doesn't solve it, it will die, squeezed out by reflexive users who want Twiki power, content pigs who want Mediawiki's corpus, incremental change types who favour wikinfo.org over wikipedia. So you can win only by copying all of these right now... There's a lot to do, to turn tikiwiki to do what getwiki.net? already does, what Twiki already does, what mediawiki and MoinMoin already do."

ways services can use tikiwiki plugin?s

1. tikiwiki JABBER plugin? runs a Java applet? to access a local jabber? service - the *MOST USEFUL*.

We need jabber, definitely, without doubt, the jabber userid? will be the interwiki identity standard?, there's literally nothing else it could be.

Also to reinforce user identification and stickiness:

1a. LANG
Displays the text if the language matches
- greeting users and giving them menus in their own language is always
ideal, even if you can't do anything else. Menu translation is painful
but not impossible, especially if one sticks to simple English ("you
can", "I will", "we may", "exit") instead of the usual crap ("external",
"sites we recommend", "capabilities") that pollutes techie-authored webs.

1b. AVATAR
Displays the user Avatar - would be ideal to have this show up when logged
in - defaults should be iconic, cartoony, not at all realistic. Photos
should be discouraged, comic characters encouraged, these work the best.
Read Scott McCloud's "Understanding Comics" to see why.


2. BANNER - a lot of nonprofits swap banners, this drives traffic up lots;
Displays an advertisement banner - entirely fair for nonprofits to display
only public service ads. Standard banner sizes only I hope, it's worth
the effort to create such banners and send them to other nonprofit sites.


3. all the interesting things to embed in a themed box on any page

theme styled box displaying categories, on-page menus, and "learn"

title=>Title,bg=color,width=>num%)}Text inside box{BOX}"
href="tiki-index.php?page=PluginBox&bl" class="wiki">BOX
Insert theme styled box on wiki page - this for about LP, our LP, my LP
but I called them "on-page menu" or "embedded HTML menu". Theme styled
box is a better term I thihk. Will modify. LP assumes is another one.

3a. MODULE - used when the intended box is an exact copy of the module!
Displays a module inlined in page. An Example that shows the use of this
Plugin is PluginModule

3b. CATEGORY
Retrieves and displays the objects that are in the selected Category.
- this might replace many or (someday) all of those "all...?" pages.

3c. CATPATH
Retrieves and displays Category Path links for the page - these "paths"
could be how we implement the "learn" facility. If they work like
wizards.

3d. POLL
Displays a poll inlined in a page.
A poll should never be seen anywhere other than in a page, associated with
say an article on a topic (so that those who read the article take the
poll, and no one else), or a daily poll as a module at the bottom right,
near the exit module.


4. live XML import, live RSS import, framing of RSS pages

SNARF
Displays another page on the web inlined in a page.

COPYRIGHT
Inserts copyright notices - useful for bottom of page, bottom of column
of menus, since, the content and menus and CSS may all be different (C)
- but mostly useful for materials being imported from other services:

FANCYTABLE
Displays a table that has alternating row background colors - this is
useful for some types of presentation, for instance this great page:

http://en.wikipedia.org/wiki/results_of_the_Canadian_federal_election,_2004:All_
on_one_page

However, I do not believe it is wise to put energy into this kind of thing.
Wikipedia, nationmaster.com, do it so well, and the GFDL corpus has so much
information in it, it would be really a bad idea to try to reproduce it. It
is like wikinews - not something we want to do.

5. mobility features

INCLUDE
Includes a Wiki Page in another object - like the printable version that
you have to preview before faxing? before generating the PDF version?

I see this as being useful in combination with &mode=mobile, so that you
have pictures of various PDAs, popular worn devices, and you include the
page in a picture of that object to see what it will really look like on
that object. I assume one can change the parameters of &mode=mobile to
put that picture around it?

6. classifying articles based on their vocabulary level, politics, etc.

GAUGE
Displays a graphical gauge - only really useful in combination with some
facility to count use of certain words in comments, diffs and user pages.

ARTICLE
Displays fields from an article - might be useful for keywords on pages?
Right now we have a plan to do this with header tags:
http://livingplatform.ca/header+tag

Or to track any bias associated with words. If there is a political
personality test, then, documents also have such personality, ultimately.


7. page lens

Once you know what the bias is, maybe you can figure out more things about
it...

REGEX
Performs regular expressions on data referencing a wiki page for the
regexp.

8. semantic webs, semantic social networks

USERCOUNT
Displays the number of users in a group

WIKIGRAPH
Renders a graph based on Wiki links

in combination, this could render a graph, figure out which groups were
editing which documents (maybe even viewing which), display affinities
between groups based on document interest, focus attention, and so on.

Obviously useful because of social capital potential
http://livingplatform.ca/social+capital
http://livingplatform.ca/social+network
http://livingplatform.ca/power+network

9.reflexivity

CODE
Displays a snippet of code. (Set optional parameter ln to 1 if you need
line numbering feature.) - this is how our own mods should be documented
if this is how tikiwiki in general seeks to handle code more reflexively
SF
Displays a tracker summary from Source Forge - keep the code and tracker
together, so that at least one properly named page always has both

10. long pages in conventional PDF-like style

SPLIT
Splits a page in multiple columns

ALINK/ANAME combination makes it easy to have those long report pages,
like essays or position papers or those ultra-long analyses of the
internal politics of the Green movement (which I believe is the single
hardest problem one can write about, and, I think I can prove that) ;-)

ALINK
Puts a link to an anchor in a wiki page. Use in conjunction with the ANAME
plugin, which sets the location and name of the anchor

ANAME
Puts an anchor into a wiki page. Use in conjunction with the ALINK plugin,
which makes links to the anchor

---

Things that have obvious or subsidiary uses.

SHEET
Inserts a TikiSheet

SORT
Sorts Input to Output

SQL
Displays the results of a SQL query

TRANSLATED
Generates a simple link to a page for translated content