[pmwiki-users] New PmWiki Features Page . . .
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. 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
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.
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.
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
More information about the pmwiki-users