Tags:
create new tag
view all tags
We should take a step back and ask ourselves what is Preview trying to accomplish? In other words, what are the requirements that "preview" is a solution to; then we can investigate whether there are better solution to these requirements.

The primary thing I can think of that preview does is to allow one to verify one's edits in a topic for correctness before saving the document into permanent storage. "Before saving" seems to have two aspects:

  1. Do not commit unimportant intermediate changes to the revision control system
  2. Allow the user to completely abandon an edit in progress.

The alternate solution for (2), of course, is to delete a topic after it has been stored. The situation is more complicated with respect to (1), albeit "preview" may not be a good solution here either. Many users save a topic many times during their edits anyway, trained from years of loosing data to unpredictable computer behavior. Those users are faced with a double whammy. Not only may intermediate edits end up under configuration management, but also, they incur twice the waiting time as if the topic would be simply saved.

I assume the user requirements are as follows:

  1. Allow a topic under edit to be saved during the edit without incurring undue time delays.
  2. Only commit final edits to the configuation management system.
  3. Allow a preview of the topic under edit as finally rendered.
  4. Allow the user to abondon an edit in progress without leaving a record in the configuration management system.

I venture that "preview" meets neither of these requirements well. (1) is best served with a simple "save" mechanism that saves the edited file to disk. (2) could be accomplished with either a "commit" button or an automated mechanism that commits the topic when the lock expires (if no lock is requested that would amount to an immediate commit, and so that should only be used when done with an edit). (3) could be a separate function, performed by the current preview, albeit it would be better to open a separate browser window, at least under preference control. (4) would then require a "cancel" button to abort the edit, i.e., restore the original topic.

-- ThomasWeigert - 19 Apr 2004

I would like to add one more important purpose:

  • Silently verify one's changes before making it available to the users

This is mainly for installations with a large user base and/or for official content (e.g. documenting internal processes and procedures) in a corporate environment. Comment: This is what was meant by requirement (3) above -- ThomasWeigert

-- PeterThoeny - 20 Apr 2004

i've often been frustrated that i can't "preview" (i.e., test) links while in preview mode. i've attached a tiny patch which causes links rendered in preview mode to open in a new window; i think this is the best of both worlds. -- WillNorris

I often use preview and frequently use the browser back button, edit, preview, back, edit, preview, repeat etc. when testing some obscure formating/syntax problem. -- SamHasler

above two comments moved here from SavemultiCgiScript. The patch referenced is on the SavemultiCgiScript page, which raises the question: is it possible to move attachments from one topic to another? -- mhw

Thomas, I don't agree that option 3 is not met by the current preview function. As long as there is the possibility to save immediately, preview could be kept as is. I would definitely vote against a separate browser window popping up. Another solution could be to have edit and preview in one screen, but I am afraid that performance will be bad when you start editing.

-- ArthurClemens - 20 Apr 2004

Agreed, preview works as preview. I recognize that it is a personal preference whether a separate window should be opened or not, thus I suggested that this be configurable through preferences.

I do agree also that the primary issue to be solved is to allow saving of one's work while (i) allowing to abandon edits without affecting the revision and (ii) only committing the final version.

-- ThomasWeigert - 27 Apr 2004

If you want to put popping-up of the preview in a preference, I am sure you wouldn't mind to turn the default setting on wink

-- ArthurClemens - 27 Apr 2004

Not sure what you are actually saying. But in either case, the point above was not really whether preview should be in a separate window or not. My point was that there was multiple requirements on preview and it does not satisfy all of them (well). If anything were to be changed with preview, the first to fix on my preference list would be to allow saving intermediate edit stages so as to not loose work in case of an outage...

-- ThomasWeigert - 28 Apr 2004

Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r13 - 2004-11-12 - SamHasler
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.