[pmwiki-users] NEW RECIPE: EditMore...

[Ben Wilson]

On 8/31/07, Mike Shanley <up at upisup.com> wrote:
>
> > Best way to do it is not to implement any features of MediaCat and
> > allow individual admins to enable that feature. MediaCat only affects
> > display by collecting and styling categories, not ROS/ROE. Your tools
> > seems focused on editing and should therefore probably avoid display
> > where possible.
> >
> Well by this logic, I don't suggest updating MediaCat at all. If this
> option is pursued, it would be easy for me to place categories list in a
> hidden div and be done with it. However, the very fact that it's GOT to
> place things in a div leaves one to wonder why it /wouldn't/ allow a
> user to display it as he wants.

Why does it *have* to put the categories in a DIV? Is this a software
constraint, or a feature request by a subscriber? As I understand it,
your tool adds a text field for authors to add categories. On save,
those categories are "categorized"[1] then added to the page text
($page['text']). It is a simple enough thing to add the categories at
the end of page text ($page['text'] .= "\n\n".implode("\n",
$form[categories])."\n";[2] This behavior can be tied with MediaCat
that allows the categories to be displayed in a DIV at display time;
even with a div set to display:none; and toggleable with javascript.

My point is this: there exists a tool that already provides styleable
arrangement of categories. Your tool is an edit-form supplement. As a
developer, the edit-context should be less concerned about display and
more concerned about edit, just as MediaCat does not do its display
function as an ROS. MediaCat is unconcerned with edit context so long
as the categories are displayed in PmWiki-standard markup.

What if somebody wants to use your excellent editing tool, but does
not want a special display feature? Giving them a choice to dump the
categories at the beginning/end of page['text'] will capture 80% of
your potential subscriber base. Allowing the combination of its
categories behavior with MediaCat will likely capture 15% more of your
base. Forcing both behaviors on your subscriber base will lower
potential interest and not reach the 85-95% subscriber base you'd
like.

The strength of PmWiki overall is that so much of it is customizeable
to satisfy a wide audience range. Maybe 60% are content with the basic
features; the balance use recipes. Providing recipes that complement
one another improves overall consumer experience. That is why I asked
you to discuss how you think MediaCat could be improved to help you
satisfy your subscriber base.[3]

[1]: Converting from user friendly "MyCategory" to "[[!MyCategory]]".
[2]: Only one newline translates as a space when converted to HTML on display.
[3]: I avoided saying "user!" Oops, I just did.
-- 
Ben Wilson
"Words are the only thing which will last forever" Churchill