User talk:Cretep

Blue-sky thinking on Extension:Semantic Forms

Existing strengths & weaknesses

SF achieves a few fantastically helpful things

1. Suggesting which templates the user will need to create an article with a particular class (eg. each Item class should have one Item and one or more Opinion and Reference templates)
2. Assisting the user to input data in in a fast and accurate way (eg. autocompletion on references to preexisting articles, map selection)
3. Verifying the user's input at a property-level (eg. numbers-only property) and template-level (eg. the Item template can only be used if the Author and Source properties are completed – mandatory)
4. Structuring the visual appearance of input fields and their accompanying labels

SF falls short in a few painful areas

1. Rigid & restricted. Only templates & properties known at the time of creation are included. If an extra template is added to an article manually, it cannot be edited using the article's official form and ends up in the free text section, even if it is a semantically-annotated template that would benefit from a form. This flys in the face of extendable and flexible wiki page content.
2. High Maintenance & Static. If a template and/or class is updated, the form must be updated too. each update requires large amounts of copy & pasting, even if it's just a simple text field which requires no special formatting.
3. Laborious Testing With no one-click "Preview" feature or WYSIWYG, testing requires several steps: edit-save-startform-back-edit.
4. Segregated from content. Adding a whole new interface just to edit metadata removes the familiar editing environment and workflow, and places less emphasis on the bulk of the page content, making it harder to edit the free-structured content around the templates. This seems like an overkill, creating a large learning curve and thus hinders adoption.
5. Semantic Forms are not page forms! Anyone wanting to structure their wiki's content will be disappointed. SF is designed to structure snippets of metadata (ie. infoboxes) and does not facilitate free-structured entry around the templates…

… or does it. hmm.

Proposal based on Extension:WikiEditor

1. Suggesting & Structuring
   1. Replace each current point of entry (ie. wherever [[Has default form::]] occurs) with a list of suggested templates.
   2. When a user hits Edit they are presented with the usual WikiEditor, but now an extra panel above the editor has appeared with a collation of all suggested templates. These could be presented immediately as "lightbox" forms in a wizard-like step-by-step manner. Completion of each template would then add it to the text area. This would fulfil the need to systematically prompt for metadata, without rigidly enforcing it; thus balancing the familiar and powerful free-structure interface with the simple and required templates.
2. Assisting, Structuring & Verifying
   1. Each template would have a header defining its nature and parameters, like the current SF {{{info}}} section. This would be read WikiEditor's template editor in order to display the template usefully.
      • Some template paramaters would just need to be listed. They would not need manual attention (a "geographical coordinate" type property would automagically present a semantic map, restricted value type properties would automagically present a select box, numerical type properties would validate only numbers)
      • Paramaters requiring manual attention could be described by a {{{field}}} entry just like the current Form namespace, only it would be in the template text rather than in a separate namespace. This "template metadata" would be invisible when transcluded.

   As a result, the information on how to structure and verify the properties would be:

   • on a need-only basis;
   • for a single template;
   • next to the data they are presenting, removing laborious fragmentation;
   • instantly accessible to any page wanting to insert that template, regardless of category or namespace;
   • removing the mountain of unnecessary table structures required to make a presentable form.

Pete C 21:48, 3 March 2011 (UTC)

TODO: Determining order of presenting templates

TODO: On new page, which categories should be used to suggest templates?

Therefore need a skeleton that outlines which forms to use, like current "Create New Form X" sidebar links

Pete C 22:55, 3 March 2011 (UTC)