Recent Changes - Search:
PITS /

00308: improvements to edit form

Summary: improvements to edit form
Created: 2005-01-31 08:14
Status: Closed - added for 2.0.beta44
Category: Feature
From: Pm
Assigned:
Priority: 54
Version: 2.0.beta20
OS:

Description:

I've gone ahead and closed this pits issue because many of the items have been address in beta44. If there are any remaining issues, open new PITS entries for them. --Pm

Goal

To provide a single point of discussion for suggested improvements to the Edit Page. Most (all??)of these points were initially discussed on the pmwiki-users mailing list.

Clarification from PM: Actually, my original post was probably unclear about this, but my intent isn't necessarily to incorporate all of the features directly into the default distribution, but just to build a framework that makes it easier for custom features to be added via cookbook recipes.
The current framework for the page edit screen fails in this last respect, in that it's hard for cookbook authors to adjust things on the edit page. It can be done, but the "hooks" for doing so all seem to be in the wrong place, and that's what I want to fix. However, in order to know what hooks to provide, I need to have a reasonable idea of the range of features that might want to be supported.

Changes under discussion

  • provide a "change summary" field
    • 1 (ChrisL)
    • 0 (BenWilson) There is already a cookbook item for this, so unless it has to be in Vanilla PmWiki . . . -1
    • I'd like to see it become part of the core and become integrated with the RSS feeds to make something potentially more useful come out of the RSS feeds. (ChrisL)
    • 1 I also think this should be part of the core Balu
    • 1 It would be a great improvement SteAgl?
    • 1 Most SCM text revision control systems I've worked with before have this summary field. For pages/authors who use it, it is great. For the lazy, it is neither any hinderance or benefit. In short: Good idea! (Monty)
  • initially populate the textarea field with an "edit template" (DONE)
  • eliminate the "Reset" button, or make it do something different
    • eliminate or replace with CANCEL which discards all changes -- NeilHerber
    • 1 en eject button that takes one back to the page being edited, discarding changes (ChrisL)
      • 1 this one gets my vote, is in my opinion what 'naive' users expect (DirkBlaas)
      • 1 yep and also make it specific: "Cancel editing", either directly or in some pop-up text Radu
    • In my opinion, new users would probably never touch the reset button, fearing the typical internet action, i.e. clearing form. Rename --JohnHerbert
    • Or, forced preview ala Twiki? (BenWilson)
    • Agree: the Reset button is ambiguous and confusing; it was the worst idea W3C ever proposed. Non-HTML-coders do not have a clue what it exists for and fear it. It should be completely removed from the (vanilla PmWiki) form. (Monty)
  • a "Save minor edit" button instead of the "This is a minor edit" box
    • -1 I see the edit checkbox more frequently than a button in other wiki clones. Thus, by remaining with the checkbox, we keep wiki users within "the familiar." (BenWilson)
    • -1/ 1 'save' would be repeated on two buttons, a bit redundant, however see modif a bit lower Radu
    • 0 having a "minor edit" box is one click less ;) Balu
  • add a "Save and re-edit" button to save changes but immediately continue editing
    • 1 from me! (ChrisL)
    • 1 got my vote --JohnHerbert
    • 1 from Anton
    • This might give problems with two people editing the same page? Balu
    • 0 not more than a normal Save; however, it may lead to way longer PageHistories Radu
  • the Save functionality seems imprecise. How about a Save set of buttons, each doing something else (Save: [Minor][Major][Intermediary])
    • 1 since I suggested it :) Radu
  • add capability to edit drafts of a page before publishing them
    • Please explain what this means, it may be too early in the morning for me, but I am not sure I understand. I would interpret this to mean there are "unpublished" versions of a page. If so, I have never encountered that in wiki clones. My solution is to use a text editor (personal choice is vim) with syntax markup. When I'm ready for a draft to go live, I copy-all and paste. (BenWilson)
    • I don't really know why swe should have something like this. Every Wiki page is some kind of draft :-). Also each site that needs this can havde a special agreement e.g. to use PageNameDraft. Balu
    • -1 In a CMS that would make sense, maybe requiring some sort of supervision system. However, in a Wiki, it would lead to messes of versions of the same page Radu
  • an "add new page" link or way to prompt for a page's name
    • with non WikiWord caps possible
    • automatic (:title:) insertion with sentence cap, example - (:title Global warming causes tsunamis:)
      • perhaps the title ought to be a separate field at the top of the form?
    • 0 as people keep asking me how to create new pages I'd like that - but it would also create a risk of many orphaned pages. Balu
    • -1 I see no difference from the normal page link button in the editGUI; if you need to offer guidance, add a simplified GUI.
  • make PmWiki.EditQuickReference reflect use of GuiEdit buttons
    • if GuiEdit enabled, Quick Ref can be much simpler
    • This may be the same thing, it would be cool to be able to click GuiEdit buttons directly from the Quick Ref (they wouldn't have to look like the GuiEdit buttons, but would be able to click directly from there and have the formatting go into the textbox)
  • provide more GuiEdit buttons
    • as shown on http://py.keonox.com/Main/BacASable?action=edit (if it's ok, I'll send them to Pm -- pyg)
    • Provide buttons accesskey shortcuts (see here again for demo working fine in Moz, but with a little bug in IE)
    • an undo button (crtl-Z works fine in IE, but not in Moz)
    • 0 this is provided in the config.php; move this request to the bottom?
  • an improved simpler interface, like the FCK editor
    • too complex and un-Wiki according to some
    • 1 --JohnHerbert
  • paragraph/section editing as in Mediawiki --PatrickOgay
    • editing large files (like this one) is very tedious as it is now
    • 1 Balu
    • Is this an attempt at something similar?
    • 1 It would be a good improvement, if this can be included with a native table of content as in MediaWIki would be perfect SteAgl?
    • 1 maybe the include directive could be set with an argument to generate a button/link that would start the editor on the included page. Radu
    • 1 (Monty) The ideas here are good.
      • I would also suggest, maybe as a subset of section/paragraph editing (as seen on Wikipedia:), a "one liner" edit, with a directive or some markup in the page which triggers this "one liner" editing like (:insertonelinerhere type=bookmark :). For example this feature would be useful HERE AND NOW :) on this page (of lists, where the normal change is to add one sub bullet to a list).
      • could the "one liner" edit be a more general case of when PmWiki must prompt for a password? Or in other words, could the 'enter password now' screen be just an instance of the "one liner" edit?
  • better table support
    • the handling of tables in FCK editor is remarkable http://www.fckeditor.net/demo/default.html
    • The problem with trying to do WYSIWYG table support is that it's not possible to draw tables from wiki markup without building a large conversion program into the browser. If we were editing HTML directly it could be easier (because browsers already knowhow to display HTML), but since we're editing an intermediate markup language it doesn't work out. (And no, there's not an easy way to convert HTML into wiki markup.)
    • even just being able to edit a table on its own would help... that is, each table gains an 'edit table' link
    • PmWiki, AFAIK, has a non-HTML philosophy (BenWilson)
      • Minor idea in helping a user create the table code - perhaps in a popup?: Ask for row and columns and create a form having textareas for each cell on submit create the needed table code... Balu
    • Expanding support for some table atribute to single cell attribute (ex. bgcolour padding border) will allow to create things like in http://codex.wordpress.org/Template_Tags. No need for nested tables, the planned implementation of "DIV" make them not so necessary SteAgl?
  • spellcheck
    • 1 --JohnHerbert
    • Use browser facilities like Spellbound for Firefox. "SpellBound is a port of the spellchecker code and user interface from the Mozilla Suite's Composer that enables spell checking in web forms such as html textarea / input elements"
      • I believe that spellbound or equal is not suitable solution. Requiring all users to install and excludes 50% of users with IE6 --JohnHerbert
    • PHP-Extention: pspell libs: aspell --PatrickOgay
    • -1 I just don't like spellchecks. I always read my text again to find possible typos and I most often the spell checkers need too much manual correcting. Balu
    • -1 great for a recipe, too heavy for the core Radu
  • larger edit area as in Gemini Two skin
    • yes please!! --NeilHerber
    • gets my vote!! --JohnHerbert
    • could use the same system than here (look at the arrow below textarea --pyg
      • need to click on show pagesource button! NeilHerber
    • Like as a cookbook. But, with an "skin-edit" this is much more site specific.
    • this is probably an idea for a cookbook entry... Balu
    • It exists - see Cookbook.LayoutEditModified
  • improved symbols support
    • 1 gets my vote!! --JohnHerbert
    • 1 strikethrough would be nice. :-) (BenWilson)
    • -1 a symbol screenboard or some such would make a great recipe, but maybe too much for a default interface tool Radu
  • save/preview/reset buttons at the top of the edit box as well as the bottom.
    • 1 (or at least make it easier to relocate the buttons)
    • 1 easier relocating, yes... Balu
    • 1 great! and make the author field show at the top only if not filled, otherwise replace it with bolded text Radu
  • This may not fall exactly under the edit page design, but I would like to see a way to view the Wiki Markup without having to go to the edit page section.
  • I would think a separate template specifically for the edit portion of the page would be ideal -- BenWilson in email:
    That is, while you have skin.tmpl to represent the entire page, then you would want skin-edit.tmpl define the edit interface. This means that skin-edit.tmpl would replace $PageEditFmt. Then, when it comes to the layout itself, it becomes more customizable. I think this would also reduce the need of various cookbook items to muddle with $PageEditFmt, which leads invariably to recipe crash. Administrators can customize their skin to their heart's content.
    • Even if we do not move to edit page templates, I recommend that the whole edit area and each component chunk of it should be wrapped in an id'ed div, to provide style hooks.
    • Agreed with wrapping individual elements w/n div's (BenWilson)
    • Maybe should have "$SkinEditTmpl" configuration variable mapping to site's skin-tmpl. This 1) let's admins painlessly try different skins and 2) when unset maps to generic (i.e., current layout) (BenWilson)
  • Some kind soul could modify the OpenOffice-to-DokuWiki macro into an OpenOffice-to-PmWiki macro. That'd be super for converting/editing long documents and/or WYSIWYG editing. Article and link to macro: http://software.newsforge.com/article.pl?sid=05/01/06/1511255