[pmwiki-users] New PmWiki Features Page . . .

Sandy sandy at onebit.ca
Wed May 31 12:52:27 CDT 2006

Ben Wilson wrote:
> With Pm's nominal support, I have rewritten the PmWiki Features
> page.[1]  This email is a request for peer review.

Wow! What a lot of work! What an incredible product Pm's created! Ben's 
put a lot of work into this page.

Can't say I'm a peer, but I've written tons of documentation for and 
with people who hate to read documentation.

We need a much shorter page for the _entry point_. First impression 
should be "Neat! I want to learn more," rather than a huge list of 
features and big words to slog through. Think cover letter, resume and 
job interview. What are the top ten good things new users (admin and 
authors) say about PmWiki?

Link to the detailed features page from the entry page. Even better, for 
each point made on the entry page, link to the right spot on the 
detailed features page.

Put the philosophy right up front. Everything else comes from that. It 
was the philosophy that got me hooked, and how well it's followed that 
kept me.

Make the release date (in General Features) dynamic (like the version 
number) rather than hardcoded.

Replace the repetitive phrases in the tables ("Built In", "Plug In" and 
"Not Yet") with three labeled columns.

Keep the bold nouns starting each paragraph; easy to tell if a paragraph 
interests you without having to read every word. Next level of 
refinement: make the first few words consistent. Start with the same 
type of word (noun, verb, adjective).

The Syntax Features section is great! Quick to read. Shows the size of 
the cookbook and the flexibility of the product.

(Note how most paragraphs in this post start with verbs, and which ones 

Fix Footnotes and Quoting paragraphs; they talk about feed aggregation.

Shorten paragraphs. Chop the veribiage.
Conflict Resolution. In an effort to support multi-user, simultaneous 
collaboration, PmWiki has a simple conflict resolution system. When a 
page has been edited while an author has been revising a page, PmWiki 
flags the sections where the text conflicts. The author has the ability 
to save the page with the conflict still marked, or he may resolve the 
conflict on-the-spot. See PmWiki:Simultaneous Edits for more information.

Compare to:
Multiple Simultaneous Edits. The first author to save does so as usual. 
The second author to save is given the choice to save the page with 
conflicts marked, or he may resolve the conflict on the spot.

Yes, it will be difficult to decide which common needs that aren't met 
should be addressed. In most cases, the need is either met indirectly or 
conflicts with another need.

E.g., Rollback on a database. Quick answer is "not supported". Longer 
answer: Each page keeps a history and you can revert to a previous 
state. You can also list recently changed pages.

PmWiki meets the intention (except for mass rollbacks, for which they 
should haul out their relevent backup.)

Keep most points under 50 words. If necessary, link elsewhere to refine. 
A link to a newsgroup post is fine -- shows we've got an active group 
and much forethought goes into the work.

Leave out "at this time" and "at present". That is assumed.

Download size
Farms. Easy to expand to many wikis supported by one copy of the engine.
Save As Draft feature.
Multiple Skins. Set by user or authorization level or page group, or let 
the user choose their own.
Plugins and Upgrading. Plugins do are done via configuration files 
rather than changes to the core code, so the core can be upgraded 
without losing the plugins.

Fix: It is believed PmWiki will serve pages on computers that support PHP
s/be:  on all computers that...

Make sure that all terms used on the features page are also used in the 
documentation. E.e., if I want more information on Mail Encryption and 
there's no link, I should be able to find it by searching the PmWiki 

Overall, Wow!


More information about the pmwiki-users mailing list