Tags:
editing1Add my vote for this tag usability1Add my vote for this tag wysiwyg1Add my vote for this tag create new tag
, view all tags
This topic is intended for discussion of the requirements for improving the TWiki editing experience.

Background

Historically wikis have used wiki markup to ease the problem of training non-technical users to produce formatted documents without the availability of WYSIWYG tools. With the increasing availability of WYSIWYG tools for browsers, there has been pressure to enable WYSIWYG solutions. However experience has shown that WYSIWYG is not necessarily the answer. It is clear that some out of the box thinking is required.

There have been a huge number of proposals for improving the TWiki editing experience, several of which have lead to real implementations. The takeup of these ideas has in general been very slow. A major part of the problem is that no-one really knows what the requirements are for editing. Everyone has their own ideas, and several have resulted in half-baked solutions that have just alienated others. For reference, here are some links for a bit of light bog reading.

This topic is intended to take the technology out of the requirements for TWiki editing, and look at the problem from a purely user perspective. The question being asked here is How do users want to interact with TWiki? It is not what is possible? You are recommended to familiarise yourself with what has already been discussed, before adding requirements.

BTW if you, or your company, are interested in sponsoring any aspect of the work to enable improved editing, then say so. Lack of support from the user community has been a really negative issue in this area.

Statement of User Requirements

So, what are the end user requirements for improving the wiki editing experience? It's clearly not as simple as "WYSIWYG" for reasons discussed in WysiNwyg. There is a lot of doubt as to whether WYSIWYG is even required. So what is required? This is your chance to have your say.

  • Requirement 1: Tables It is very easy for even relatively simple tables to become unreadable in TML. More powerful tables are required (which requires significant extensions to TML, or dropping TML in favour of HTML). That should include:
    • Resizing,
    • cell colours,
    • borders,
    • bolding (heading) whole rows or columns,
    • aligning whole rows or columns.
  • Requirement 2: Images A lot of our new development is GUI based, so screenshots are becoming a must. Adding graphics in the normal editing is currently not possible and instead requires a cycle of Saving, Attaching and back into edit.
  • Requirement 3: Contextual Editing (also known as Sectional Editing) The fact that even a CTRL-K (Checkpoint) takes you back to the beginning of the document (which could be very large) is a PITA. What would be really good would be the Double-click edit which takes you into a full edit with the cursor positioned at the point where you double-clicked.
  • Requirement 4: We'll assume that support for IE and Firefox/Mozilla-based browsers is a given. But what about Safari?
  • Requirement 5: Support for Opera
  • Requirement 6: Search and Replace (not be required if the contexts in Contextual Edit are small enough).
  • Requirement 7: Maths

-- Contributors: DuncanKinnear, CrawfordCurrie

Requirement Prioritisation

Priorities in the range 0..100, higher number means it's more important to you. Add your own row to the table (keep it sorted by name, please). ?? means you haven't had a chance to express an opinion yet.

Who Requirement
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
ArthurClemens 40 90 80 100 5 50 5 ?? ?? ?? ?? ?? ?? ?? ??
CrawfordCurrie 30 10 70 65 20 90 5 ?? ?? ?? ?? ?? ?? ?? ??
DuncanKinnear 80 70 90 1 1 60 20 ?? ?? ?? ?? ?? ?? ?? ??
KennethLavrsen 90 60 70 50 20 40 1 ?? ?? ?? ?? ?? ?? ?? ??
OliverKrueger 80 50 90 10 35 30 1 ?? ?? ?? ?? ?? ?? ?? ??
PeterThoeny ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
RafaelAlvarez 90 80 89 1 1 30 40 ?? ?? ?? ?? ?? ?? ?? ??
SteffenPoulsen ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
  410 360 489 227 82 300 72 0 0 0 0 0 0 0 0

Discussion

I had added this up above in the actual requirements, but I think I should probably put it down here instead.

For us, Sectional Editing is only a workaround for not having Contextual Edit Positioning (the double-click method I described originally). We would want to be able to edit the whole topic in 95% of the cases where we currently use sections. Sectional Editing is useful in very large documents where there are parts that are almost totally separate from each other, but I would argue that that type of document is best split up into separate topics anyway.

What I'm trying to say is that anything that cuts down on the need to go through the edit-save/preview-edit cycles is preferable. Sectional Editing actually increases the need for these cycles, so I do not see it as part of the main editing solution.

-- DuncanKinnear - 19 Apr 2007

No, the SectionalEditPlugin is a workaround; the Sectional Editing concept predates that plugin, and was been more fully explored by SvenDowideit. Sven supported what you are now calling Contextual Editing (double-click in text to edit, bounded by para marks, for field, heading, whatever). Just a terminological nicety.

-- CrawfordCurrie - 19 Apr 2007

Crawford, when you say that 'Sven supported what you are now calling Contextual Editing', do you mean that he had a mechanism to do this? I would be very interested in this, if that was the case.

-- DuncanKinnear - 20 Apr 2007

see http://twiki.org/cgi-bin/view/Plugins/InlineEditPluginDev , though the version in svn is broken atm, last time i worked on it, I was trying to tease apart some of the more odd code.

-- SvenDowideit - 20 Apr 2007

Sven, can you describe what you were trying to achieve with your Plugin? When do you think you will be able to continue working on it?

-- DuncanKinnear - 23 Apr 2007

My ideal is to be able to select an area of text, and hit edit on it. The compromise we made was to chop up a topic into sections, with context appropriate mini-editors - hit edit on a table, you get a spreadsheet like thing, hit etc on a prose paragraph, you get a little text edit of that section, hit edit on a SEARCH and you get a popup UI that guides you through the SEARCH options, with help as you need it.

The biggest missing twiki functionality for this to work well, is the TopicObjectModel - a way to round trip identify (and thus modify) any quantizable section of a topic of topic set.

Its a massive undertaking, the proof of concept was worked on with sponsorship, to enable me to focus entirely on developing the idea for amonth, and to be honest, to re-vive it will probably require the same, as I don't have a contiguous enough block of time that i can go without working on finding more work to pay for groceries.

The reason that the svn version is currently broken, is that I started to work on re-engineering the 'proof of concept' code into a unit testable platform, and this is far from done (the experience of WysiwygPlugin shows that the editor has to work, every time, all the time, with all types of content ).

-- SvenDowideit - 23 Apr 2007

Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2007-04-23 - SvenDowideit
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.