[pmwiki-users] Input recipe

[Martin Fick]

> I do think that in most cases, it's just the admin who's supposed to 
> edit a form page, though there are exceptions:


** I think that is a uneccessary role assignment to admins
   only.  It's probably a big reason why so many UIs suck! 
   Only the 'blessed' few (programmers or administrators)
   can adjust and modify them.  That same difficulty with
   HTML led to outdated websites that did not meet users
   needs, wikis address this well.  Web forms need to be
   flexible and adaptable by the users or they will never
   evolve and improve either.



> >-Tabular data editing where any row can be edited as a separate form.
> >This could even mean editing a DB! [...] the front end can adapt to
> >how the users think best fit.
> 
> (I read that as "users can adapt the forms to their taste", though it's 
> not what was meant originally - but it's surely an interesting application.)


   Yes, that's exactly what was meant. :)



> >-Create a form that adds pages to trails so that a user
> > does not need to understand bulleted lists to edit a
> > trail.
> 
> Not a good idea IMHO. One of the things that makes wiki trails useful is 
> that you can have trail info and running commentary intermixed; 
> "formalising" that into a form page would destroy that functionality.


  I'm not sure why you think it would be lost, the original
page wold still exist but a additional form page would help
users who don't even know that you are running a wiki.  But
wait, that's the wrong answer anyway; if the form lost
important functionality, the users can add it back in
themselves by improving the form!



> >-Create a form that breaks a page into multiple sections
> > that each get edited in a sepearate input box.  Think of a
> > page describing a photo with a title section, a
> > description section, a categories section, a rating
> > section...
> >
> >-New page templates, like above.
> 
> Been thinking about that :-)
> 
> Still in the administrator domain.
> ("Administrator domain" has two consequences: (1) it's just a single 
> person who's supposed to learn and type that markup syntax; (2) the 
> markup is written or modified very rarely, so the case for easy syntax 
> isn't very strong - better keep those simple syntaxes for other features.)


  Again see ** above


> >  Some of these cases could be serviced by very simple safe
> >backends that would support the creation of an unlimited
> >amount of forms.
> 
> I think there are two cases:
> 
> 1) the backend stuff you mention above. If I understood you correctly, 
> that would be defining another markup that generates the appropriate 
> (:input...:) markup, which would then be further translated to the 
> appropriate HTML code.
> If you really insist on doing the --...-- markup, you could do even do 
> that - PmWiki is flexible enough that you can define your own markup :-)

  I'm not sure I'm following this, what I meant was: that
there could be some simple generic backends that: knew how
do edit a DB, knew how to edit templated wiki pages and
that knew how to email forms to people.

  I agree that pmwiki is flexible enough for me to define
my own markup, I'm just not sure I'm smart enough :(. I
guess that's why I'm trying so hard to get others on board.
If anyone else thinks it's a decent idea I will start a
wiki page where we could work it out, but I'm not sure
anyone else is.  I am probably just deluding myself. :) 
Anyone, anyone...??



> 2) One-shot forms ("administrative" ones). Syntax is of secondary 
> importance, giving access to as many useful capabilities of HTML as 
> possible is more relevant.

  I'm still not buying this hardline admin/user split.

  -Martin