I'd like to spark interest in adding some additional buttons to the edit and/or preview in the Beijing release, so I created this page summarizing the buttons (and controls) that exist on the edit and preview pages, and the buttons that have been proposed.

I'm trying to minimize the comments within the lists so that I (and others) can perhaps stare at the page and consider which buttons or combinations of buttons make the most sense.

I have two main goals (Update: Revised the order here.)

• To be able to choose not to preview when:
  • The changes are so simple, I think I don't need to preview
  • Time is pressing, I need to save and get on to something else
  • (Similar to above) I have many windows open, will probably switch windows after hitting Preview Changes, and may forget to come back to Save Changes.
• To be able to save while editing is in progress to avoid possible loss of information due to some mishap

Contents:

Edit

Existing Buttons

• Change (WebForm)
• Preview Changes
• Cancel edit

Proposed Buttons

• Save and Continue Editing
• Save (and Quit Editing) (i.e., no Preview)
• Note: Both of the above with:
  • Release Edit Lock (checkbox)
  • Minor changes, don't notify (checkbox)
  • Buttons for alternate solutions to the minor changes problem (not currently defined)
  • any other buttons relevant to save
• View Preview in New Window
• Force New Revision (checkbox)
• LogOutButton

Preview

Existing Buttons

• Save Changes
• Release Edit Lock (checkbox)
• Minor changes, don't notify (checkbox)

Proposed Buttons

• Resume Editing
• Save and Resume Editing
• Force New Revision (checkbox)
• LogOutButton
• Buttons for alternate solutions to the minor changes problem (not currently defined)

View

Existing Buttons

• <many -- may list later>

Proposed Buttons

• Tag (Bookmark) this Page
• LogOutButton
• UsabilityIdeas

Reference Pages

• SavemultiCgiScript
• AutoSave
• BackFromPreviewToEditButton
• MultipleChangesNotIncrementingRevisionNumber
• RefreshEditPage
• SaveWithoutPreview
• TaggingRelatedTopics
• LogOutButton
• UsabilityIdeas
• ChooseFormButtonIssues
• FormChooserPosition

Other Comments

There have been suggestions about doing something different about minor changes. I've lost track of that for now, so I haven't tried to address it. (Update: I added a vague reference in the lists above.)

Oh, I just rememberd the concept of TaggingRelatedTopics.

PS: Since I am on a (slow) dial-up connection, I thoroughly subscribe to the idea of keeping these buttons at the bottom of the page in order to ensure full loading before pressing (to avoid data loss).

Update: Actually, I would like the buttons at the top of the page, and would like to be able to press them as soon as they are visible (before the entire page is loaded), but not at the risk of losing data.

Other Buttons

If I've missed some proposed buttons (or referenced pages), please add them.

Preferences

My Preference

Preliminary preference: After "sleeping on it", but without a lot of thought, I'm most interested in changes to the edit window, ranked as follows:

1. Save (and Quit Editing) (i.e., no Preview)
2. Save and Continue Editing
3. (Updated, added this item as a preference) Buttons for alternate solutions to the minor changes problem (not currently defined -- maybe I should attempt to list proposals for this and allow us all to stare at them)
4. Force New Revision (checkbox)
5. View Preview in New Window

Note: The first two items above should also include:

• Release Edit Lock (checkbox)
• Minor changes, don't notify (checkbox)
• Buttons for alternate solutions to the minor changes problem (not currently defined)
• any other buttons relevant to save

I'd also like to have the

• Tag (Bookmark) this Page

... on the view page, but I'm not sure where I'd rank this in relation to the other four items. Initially it might come after the first three but before the last two.

Your Preference

Name	Preference
MartinCleaver	as per Randy's suggestions in v1.2 of this topic

-- RandyKramer - 15 Nov 2001

Good summary Randy. Apart from the forceNewRevision checkbox I can't see that any of this would require any rework on the scripts, I imagine that it is all template driven.

-- MartinCleaver - 17 Nov 2001

Thanks, Martin, and thanks for the information! For a lot of reasons, I haven't worked out my preference yet, but knowing (hoping) that most of the changes can be dealt with by template modifications, I won't attempt to before the Athens release. (I'm running out of time, and so are the developers, and rereading BackFromPreviewLosesText just adds to my uncertainty. (I was hoping to find a proposed set of additional buttons that required minimal developer effort and would be acceptable to most users who had an interest in some additional controls -- probably not very likely anyway.))

I expect to try again later.

-- RandyKramer - 26 Nov 2001

I would indeed like to have the buttons on top. Preferrably in a frame so they don't scroll down when I edit the text. Reloading the buttons shouldn't take much time if the URL is constant - the browser should have cached them anyway.

Also, there's a layout mishap - the WebForm Change button. The problem is, I have to scroll the browser down to see the Preview Changes button, which wasn't necessary before WebForms were introduced.

Re Save without Preview: I think it's OK, but the button should come with all the other paraphernalia of the Save button from the Preview page, i.e. Don't Notify, Release Edit Lock and whatever else might be part of Save.

-- JoachimDurchholz - 27 Nov 2001

Joachim,

Thanks for your comments! I believe I've incorporated them all in the body of this page except for the frames comment. I generally don't like frames unless I can disable them.

I use 15 and 17" screens at 800x600 resolution -- a frame usually uses too much of my page width, although on my home TWiki I've added a modification to limit the line length to 90% of my screen width, which makes for more comfortable reading. I guess a frame that was limited to 8 to 13% of the screen width might be fine. (Assuming (WAG) 2% "overhead" for the frame, leaving 85 to 90% of the screen width for the TWiki text.)

On my home TWiki, (IIRC) I did this using a width attribute on a section (division?) rather than a width attribute on the table in the original TWiki template (20010315 beta). It made the line wrapping behavior better, somehow. (I think this had to do with wrapping all text except text in things like <verbatim> tags to the actual width of the window, thus minimizing the need for horizontal scrolling.)

-- RandyKramer - 27 Nov 2001

Yeah, the limitations of frames are annoying.

Though, in this case, they wouldn't be too bad. Just make all links target="_top", and put the standing matter on top of the page (who said it must be the left margin?), and everything will be fine (including browser bookmarking).

-- JoachimDurchholz - 28 Nov 2001

Ahh, Joachim, thanks, the light dawns -- yes, a frame at the top of the page would be fine.

PS: Re:

Also, there's a layout mishap - the WebForm Change button. The problem is, I have to scroll the browser down to see the Preview Changes button, which wasn't necessary before WebForms were introduced.

I didn't quite realize the point you were making until I reread this. (I confused it with another very related point about people clicking the wrong button since this addition. In addition, I have my edit window set to the full screen height, so I have to scroll down in any case.)

But, yes, I see that a change here would be very nice (if we don't move the buttons to the top), I could adjust my edit window size so the Preview Buttons did fit on the first page, so I would rarely have to scroll down.

Aside: (I (or Mike Mannix ) will move this somewhere else, but an off-topic thought -- it would be nice to have TWiki shorthand for the <blockquote> tags.

-- RandyKramer - 28 Nov 2001