[pmwiki-users] Re: Perfection and Menus (WAS: on over-bundling) . . .

[Sivakatirswami]

As a complete wiki novice, now wiki admin, who does not know PHP 
(daring, but possible, thanks to PM's framework) but long HTML and 
xTalk coder, dealing with dozens of totally "naive" wiki users, some of 
whom will become "admins" in their own areas,  for whom GUI  point and 
click, mark up tools are standard on most any other mark up interface 
they might have dealt with (InDesign CS, GoLive, DreamWeaver, BBEdit, 
etc. ) I would second these...
>
>> installing PmWiki for the first time can easily get
>>     their wiki to act like what they saw at pmwiki.org
>>
>> to bring something into the core if only to provide (and commit to) a
>> standard that others can reliably build from.  (The GUI bar falls
>> into this category, as will user authorizations.)
>
Mark up is at the core of wiki usage, tools to do that obviously belong 
there. As soon as I see "cookbook" and "install this 
fooGreatNewGadget.php"  etc. my lens implants fog up. Of course, they 
will clear up eventually, but we need to fly this bird today. We have 
to constantly "battle" against the tendency create frameworks that 
reflect our own personal advancements,  while leaving others behind. 
The result is, almost always, you will do *all* the work.

I too examined many wiki options and the PM philosophy "continuous 
usablity by naive users while simultaneously advancing toward more 
complex implementations." was the fundamental to the choice.

Thank you, PM....

Sivakatirswami
Himalayan Academy Publications
at Kauai's Hindu Monastery
katir at hindu.org

www.HimalayanAcademy.com,
www.HinduismToday.com
www.Gurudeva.org
www.Hindu.org
>
> On Mar 9, 2005, at 1:10 PM, Patrick R. Michaud wrote:
>
>> On Wed, Mar 09, 2005 at 05:03:02PM -0500, Radu wrote:
>>> Not much. But the steps to take if you want to enable a gui bar are
>>> different than for adding any other recipe.
>>
>> But not any different than enabling or disabling other features
>> that use the $EnableXXX convention.
>>
>>
>>> And anyway, if they're 0
>>> disabled, why are they bundled in the first place? If your answer is 
>>> 'for
>>> convenience', then why not bundle lota of other often used recipes - 
>>> and
>>> leave them disabled?
>>
>> Well, it comes down to two very practical considerations:
>> (1) If a feature is globally enabled on pmwiki.org, then I think it's
>>     a good candidate to be in the distribution, if only so that
>>     someone installing PmWiki for the first time can easily get
>>     their wiki to act like what they saw at pmwiki.org
>> (2) Some features have dependencies in the order in which they are
>>     loaded or executed -- in these cases it's often easier if I
>>     pre-configure certain features.
>>
>> A third consideration is whether the feature is likely to be used
>> as a basis for other recipes and features.  In this case it's useful
>> to bring something into the core if only to provide (and commit to) a
>> standard that others can reliably build from.  (The GUI bar falls
>> into this category, as will user authorizations.)
>>
>> Beyond that, almost any feature could be considered "extra" to 
>> someone,
>> including search, trails, categories, etc.  I just measure the
>> relative utility of the feature versus the difficulty it might
>> pose an admin to install (PmWikiPhilosophy #5) and take my best
>> guess from there. And nearly every core feature can be easily
>> disabled if desired.
>>
>> Pm
>>
>> _______________________________________________
>> pmwiki-users mailing list
>> pmwiki-users at pmichaud.com
>> http://pmichaud.com/mailman/listinfo/pmwiki-users
>>
>