Planning for improved page editor. Please comment on the ideas in this page

See also UsabilityObservation/Wonder how to save

Don't start implementing until 1.5 branch is open or you will create lots of conflicts.

Problems with current editor

Stuff improved in 1.5 is marked with a check mark (./).

Sorted by importance (add stuff that bug you):

• Scrolling within scrolling. Both the mouse scroll wheel and the keyboard page up and down does not behave in an expected way - either the the page scroll or the text area. Cause by having too much elements in the page.
  • how to improve?

• The text area we write into is only about 50% of the browser window, compared to about 90% with real text editor.

• The layout and design is hardcoded in PageEditor, should be part of the theme.

Unneeded stuff that take valuable space

• The [current page size is 0 bytes]" are useless. Who cares about the size in bytes of the page?

  • Replace this with document statistics that can be helpful, like line count and word count.
  • any other interesting statistics?

• "Optional comment about this change" too long, can be simply "Comment" and come in the same line as the comment text field

  • stylistic argument, some people think an edit textline has more style if it spans the same width as the big box above it, others like more compact space top to bottom.
    • I don't think about style. This extra line could be the line that make me scroll to get to the save button, instead of just clicking on it. We are using both styles in other places.

• The horizontal line before the help does separate the help (and some people like it) but we can do it in a more compact way.

Needed stuff that take too much space

• The message "Other users will be warned until 2005-05-07 21:35:21 that you are editing this page. Use the Preview button to extend the locking period." is too long.

  • Some people (me ) does not use this information, they simply think about the text, and don't count how many minutes they have.

  • Others want to know when the lock will expire
  • It's a warning - kind of soft-lock

  • Should be shorter, maybe: Locked until Sun May 08 01:34:34 2005 (preview to extend)

  • Maybe we can save vertical space by locating it on the side.
  • Maybe remove other element like trail or navibar make space for that
  • If we want to show the time, why not show real progress using javascript?
  • How about showing a preview reminder dialog when the lock expire? (could be annoying)
• The title "Edit "Editor Redesign"" is huge, should be CSS'able like everything else

• "Make this page belong to category" too long, can be simply "Add to ...".

• The message "The lock of Nir Soffer timed out 6 minute(s) ago, and you were granted the lock for this page. Other users will be warned until 2005-05-08 18:30:09 that you are editing this page. Use the Preview button to extend the locking period." is quite amusing to read when you ARE Nir Soffer, and being granted the lock of yourself I hope we can put little AI into this and just say "You were granted another 10 minutes".

• "Click preview to extend the lock" is nice to see on the first use. But when you see it again and again, you just ignore that message. We don't have to give help for people who don't need help. Maybe we can have a beginner mode, that give you hints, then stop annoying when you ask for it. Its a common pattern in GUIs, quite annoying also, but better then repeating help.

  • As long as we do not use those 'light bulbs', 'computer faces', 'dog friend', etc. some OSes use.

    • There will be no moin paper clip!

• 'HelpOnFormatting' is good for newcomers who, once they are about to edit, have doubts about how to.

  • Can come on a sidebar, maybe even with more links.
  • To keep both new and experienced users happy, we can make this kind of help collapsible, and make the user remember the last state of the help list. So when you are a beginner, you get the help and the tips. The first time you collapse the list of help links and tips, the wiki remember it for the next edit. This way we can save user preferences without adding more check boxes. This is the most natural way - the wiki simply look like you left it on the last time.

Wrong placement

Trivial change and Remove trailing... are located after the form submit buttons. The order should be top to bottom, left to right (or right to left). In current location these might be hidden, and the relation to the rest of the form is not clear.

Correct placement would be:

page name
[edited text...                                                           ]
 comment: [                                                               ]
  add to: [categories]  [ ] trivial change  [ ] strip trailing whitespace
[preview] [check spelling] [save]   [cancel]

• Where would you place the "preview text" (below "edited text" or below or "in between" the "buttons")?
• Similar question when using "check spelling".

Losing editings when using "Preview"

New (and old) users sometimes click links in the preview, and continue to work on another page - forgetting to save their edits.

Possible fix - inactive links

• If javacript is available, make links in preview show an alert

  • You have unsaved changes, do you want to discard them or save the page?
    [Save changes] [Discard changes]

Save would save the page by just like you clicked the save button. Discard would visit the clicked link.

• Without javascript, links will be simply disabled, using an html title "Link is disabled in preview mode, save page or cancel the edit first."
• Same problem exists when clicking on links outside the preview - new users might exit the editor without saving their changes with a single click. We can similar alert when clicking any link that exit the editor without save.
• Problem - the link must be active and should not show any alert when you try to open a link in a new tab or window - can we do this?
• Or - open all links in a new winodw from a preview - might also be very annoying.

better preview hints

Preview mode

When in preview mode, the editor is at the top and the preview at the bottom. The page load and scroll automatically to the preview part. When you want to save, you need to scroll back up to the top, then scroll down to see the save button.

Seems that preview at the top, editor at the bottom make more sense:

1. Click preview in an editor
2. Preview opened, no scrolling needed
3. Read page, scrolling down
4. Scroll little more to get the editor, or to the end to get the save button

We need to try this, it will be easy when the editor move to the theme, so its easy to move things around.

When using the "Check Spelling" button, the page should scroll to the list of unknown words from the spell-check. It doesn't make sense to skip past the word list and show only the preview for pages where the document is long enough to fill the page.

Stuff to think about

• "Remove trailing whitespace from each line" do we really need this?
  • I have seen things that need it, mainly the results of pasting.
    • Let assume its needed in certain cases - can we apply this automatically in all cases and save one ui element?
    • If we can, why not make the parser more forgiving about trailing whitespace?
    • "Strip trailing whitespace" is little shorter
• The current location of the help does not help much, because you have to scroll (and possibly loose your location in the text area) to get it.

  • A better location would be on a sidebar - kind of SyntaxReferenceLite in a #!sidebar section. We probably can do this because editor font tends to be smaller and using the full width of the browsers window create very long lines that hard to follow.

  • Or a floating box, new window - problems with non javascript browsers
  • If the display code is factored into the theme, people can use different themes without disagreement.
    • I like the idea of a kind of 'sidebar' for help. It's nice to have it at hand, so editing experience can be quicker.
• Help uses too large font in the worst layout possible.
  • Should use smaller font (designed by css)
  • Tabular design instead of definition style - problem: its wiki markup using definitions, maybe few css rules can fix this
  • Could be toggled by simple javascript
  • When javascript is not available, maybe open in a new window?
• It's very hard to search inside the textarea. It's very common to find something you want to change in a big page, open an editor and then work very hard to find the stuff you need to change.
  • This is a browser limit, I don't know if we can make it better.
  • The best solution is section editing - like mediawiki has, or better see bellow "in-place editing".
• If a user uploads some attachments and then tries to create links, he either has to remember the attachments' names or cut and paste them from another window.
  • having users create empty links first and then fill in the attachments gets around remembering the name, but I've found it's very foreign to new users who want to grab their mouse and click to attach something.

  • http://del.icio.us has a nice way of doing this with tags (where its the tag names you have to remember instead of attachment names). The tags are listed below the text area. Clicking on on inserts it. Perhaps this could be done with attachments. At the very least, having the attachment:filename available to cut and paste from on the same window would help. It would also be nice to be able to add attachments from the editor window (a popup?). Users are accustomed to email where they attach files from the same window where they edit.

• The function of categories isn't obvious from the editor page.
  • You can't tell what categories the page already belongs to unless you scroll to the bottom of the edit window.

  • The pull-down menu with <no addition> doesn't scream out to the user that there is anything he should possibly do. I doubt any first time users even notice it.

  • http://del.icio.us model uses a blank box, so at least you might consider whether to put something in there. Another option might be to say "categories: none" or "none assigned."

  • a list of existing categories on the page would also help the selection versus a pull down menu. Using small type and the categories listed horizontally could save space.

Stuff that need more thinking

• the site stuff - logo, login, search trail and navigation takes a lot of space. Do we want to "leave" the site for the editing, or we want to edit the page in the site?

  • Its very common to open two pages while you edit - copy text from one page into the current editor, or lookup the syntax of a macro in the help etc.
  • On the other hand, its very important to have simple clear interface with only needed elements, and taller textarea you can get (width is usually not a problem).
  • We need a folding solution - when you open the editor, the side navigation, trail and search can fold - so you have place for quick help, few links and document statistics. If you want to open another page or search, you can unfold the needed stuff with single click, you don't need to close the editor.
    • Problem - how this will work without javascript?
      • maybe you will get the folding stuff only if you have js. If you don't - you will get simpler interface that let your do most things in an acceptable way.
      • One option is implement folding with a request to the server - clicking on a title will preview the page and send you an expanded view. Clicking again will go to the server and return a collapsed view. It suck, but this was your choice to disable client side scripting.
• For more than quick edit, editing in a browser suck. One want to work in an editor with real find and replace, spell as you type, undo, etc. How can we make it easier to edit in external editor?
  • As someone who recently added mozex (a chrome patch for mozilla that has the context menu offer helper apps) I like having my own editor - but I hate the detached nature that leads me to ignoring my fading lock, and I wish for "fast macro" moin things. I can train my editor to this - or moin's editor could be really nice and I wouldn't have sought to leave it.
    • Yes, editing user experience could be improved but it should always be an 'optional feature to enable' because the good thing about wiki editing is that you have the freedom and the chance to edit anywhere, wherever you are, and from any device that supports web browsing, right? Hence, Moin is cool because it is not so piky or resources demanding.
• Do we need more control for the font and size of the editor, like have certain font and size for each user?
• Many times you catch stupid errors only after you save the page. Then you edit again and again, and your wiki collages get tons of mail about your changes. Maybe we want to make save available only after you click preview?
  • a moin cannot AI-determine what kind of change is trivial or not, only a human could guess that. By which time it's too late, the mail is sent. Subscribers to pages should mean they want that news.

  • Please not! At least not by default - a configuration option would be okay though. But I don't want to click 2 times and wait for the server to respond each time I make a change! -- NicoDietrich 2005-05-07 21:07:08

  • What about merging subsequent edits of the same user that happen within a short time? May be merge them only after some days past or offer a button/checkbox
    • Automated merge if the things aren't near each other sounds easy, but if they are describing the same context, seeing each other's edits may inspire a more serious page tweak. if we decide to to this, should be in the form of a Preview_automated_merge - with the ability to accept it.
      • I know that TWiki files multiple consecutive edits by the same person within a configurable time period (defaults to an hour) as a single revision. I think that would be a good start.
  • AFAIK, 'subscribers' are able to understand the pros and cons of subscribing and I seriously doubt a person edits intentionally to make stupid mistakes. Actually, it seems to me that many people editing content (me included) make mistakes unintentionally or because they are editing in a foreign language. IMHO, quing or waiting for notification to be sent, after a change has beeing made, kills the wiki idea.
  • Maybe it can be a user preferences - those that like a safety net of a preview on each save will use it, those that never make mistakes will disabled it.
  • Maybe simply making preview the FIRST button will be enough:
    • When you click enter, it will cause a preview, not an unwanted save
    • Its a hidden recommendation to the user, preview before you save - good for both the other users and the wiki itself, instead of 5 revisions with typos you will save one clean revision.
    • Preview extend your lock, so you will get less conflicts, which are annoying and hard to fix

Examples in other wikis

• Please add links to interesting reference.

• PhpBB has a very nice editor concept, but it depends heavily on javascript.

  • Maybe I confuse it with other system, but I remember a tiny window, maybe 1/10 the area of the browser window, all the other space filled with unneeded buttons, smilies, BBcode, html code... Usually this come with horrible tiny font, which complete a totally unusable system.

Planning for 1.5

• The text area should be the largest element and fill most of the screen

• No scrolling to get to the save/preview buttons

• Remove everything not needed while editing

• Make less important stuff small, and put at the bottom of the page, where is might be hidden.

• Compact folding help, or simple help toolbar like media wiki. Should work also for clients without javascript.
  • It should be a syntax reference at least for basics, and if you have JS turned on, do useful things when you click on them. The BBS' offer fast smilies - we definitely should.

• Consider the site elements needed in the editor.

Refactoring

• Move all display code to the theme, PageEditor will only supply needed data to fill the editor. The goal is make is possible to create themes with only some parts of current editor, or with new parts, without changing PageEditor itself.

• The theme should define all html structure, css ids/classes

• We should keep the logic inside PageEditor, so we don't have same data kept in different modules

• Kill the huge functions in PageEditor, the worst is sendEditor

Future ideas

In-place editing

Its very hard to edit long pages, because its hard to find a paragraphs in a browser text area. Unlike real editors, there is no search as you type. If we can edit in-place - edit a paragraph inside the page itself, its was much easier.

How it could work:

1. Click on an edit button near the paragraph
2. The paragraph is replaced with a text area - no need to open separate editor!
3. Edit and click save
4. The new paragraph is sent to the server
5. Either get the new paragraph with remote scripting, or the new page after the change Do this so it stays Lynx compatible and I'd be pretty happy... can't just be a floaty sized box, the gui browsers are insane when it comes to layout glitches calculated by size...

   • I already done this in in a forum interface in a multi platform way (even IE) using javascript and dom. Basically you send a hidden text area with the page, then when you want to edit, you remove the paragraph and insert the editor instead with addChild etc and unhide the editor. You must prepare for this by giving id or class to elements so you can easily identify them. Check http://nirs.freeshell.org/forum/forum.html (sorry Hebrew only, yes it also RTL )

Or:

1. http://www.appelsiini.net/projects/jeditable/custom.html

2. when generating the html code, include raw file offset positions and lengths of a displayed section/paragraph and the page revision.
3. the editied sections gets sent to the server and replaces the section in the raw file thereby generating a new revision of the page. of course, you need to check the revision to avoid concurrent edits.

Markup toolbar

Instead of the help, we can have kind of toolbar that let you add markup with a click of a button, or at least see the markup when you hover on a command - something like media wiki.

• Problem: will not work without javascript - could look like merely a helper-card instead if it doesn't.
  • "Unfolding" help done without JS could paint more stuff on screen, invoke preview, and extend your lock.

I don't think it makes sense having to many different editors. There are basically two kinds of people: the ones knowing and caring for wiki markup and the ones who don't know and don't care. Therefore we need 2 editors:

• one markup editor (as in 1.3 and before) - we don't need a markup toolbar there
• a WYSIWYG kind of editor with buttons and menus (BB/FF/TW currently work on this)

A markup toolbar that add markup for you can help you learn how to use wiki markup, and is much easier to do and will be much faster and compatible with many browsers, unlike WYSIWYG editors.

• Try http://httest.de/testwiki/WikiSandBox?action=edit, the JS code is from wackowiki. It only works with firefox at the moment, but the wackowiki documentation says it should also work with IE.

  • Totally broken with Safari
  • B/I/U buttons effect whole line instead of only the selection: try to write "some text and some bold text" select "bold text" and click the "B" button. All the line becomes bold, instead of only the selection.
  • Does not show if you disable javascript, we should have simple help in this case.
  • The shift left/right and the lists work nice
  • The B/I/U buttons should toggle the state of the selected text. If you select bold text, the button should look pressed, and when you click it, the selection should become plain. This is probably not see easy to do.
  • headings also effect whole line, ignoring the selection or cursor location, but it should work in most cases.
  • hr inserted on the next line instead of current line
  • shift left/right effect heading lines, which break headings in 1.3.
  • This markup editor need much more work to be useful, even on only Firefox.

• Also look at my 1.3.x patches MoinMoinPatch#head-883900d79d1ac5ca68f1621152dad25d01f6646b character inserter bar. It has some support for wiki markup. Also importantly, it provides shortcuts for inserting the most common Unicode characters (most English-speaking writers have no idea how to insert accented characters, yet the need arises occasionally). JS works in most browsers. -- DeronMeranda

Separate editor for acl

In most cases, we send acl lines to a user that can not edit them. When they try, they can't save. This is not very user friendly. This does not save space in the editor but just remove few lines you can't and probably don't even know how to edit.

• We can send the page text without the acl lines if you don't have admin rights
• If you have admin rights, we can send the acl lines like we do today
• Or maybe put them in an extra editor, maybe customized for acl editing, so easier to use
  • But separate editor need space, maybe acl editing can be separate from text editing?
    • Like we look at attachment, we can look at acl rights, and edit them - without touching the page text (the acl can be saved IN the page text actually, but it can be transparent)

Editor for processing instructions and pragmas and other meta data

Unlike acl, you can edit those always, but you don't need too in most edits. These are more page meta data we keep in the page text. We can replace with a form:

• Select page format from a menu that shows all available formats on the wiki
• Add pragmas with few selects and a text field for the value
• Set boolean values with a check box
• All this without opening the page text for editing, and without creating a new revision of the text - if the data is saved outside of the page.
• Same for categories? use meta data section or separate file instead of stupid hard to use backlinks?

-- ThomasWaldmann 2005-05-08 11:03:22

actions

while I recognize I always scroll down to save my new comments I wouldprefer the "Save changes" "Preview" and so on duplicated on bottom ofthe text window above the Comment line. -- ReimarBauer 2005-10-15 20:09:38

Switch to the open source Dojo editor, same WYSIWYG editor as Jot.com

I used the WYSIWYG editor on Jot.com ( demo and link to main Dojo site) and it's quite amazing. I've been playing with it and I haven't encountered ANY problems. Their goal is zero data loss and perfect correllation between WYSIWYG editing and submission. The Jot team is sponsoring the project with money, and there are a few dozen active contributors. I know a lot ofwork has gone into the current editor in 1.5, but perhaps the bugs can be fixed rather easily by switching to an editor that may already have the lingering bugs (especially the spacing issues) hammered out? Maybe worth a look? -- RyanK 2024-04-27 09:42:04

• - The Dojo Editor looks impressive. This would be a major benefit to the usability of the wiki. The uptake of wiki's is now to non-technical users who do not understand the wiki markups, and now we don't have to expect them to!