• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

I am not happy with this change to having an edit button that either do one mode or the other.

So now I will have to edit my user preferences or manually edit the URL to switch between WYSIWYG and normal Edit mode????

That is not smart. That is bad. Very bad. And not at all user friendly.

The WYSIWYG editor is not at all a replacement for normal edit. You cannot edit half the features TWiki has with WYSIWYG. It is not a matter of some people ALWAYS wanting to use WYSIWYG and never normal edit mode. And other people ALWAYS wanting the normal edit mode. Sometimes you will be editing with WYSIWYG. That will be when you are editing normal text and a lot of it. And sometimes you will edit in normal mode and that will be when you are working on a complex formatted search.

I easily see the two editors used on the same topic by the same person. First you edit a lot of the text. And then you adjust some of the TWiki codes in a search or something else where the WYSIWYG editor cannot handle it. We know that WYSIWYG cannot handle everything.

I am sure that the most users would like to have two buttons - as standard - both at the top and at the bottom. Just the past weeks of testing it has irritated me that the edit button was only at the bottom because I could not edit everything in WYSIWYG.

IF you want to give this feature to someone then use TWO variable.

One that enables the EDIT button.

And one that enables the COMPOSE button.

Then you give people the freedom of choice

-- TWiki:Main.KennethLavrsen

OK, let me explain.

There is strong user resistance to having two edit links on the view page. Why?

  1. It is dangerous - accidental clicks on the TML edit could alienate 90% of users - especially PHBs
  2. "Compose" (the word) is not intention-revealing, and no-one has suggested anything better
  3. 90% of users are TTTSWTG (Too Thick To See What They Get) with the TML editor
  4. It clutters up an already over-busy page
The problem is that some users still want/need TML, to edit TWiki variables etc. But they are a minority. The problem is to give 10% access to what they want, without alienating 90%. My thinking ran as follows:
  1. Most people who want to WYSIWYG want to WYSIWYG all the time. Not true! My users want TML for making TWiki apps and small topics and WYSIWYG for meeting minutes and ISO9000 docs - KennethLavrsen
  2. Most people who want to edit in TML, want to edit in TML all the time.
  3. A local site can add extra commands to their local skin, if they want both links available.
  4. The edit modes are switchable from the URL bar. Just append ?skin=kupu or ?skin=pattern to the edit URL.
  5. The people who want to edit in TML are smart enough to be able to use the URL bar to switch editor if EDIT_SKIN=kupu
  6. The default skin (out of the box) should be simple as possible
  7. If someone wants to tailor the skin for local use, it is a lot simpler for them to simply add a button, than it is to support the rather convoluted code that makes the optional Compose button.

-- CC

I have experimented with view.pattern.tmpl to see if I could make the function I personally wanted to see. And I think the result is fine like this. Yes there is an extra button to look at. And so what? I am sure this is what people want in reality.

People can still use EDIT_SKIN to set the default editor that comes up when you create a new topic. So the administrator can set EDIT_SKIN in TWikiPreferences to kupu. The PHBs and the newbies will get the WYSIWYG editing with the new topic. And the geeks, and nerds - like me - and most of us that move about on this bugs web - can set EDIT_SKIN = Pattern in our user topics.

So I propose having this built into Pattern skin. And live with the fact that skins will have to accomodate the WysiwygPlugin. It is an essential plugin that I am sure all will install so all skins should eventually support it.

I have attached my modified view.pattern.tmpl

I have no religious opinions what the two edit buttons should be called. Edit Raw/Compose, Edit/Compose, Geek Edit/PHB Edit. Whatever. As long as both buttons are there.

-- TWiki:Main.KennethLavrsen

I think using WYSIWYG all the time is way too dangerous in the current state of the editor, especially when naive users edit pages set up for them by power users (with heavy use of TWiki forms for instance: our blog system would be unusable)

My position would be:

[1] have a per-user preference variable * Set EDIT_MODE = raw that would make the edit pop up the raw editor (default would thus be kupu) A nice touch would be:

  • A button in raw edit to go kupu
  • A button in kupu to go raw edit
  • Ways to force kupu or raw edits via accelerators in the skin even if you do not want the 2 buttons
For us, we will definitely keep the 2 edit buttons.

[2] have the editor go into raw mode if the page was not edited with kupu before (kupu save would add an HTML comment, that could also be added by hand. Editing will use kupu only if this comment was present). Alternatively you may go into raw mode if you detect some constructs in the page (%SEARCH, %EDITTABLE...) la Jotspot

-- TWiki:Main.ColasNahaboo

Remember that the optional Compose button is available in Dakar only; it uses the new conditional constructs. Cairo users can still define two buttons and ignore EDIT_SKIN. Nothing sets it by default. Also, EDIT_SKIN is an additional feature; the existing approach, or programmatically adding buttons, still works, so the only thing that has been taken away is the PatternSkin-specific button logic.

Your "per user preference variable" is there with EDIT_SKIN (just set EDIT_SKIN=kupu in site prefs and then override with EDIT_SKIN=pattern per user).

This whole business of making the editor content-sensitive is obviously the best solution, but way too complex to handle in the plugin. Really we need to re-architect the edit script to be a lot smarter (there needs to be a way for a plugin to decide if it can edit the page or not), which is a lot of work, and would never be portable back to Cairo.

I doubt there are two people that can agree how the requirements should be for a context driven choice of WYSIWYG or TML. KennethLavrsen

CC

From what I can sense there is a significant (probably majority) of admins that has a user base that will need both edit buttons. And a significant minority that should not be ignored that want one button with a default action.

It should not be difficult to implement a solution where you can configure one or the other. This is one of the most essential user interface features and must work for everyone.

And it must be possible to jump directly to the edit mode you desire.

My user base is 200 engineers. Half are Lusers that hate TWiki because of lack of WYSIWYG. And the other half are super users that love the whole TWiki concept and make one brilliant Twiki app after the other. And those brilliant ones are the ones that use TWiki 90% of the time. And they clearly want both modes easily available. I just walked around and discussed this feature with some of my most active users. They all want both buttons available.

They want WYSIWYG when they edit our ISO9000 procedures which are long mostly text only documents. And the TML Edit mode for when they develop the TWiki apps (test plans, release control topics, action lists, etc etc).

I agree with CC that the Luser will press the wrong button because Compose and Edit are not mutually exclusive words. So maybe EDIT for WYSIWYG mode and some geek work for geek mode. "TML Edit" "Raw Edit" "Edit Code" "Markup Mode" ...

-- TWiki:Main.KennethLavrsen

Item568 had my workaround for a previous version of Dakar.

It worked by detecting whether WYSIWYG plugin was installed. If so, it added a new button "Edit Raw" next to "View Raw" in the bottom bar: techies would use this one. It also removed the top bar "Edit" button and replaced with "Compose".

-- MC

OK, OK, enough already. SVN 7771 puts it back. CC

You forgot that you had also implemented the smart feature EDIT_SKIN. If you set this to kupu, which is actually smart to do if you want WYSIWYG to be the default for the users when they create a new virgin topic.

But doing that makes the EDIT button open in WYSIWYG mode. So you have two WYSIWYG buttons and no edit button.

Your EDIT_SKIN feature is smart as such but then we have to add ?skin=pattern to the edit button in the Pattern skin.

Like I did in my attached view.pattern.tmpl file.

I have probably implemented it a silly way but it does the job the way I think it should work. Use it as a requirement demo if nothing else.

KJL (Kenneth Jahn Lavrsen)

SVN 7795

Personally I like it much better than 'Compose'...

CC

ItemTemplate
Summary Please provide buttons for both editors (WYSIWYG and TML)
ReportedBy KennethLavrsen
Codebase

SVN Range 7760-
AppliesTo Extension
Component PatternSkin
Priority Urgent
CurrentState Closed
WaitingFor

Checkins 7771 7795
Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formattmpl view.pattern.tmpl r2 r1 manage 6.4 K 2005-12-05 - 21:23 KennethLavrsen Kenneth's proposed solution to WYSIWYG AND Edit button version 2
Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2005-12-07 - CrawfordCurrie
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback