While we want the focus of this page to remain specific and detailed feedback on the new editing experience that we can address, a number of people have put considerable effort into outlining their ideas for alternate editing strategies and we also wanted to capture these below. | From | Idea |
|---|
| Alexy Kotenko | Okay, as the WYSIWYG abilities are wider than wiki markup allows - let it be. But you can still provide a solution similar to one implemented in JIRA search. In there you have a search form for rather simple requests, and direct SQL edit for complicated requests. And if directly edited SQL is too complicated to show it as a form - it just tells you "search query is too complicated" and doesn't allow to switch back to form. As earlier you have claimed that implementing XML-to-wiki transformation is easy - I see no problem to still allow wiki edit, but with XML format on backend and disallow wiki if something too complicated was created through WYSIWYG. This can easily be added as a plugin, to solve your problem with complains on the core software. | Anonymous (In reponse to Alexy) | This sounds like a very good idea, and I hope Atlassian will take the time to investigate it. By definition, people who still want to use wiki markup will not be using the most complex WYSIWYG-only formatting, so it should be possible to convert almost everything such users write back to markup.
Another suggestion would be to extend the Wiki Markup Styler plugin to do the same thing. Ideally, any content that can be converted back to markup, would be. And any complex elements that cannot be converted would just appear as they do in the normal WYSIWYG view. This would avoid the possibility of one complex piece of content causing a whole page to be marked as "too complicated to edit through wiki markup".
If Atlassian choose to do this, the other vital requirement (for me) is that we can copy the wiki markup from the editor. At the moment, the plugin displays markup elements on-screen, but if I try to copy them it just gives me the underlying text. In common with other commenters, sometimes I prefer to copy markup from a Confluence page into a text editor and edit it there, before pasting it back (either into a different page, or into another part of the same page). | Todd Day Andrew Spina | Keep wiki markup format by wrapping in a "wiki markup" macro ---- Todd - Ability to wrap entire pages in the Wiki Markup macro and not have them auto-convert to storage format. Additionally: - Macros that come from plugins I currently use in 3.5 continue to work the same way in the wiki code block. I'm willing to wait for the authors (Adapatvist, Customware, and the guy who wrote the LaTeX plugin) to upgrade their plugins for 4.0, but the end result must be that I can write in 4.0 wiki code blocks the same way I currently write in the 3.5 wiki editor.
- User macros I wrote for 3.5 need to also appear in the 4.0 wiki code blocks.
- When upgrading from 3.5 to 4.0, I want the upgrade process to wrap every page in a wiki markup block instead of converting it to the new XHTML format.
- Site and Space themes should be definable in terms of Wiki format.
- It would be nice if the wiki code blocks had a button on them that would convert to the new XHTML format if you pressed it. I understand this would be a one-time no-reversal operation, and that would be fine with me.
---- Andrew - I haven't read through this post, but this page says to post requests here. I'm new to confluence (and like it a lot), but was wondering why wiki markup is translated into a wysiwyg format after entry. I was wondering if it made sense to allow people to make a container (like a new column) which would preserve wiki markup, but render it on the saved page as rich text? I know it's not as friendly to non-technical users, but it seems a bit closer to the middle ground. Just a thought...
- See related issue at
| Jira |
|---|
| CONF-23895 |
|---|
| server | Atlassian JIRA |
|---|
| serverId | 144880e9-a353-312f-9412-ed028e8166fa |
|---|
| CONF-23895 |
|---|
|
| | Don Gamble | Treat macros and all special editor objects (images, links, etc) the same - i.e. they would all have a frame. Currently the new editor doesn't treat everything as equivalent. This results in issues with where the insertion point moves during editing, what is selected, what gets cut or pasted, etc. Treating everything special (i.e. macros, images, links - things with parameters and/or bodies) as a framed object allows everything to be treated as an object, just like a character of text. Providing the frame also now allows you to explicitly see what is inside and outside a special object and allows you to select the object. For example, there is currently no way to select a link. You can select text that is linked, you can select an image that is linked, but you can't select a link. Raised in CONF-24026. | | Don Gamble | Display the associated parameters of the object (macro, image, link, etc) as text in the header of the objects frame. With macros and special objects now having a frame, the hidden parameters of a macro/special object can now be displayed. Entering edit mode should expose all of the hidden information that is not visible when the page is rendered. Currently entering edit mode results in still having to enter a deeper edit mode (i.e. the macro browser or the special popups) to see the true values to edit. An edit mode within an edit mode is a huge productive hit. Simply seeing how a page was created is not currently possible while in edit mode. A guiding rule should be "While in edit mode the user will be able to inspect the page and see all the properties effecting how the page renders without needing to do any further activities." If this rule was true a majority of the productivity hit of the new editor would be resolved. To do this requires displaying the parameters of macros and special objects in their frame. Raised in CONF-24026. | | Don Gamble | Allow the parameters in the frame to be edited as name value pairs and re-interpreted when focus leaves the frame. The final hit to productivity of the new editor is the need to enter a sub-edit mode (the macro editor or the special popups) when making a change to a parameter that is already applied to a macro or a link/image. Allowing the name value parameter pairs in the frame to be edited would allow rapid changes to be made with a few keystrokes with no loss of user focus caused by having to visit a dialog. Allowing new parameters to be added into the frame by just typing, for example "width" which is an obvious and easily remembered parameter on many macros, would allow common edits to occur quickly. Parameters that could not be parsed after the edit completes (i.e. after focus leaves the frame) could be handled by highlighting or in a similar way to how firebugs lets users change the parameters in the html editor window. Raised in CONF-24026. | | Don Gamble & Fast | The confluence editor should behave very similar to every other commonly used editor. At a high level, today's user's expectations of how an editor reacts is common across all editors. If the editor doesn't behave as commonly expected then the user's experience is compromised (some would say the editor is broken or unusable). I see these expectations as (please comment - do others agree?):
- The focus of all activity occurs at the insertion point or selection.
- Pressing backspace or delete, removes what is to the left/right of the insertion point or removes what is selected.
- Typing or pasting inserts the contents at the insertion point or replaces the selection and leaves the insertion point after what is selected.
- Moving left, right, up, down with the arrow keys or page up/down in a document, if the same key presses are reversed, should place the cursor back in exactly the same location as it was before the first key press.
- Holding the shift key while moving left, right, up, down should extend (or start a selection from the insertion point). Pressing the opposite key should reduce the selection.
In general, the new editor doesn't respects these user expectations. This makes it slow, hard to use, and I would argue filled with special situations that while can each be individually explained as correct - as a whole make it wrong. An editor should be a simple experience - not complex. Specifically with respect to what should happen when the insertion point is at the beginning of a macro, i.e. just inside the body. I would suggest: - Pressing the backspace key should do something, currently it does nothing when just within the body.
- Pressing the left arrow moves to the outside of the macro (CORRECT), but starting at the same spot and pressing the left arrow, while holding the shift key, doesn't appear to do anything.
- Unfortunately, it is more complex (in Firefox at least) continuing to press the left arrow while holding shift results in first the insertion point disappearing, with nothing selected, then nothing on the next key press. After some number of key presses the insertion point reappears with no selection. Reversing, i.e. pressing the right arrow with shift held, results in the insertion point appearing, then a selection appearing, then an insertion point, etc. Nothing is obvious as you attempt to select across a macro.
|
|
