Wireframes for the Edit screen

---

UPDATE: I moved the examples from other editors to WireframesEditScreenInspirations to allow a better overview of the mock ups we have for foswiki already... -- CarloSchulz - 09 Jan 2010

---

Thinks which need to be addressed

TopicTitle

I am sceptical of the EditMe (see WireframesEditScreenInspirations) approach which adds yet another checkbox; I would rather:

• Assume that TopicTitle becomes a core feature and all skins are required to implement a field above the topic content editor as in NatEdit.
• Adjust the default new topic template so that it had a %TOPICTITLE% in a heading1 at the top.
• Recognising that most legacy wikis with lots of legacy content will only gradually gain new TopicTitle data:
  • If there is no %TOPICTITLE% macro present in the topic text
    • If the first line of text in the topic is a heading, offer to copy that to the TopicTitle field and replace it with the %TOPICTITLE% macro.
    • If the user modifies the TopicTitle then automatically insert a %TOPICTITLE% into a heading1 at the top of the topic in the editor content.
• If there is a %TOPICTITLE% macro present somewhere in the editor content, then deleting the contents of the TopicTitle field should automatically populate it with the name of the topic.
  • Because if TopicTitle is blank, the topic name is what %TOPICTITLE% should expand out as anyway.
• Renaming a topic should keep the TopicTitle in sync, if:
  • %TOPICTITLE% = %TOPIC%, OR
  • %TOPICTITLE% = %SPACEOUT{"%TOPIC%"}%

We need to throw fewer options and quirks at the user, not more.

I do not believe that a topic's name/identifier should always be the same as its label (TopicTitle in NatSkin speak :-). The obvious example is autoinc topics, but there are deeper reasons too, which I've learnt about from doing semantic/linked data stuff which I won't go in to here.

Macros and WYSIWYG

Working on WysiwygEditorAndMacros provided us with a way of rendering %TOPICTITLE% as an interactive object in the editor that would normally take the value of TopicTitle, instead of a confusing naked macro name...

Form fields

As much as I like NatEdit I also agree that it's much more usable to have the form above or below the topic editor, instead of on a separate tab.

But then it would be great to have forms which could be instantly editable from view without having to click edit, which might be a better approach (I am thinking about new attributes - other than the existing H and M used in data form definition tables - for enabling wysiwyg on formfields).

• Of course. "Edit form" is one of the shortcuts of the edit menu. I think it should only show a page with the form. -- AC

-- PaulHarvey - 04 Jan 2010

I am happy about your constructive thoughts on the topic title, bringing it one step further.

-- ArthurClemens - 04 Jan 2010

There was some interesting user feedback in a video at MergeWYSIWYGEditors comparing the current raw editor with NatEdit saying that users actually liked the tab approach to avoid excessive scrolling between different areas of the edit screen.

In the apps for the clients I work with large data forms have regularly been split up to be displayed on separate tabs with speaking labels so that users can focus on different kind of edits each at a time. Actually, I wished splitting up data forms during edit into groups/tabs would be a core feature. For now this is done writing edit_templates for specific topic types ... which is expensive.

-- MichaelDaum - 04 Jan 2010

• With the Form vs Topic editing in tabs or not, I can see how the separate tab would be useful.
  
  Perhaps it would be nice if I could choose that the form tab opened up by default, instead of EDITACTION=form which hides the topic editor tab completely.
• I also like Carlo's mockup, but it would be very useful to app developers to choose that the Meta Data section goes above the topic editor, or perhaps a better idea is that there is some way to hide the editor by default inside a twisty.
• Perhaps we can also talk about the WYSIWYG fullscreen issue, Tasks.Item2285. Users are a little disoriented at first because they don't realise you have to escape from fullscreen mode before you can save or exit. Especially for users that hit fullscreen by accident.
  
  Main.SvenDowideit raised a good issue also, and that is why should we bother "Save Changes" vs "Save and Continue" - Just have one "Save" button and one "Exit" button, like a normal native rich client application. The "Exit" button would ask if you want to discard the changes.

-- PaulHarvey - 04 Jan 2010

First round of mock ups

Some sketches showing the edit screen:

-- Carlo

If we create a long edit page with sections, those should be visible/accessible though a TOC or side menu. Perhaps fold them with twisties (with a 'remember' setting).

• Good idea. Another one might be to use a tabbed section. -- CS
• Tabs is what I did not like from NatEdit when it was installed on foswiki.org. It is too easy to miss a section. For example for bug reporting the form is almost the most important. -- AC

The 'change form' could be a popup/dropdown list.

• this way we could get rid of an extra screen. -- CS

The attach table should have some management links as well.

• Of course. This was just a quick draft -- CarloSchulz - 04 Jan 2010

-- ArthurClemens - 03 Jan 2010

Some minor updates, now matching the latest version of WireframesViewScreen . The issues with autoinc topics and how to section/tab a form are not answered yet. Will be part of the update. The bottom bar containg the topic actions might not make that much sense during edit... candidate for deletion/hiding.

-- CarloSchulz - 06 Jan 2010

Cool. This is feasible. To include the save/fullscreen/switch-to-raw outside the editor, into the fullscreen mode of TMCE will require a custom fullscreen plugin, but should be worth it.

-- PaulHarvey - 07 Jan 2010

Edit screen maximized:

-- CarloSchulz - 09 Jan 2010

Discussion

Is this different to the editor full-screen mode, where there's only the TinyMCE editor taking up the full browser window?

-- PaulHarvey - 10 Jan 2010

Yes, in full screen edit mode with TinyMCE theres is no space around the editor and no other controls outside the toolbar.

-- CarloSchulz - 10 Jan 2010

There could be an in-place editing version, where you can edit the topic or part of it. I assume that would only show the editor, not the tabs. But fullscreen mode would be handy because the working area could be limited due to side bars.

-- ArthurClemens - 10 Jan 2010

Commenting is disabled while not logged in