• 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.

The definitions for 'compose' include "... to make or create .."

See http://dictionary.reference.com/search?q=compose and http://thesaurus.reference.com/search?q=compose&start=11

These definitions and synonyms infer 'create' rather than 'edit exisitng'.

I suggest we find another tem. See http://thesaurus.reference.com/search?q=edit for some suggestions
-- AJA

I concur. See Item574


Agreed. This is just using wysiwyg editor... --TW
If 'revise' is too uncommon, you could use 'modify' (just a synonym for 'edit') or 'style'.

Just my two cents. -- FJ

Also possible: use Edit for WYSIWYG, and Source or Page Source for TWikiML editing. -- AC
Now that (AC's suggestion) makes more sense!
Other sites & applications seem to use a WYSIWYG as the default editor. The problem is that browser display the source, what we call the RAW, when the "Page Source" item on the menu is chosen. Its not editable.
  • "Raw" is also not so fine term. "View source" could be used for this, but that conflicts with "Source" or "Page source". While "Edit source" conflicts with "Edit"... -- AC

We do need to make it clear that one is the "old" TWikML editor and the other is the "new" WYSIWYG editor, so works like "revise" and "modify" and othr synonyms for 'edit' are not going to do the job.

The only easy solution I see is to have ballons on all the items.

  • You mean help tips? -- AC

-- AJA

  • What does the J stand for Anton? wink -- FJ

As I've stated elsewhere, I think the real problem here is having two edit links. I can't imagine how we can come up with two words that both mean, bascially, edit - that will also unambiguously communicate the distinction to new users. So how about this:
  • Have one default "edit" link that leads to wysiwyg.
  • Have a user preference to turn on a second "TML" link. If you know enough to turn on the preference, you'll know what it means (and it's short).


I notice that once started the WYSIWYG editor has the option of switching to HTML mode.

Is there any reason that

  1. This can't be extended to have 3 modes: WYSIWYG, HTML and TwikiML
  2. The mode is displayed (as an option pluu-down)
  3. The user can have a the prefernce setting that LB mentions to determine which mode the editor comes up in

This way there is only ever ONE edit button.

-- AJA

  • Oh what a coincidence, FJ. The J is the same as yours only its spelt and pronounced differently.

Good idea, Anton.

-- MC

I attempted to add a link within Kupu edit view that leads to TML edit but couldn't get it to work. (I couldn't get it to save changes in Kupu before switching. You can see my effort here. Click on Compose and see TML link at right end of toolbar.) My only further comment is this: let's not over-engineer a solution. KISS. I've put out a couple of simple solutions to add the TML link for those more knowledgeable users who will use it.


If we use "TML" for old style editing, it all becomes very enigmatic if the Kupu editor is not enabled. -- AC
  • No. Use the P{context="WysiwygPluginEnabled" then...= costruct allows the name to depend on context. -- AJA

There should be one edit button from view, not two as we have at present. If they happen to have multiple editors installed then put them in their default editor. The key is to provide, inside every editor, a means to switch to the other editors.


Agreed with MC's suggestion... Having two different edit buttons is no good... that implies that from the edit field one would switch to the other editors, if the user desired one is not available. Editor should really be chosen from the preferences (or a skin, if so desired... here is once again where additive skins come in really handy...) --TW
I am not saying that there should be 2 Edit buttons. Only if WYSIWYG is not enabled, there is only the TML button, and having only one button that says "TML" is not a good interface.
  • That's not a problem. The button names can be determined with a P{context="WysiwygPluginEnabled" then...= clause. - AJA

So both buttons should be labeld "Edit". But that implies that the user can either choose WYSIWYG or TML, not both. -- AC

> I am not saying that there should be 2 Edit buttons
> So both buttons should be labeled "Edit".


  • I was trying to say: not 2 edit buttons simultaneously visible. But forget it, better solutions are offered on this page. -- AC


Did you have had a look on TWiki:Codev.JotSpots solution (http://hotspot.jot.com/WikiHome). They provide a drop down type of tab. I also like their solution for the More... Just move the mouse over their More Actions... link and see. -- FJ
JotSpot does not work well on Safari. The folding out layers go everywhere on the page. But that is not the point here. The dropdown could work if the selection is remembered and the next click on Edit opens the edit window in the same manner as previously.

But I am hesitant for the UI scripting at this stage. -- AC

I guess the main problem is that is preferable to keep the identifiers as short as possible - but it's just not that easy. And with I18N versions it just gets (a lot) worse :-). So I say, as long as we have a "Raw text" link in the bottom bar, best bet is to have a "Edit" button first (Kupu) and a "Edit raw" second (trad). At least that would be consistent regarding the "raw" terminology, and the not-so-geek world definetely wants their wysiwyg badly - so let the kupu link show up first as just "Edit" .. the rest of us can hit the link (Access key! ;-)) of our choice.

BTW: A multiple choice is already at the bottom; the "Backlinks: Web, All Webs". If we happen to come up with a handy solution for the multiple editor choice, that might be used for that choice as well(?).

AC: I agree on the "remember last choice"-part. If we choose to go with something like the dropdown, it should 1) be very clear what you are going to get and 2) it should default to last choice, of course. Having to select your non-default editor of choice just two times in a row is annoying. -- SP.

The 'Edit' and 'Edit raw' solution sounds tolelrable to me. As Steffan points out, the terminology is consistent.

Lets just hope that it doens't map to an 18 charecter word in some language. German is bad enough to 'break' the field width visual balance on the NatSkin.

-- AJA

Consistency is good because it gives the least surprise to users. I'd say, let's go for "Edit" and "Edit raw"

-- PTh

Please make sure that when the WYSIWYG plugin is not installed, it says "edit" when you use the standard edit cycle, not "edit raw" -- TW

  • I agree on this part. -- SP.

"Edit raw" is not really good for the standard "edit" also because the WYSIWYG plugin cannot replace the edit fully. The "raw" makes it sound like this is going into the database and hacking the file directly (and might scare folks away). However, as far as I understand, the WYSIWYG editor is not able to completely edit all TWiki ML. In particular, variables and tags are largely excuded, I am told. -- TW

  • It's a feature of the WysiwygPlugin, that it is "Full round-trip (TWiki syntax -> XHTML -> TWiki syntax)". As goes for the edit part, I believe you're right, the plugin is not best choice for editing pages when you're in a TML mood - none the less, it should support TML fully, else it is time to file a bug report smile -- SP.

"Edit code" is another alternative. Manager types tend to know what code is, and that they want to stay away from it. Same goes for Sushi, some might say.

-- MC

mmm, this is alot of to-ing and fro-ing for a plugin that is not in the release!

the requirements are quite clear:

  • normal TML edit must be named 'Edit' when there is no WYSIWYG plugin
  • normal TML edit must still be available when WYSIWYG plugin is installed
  • WYSIWYG plugin's edit link needs to be the one with the 'i'm extra, and better' name. otherwise, users moveing between twiki installations with and without WYSIWYG plugin will have a surprise when they hit edit.

so - an obvious choice would be 'Wysiwyg Edit'.....

  • Isn't that where we started from? -- AJA

i'm thinking of making this an enhancment, as its not a show stopper, just a refinement

-- SD

We started by saying Compose sounds like Create and we need two Edits. We then moved to we need One Edit button on the view page (which should be dictated by the user's preference, and the user should be able to toggle between edit modes while editing). Nothing has come of that.

  • No. We started with buttons "Edit" and "Wysiwyg". The "Wysiwyg" was cahnged to "Compose" and I posted tis bug. -- AJA

I then said I wanted to add a button to 'Create' to lead us to the WebTopicCreator. Nothing has come of that as I am waiting for feedback.

  • I already have it on my site where its approriate but its based on Lynnwood's code. Its not appropriate for all webs. -- AJA

We're now back to discussing what the two edit buttons should be called.

-- MC

unless you guys have some magic code thats not yet in svn, the 'toggle between edit modes while editing' is just dreaming? so really, you guys don't seem to have gone anywhere that is realistic in the timeframe we have. ALL i'm trying to do is give you enough feedback so you have some idea whats needed so that any change is made at all. This is not the place for a discussion, its the place for action..

-- SD

One more plea for keeping it simple:

  • Have one and only one Edit link. If Wysiwyg is enabled, Edit leads to Wysiwyg edit mode. If not, it leads to TML edit mode. (BTW, it appears that AJA, MC, TW along with myself have all endorsed this approach at some point in this discussion.)
  • For now, If Wysiwyg is enabled, leave it up to the advanced users who want a TML edit link to add it to their WebLeftBar. (or on More topic actions - MC) (We can provide instructions with the sample code in TWikiAdminCookBook or somewhere.)

Basically, I;m making the case for the short term to make it as non-confusing as possible for the most number of and least sophisticated users. It's trivial for users who understand TML to add the second edit option if they want it. Then later, we can implement a more sophisticated solution. I just hate the idea of Dakar going out with something so basic as the Edit link being confusing.


are you guys intentionally overlooking the fact that the Wysiwyg editor is not going out with Dakar at all? I'm kinda confused but all this discussio about something template instructions that should not really be made here at all (as it does not help anyone that is not in the DevelopCommiters group with solving how to distribute modifications to the distributed topics...)

the short term thus will NOT be misleading if we leave compose in place, as only advanced users that are helping test WysiwygPlugin will have it installed...

quite puzzeled.

-- SD

> the short term thus will NOT be misleading if we leave compose in place, as only advanced users that are helping test WysiwygPlugin will have it installed...

I'd venture that WYSIWYG is the single most end-user demanded feature and it is the novice users that will benefit most. Although it is rightly a plugin, many will install it and thus most novices will be faced with two buttons.

-- MC

you can venture all you like smile playing with mini-edit, i've found a hacky way for my plugin to add its own edit link to the view'd page... -- SD

this is obviously a discussion, and as such needs to be taken up on Codev, when a concensus is reached, bring it back

-- SD

I am very puzzled about "the fact that the Wysiwyg editor is _not going out with Dakar at all". Follow-up in AddWysiwygPluginToDakar.

-- PTh

Summary "Compose" on the topicaction bar sounds too much like create
ReportedBy TWiki:Main.AntonAylward
SVN Range

AppliesTo Engine

Priority Low
CurrentState No Action Required

Edit | Attach | Watch | Print version | History: r41 < r40 < r39 < r38 < r37 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r41 - 2006-01-03 - PeterThoeny
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback