Jump to content

Proposal:Split-screen edit-preview and edit-form

From Strategic Planning
Status (see valid statuses)

The status of this proposal is:
Request for Discussion / Sign-Ups

This proposal is associated with the bolded strategic priorities below.


  1. Achieve continued growth in readership
  2. Focus on quality content
  3. Increase Participation.
  4. Stabilize and improve the infrastructure
  5. Encourage Innovation.


Summary

This is a very cheap and easy method to incorporate some advantages of a WYSIWIG (what you see is what you get) editor. Firstly, we create a split view of code and preview by placing the edit-preview content in a scrollable box with a specific height (just like the edit-form is already placed in a box with fixed height). Secondly, we live-update the content in the edit-preview box.

Please see a screenshot of this proposal here: http://www.webcitation.org/68DfP0tv6

Proposal

Phase 1 "split view"
  • edit-preview is placed in a box with a fixed height, just as like the edit-form already is. This will create two scrollable areas on top of each other, allowing a person to navigate to the same content in both views.
  • Optional "automatic scrolling": content in both boxes could be matched through automatic mutual scrolling, always aligning the first line in each box. (this could be presented as an option that could be locked and unlocked).
Phase 2 "live preview"
  • Change the "preview" button into an "update preview" button, updating the content in the peview box (possibly without reloading the whole page).
  • Or, dynamically/live update the edit-preview box, so that changes in the code are immediately visually represented.

Motivation

Advantages of phase 1 "split view"
  • By placing them in one view, editors (in particular new ones) can better relate the two, without having to constantly scroll up and down.
  • It becomes more clear when one is in the editing mode, because one will always see the edit-box at the bottom. (With the possible exception of when one scrolls down to see the list of templates, etc. below the split-view)
  • Advantages of optional "automatic scrolling": Although free scrolling in both can have its advantages, directly seeing the results of editing requires that the content in the two boxes match. This would also help new editors understanding the 'live preview' functionality.
Advantages of phase 2 "live preview"
  • One will be able to see an "updated preview" without changing the view.
  • One approximates a WYSIWIG editor, without having to design a new editor.

Key Questions

Why not?

Potential Costs

Phase 1 "split view"
  • Very minor costs. Additional code could be as little as one line of additional style code (Of course, the height must be dynamic to take into account different screen resolutions.):

<div style="max-height: 240px"> <div id="wikiPreview" style =”max-height: 240px; overflow: auto;”> … </div> </div>

  • Optional "automatic scrolling": Probably minor time/resource costs.
Phase 2 "live preview"
  • The "update preview" button would be very simple to implement; making sure that the view returns/stays focussed on the same content may be a bit more costly.
  • The "live preview" development costs would be higher, but not insurmontable. There could be some costs on wikipedia-infrastructure, depending on the frequency of the live-updating.

References

Screenshot of the proposal (JPG) on WebCite.


Community Discussion

Do you have a thought about this proposal? A suggestion? Discuss this proposal by going to Proposal talk:Split-screen edit-preview and edit-form.

Want to work on this proposal?

  1. .. Sign your name here!
Retrieved from "https://strategy.wikimedia.org/w/index.php?title=Proposal:Split-screen_edit-preview_and_edit-form&oldid=86020"