Text area helpers, Wiki Syntax and WYSIWYG and the strategic importance for TikiWiki

[Marc Laporte-4]

Hi!

My views on Wiki Syntax:
http://tikiwiki.org/Why+Wiki+Syntax+Is+Important

However, there is a big demand for WYSIWYG.
http://www.wikimatrix.org/statistic/Most+flagged

And WYSIWYG has many benefits but brings its set of challenges. For example:
http://dev.tikiwiki.org/WYSIWYG+observations

Part of the problem is that our integration with CKeditor is not as
seamless as it could be. But also, that WYSIWYG is a hard problem.  I
have heard for at least 5 years, "Wiki syntax is going to disappear,
and everything will be WYSIWYG". Yet, here we are.

"In 2009, there is no available 'ready-to-go' package for
incorporating full WYSIWYG into the MediaWiki software. The problem is
that any WYSIWYG editor would have to know wikitext grammar, and no
full grammar for wikitext exists - the "parser" doesn't parse, it's a
twisty series of regular expressions. So present WYSIWYG editors
either have to (a) reverse-engineer as much of a grammar as they can,
or (b) forget wikitext and just write HTML."
Source: http://www.mediawiki.org/wiki/WYSIWYG_editor

I just checked again, and CKEditor is __not__ using CKEditor for its
own wiki. If you create an account and click the following link, you
will see they are using the MediaWiki tools, which are very much like
our old quicktags.
http://docs.cksource.com/index.php?title=User_talk:Fredck&action=edit&redlink=1

Interesting, is it not?  CKeditor is using a wiki (they see value in a
wiki), but it's not WYSIWYG (you would think they should be able, no?)
So to all that are wondering if wiki projects (that are not doing both
Wiki & WYSIWYG) __are sitting on their hands__: If it was an easy
problem, it would be reliably solved by now!  :-)

A friend once told me that for some projects (not Tiki projects, but
another CMS), they "sell" WYSIWYG, but once the project starts, when
there are issues, they deactivate and resort to text. Mind you, the
type of application they were making was mostly forms and comments. So
WYSIWYG is less important for small text boxes.

I think the long term solution may very well be WYSIWYG, with a
smaller set of features and that generates Wiki Syntax. And Stéphane
(sept_7) is working on this. But it's more for Tiki5. It's not easy,
as work is needed on the parser first.
http://dev.tikiwiki.org/WikiParser


Looking down the road:
1- Perhaps there are some interesting things with CK editor, version 3.
2- Perhaps the jQuery way?
3- Perhaps this will be handled better in the browser? (even with a plugin)
4- Look at MoinMoin, XWiki, Foswiki/TWiki, etc for ideas (and hopefully code!)


Another idea: A perpetually refreshing second window, in AJAX, which
shows the output every 3-4 seconds?  Imagine a perpetually refreshing
preview section. Do you think this could work, and bring value?



But for now, people that need it to work reliably (I mean rock-solid,
no stressful support requests), what are we to do?

I think one of the reasons WYSIWYG is in demand is that it's perceived
easier to do certain things.  "my users won't learn code, etc. " I
disagree that wiki syntax for bold, italic, headers, etc. is a
barrier. The text is perfectly readable and there are tools (aka
quicktags). I teach users all the time, and it works.

Of course,
1- if you are not convinced yourself
2- if you don't explain the benefits of wiki syntax
3- if you don't show users how the toolbar removes their need to learn
any syntax

you'll be in trouble!

But show them section edit, headers and maketoc and see their eyes
light up. Show them beautiful diffs which are only possible with wiki
syntax!


However, things like making a hyperlink, and especially adding a
picture, etc are too difficult. This part I agree. So we need:
1- more "helpers"  -> http://ui.tikiwiki.org/Text+area+editing+helper
2- To keep the wiki syntax clean

Thus, Jonny has been putting a lot of efforts to improve these
helpers. We maintain Wiki syntax, but we make it easier to create.
Louis-Philippe had done a lot of great work in Tiki3 for plugins,
where you fill out a form instead of copy-pasting the code from docs
or help and then, editing.

Text area helpers are a star feature for Tiki4 and they are of
strategic importance for Tiki. I ask everyone for your help to make
this better. And safe enhancements here can be an exception to the
feature freeze. We are now starting to reap major benefits from
jQuery. Special thanks to Jonny & Matthew for their energy in this
direction!

In short, if we have enough helpers, which are jQuery-based and
cross-browser, we can improve the usability of the wiki syntax editing
and reduce demand for WYSIWYG. (call it quasi-WYSIWYG)

This makes Tiki easier to use, and yet as powerful and stable as
before. And the current CKeditor option is there, as always.

In my next email, I will send some specific suggestions to improve the
current text area helpers.

Best regards,


--
Marc Laporte

http://MarcLaporte.com
http://TikiWiki.org/MarcLaporte
http://AvanTech.net
http://OurWiki.net

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

[Kerr, Michael E (Mike)]

Is it worth looking at XML as a baseline, using HTML for the wysisyg and converting its markup and using special objects and additional custom markup (essentially making plugins and advanced wiki options objects of some sort within the text)?

It may not be lightning fast, but at least (I think) it would work.  I'd advocate converting everything to xml but that would require massive rewrites and wouldn't be backward-compatible.  If you could convert plugins and advanced wiki markup into objects and have the wysiwyg handle them as such (click on them and a window pops up with settings), then I think it could be accomplished.

May be slow, but we could at least brag we had the first implementation of it.

Mike.

______________________________
Mike Kerr
Sr. Internet Network Engineer
[phone]
mike.kerr@...

"I didn't come here to be ordinary."

 

verizonbusiness

global capability. personal accountability.
http://www.verizonbusiness.com

This e-mail is strictly confidential and intended only for use by the addressee unless otherwise indicated.

-----Original Message-----
From: Marc Laporte [mailto:marclaporte@...]
Sent: Monday, October 12, 2009 2:19 PM
To: Tikiwiki developers
Subject: [Tikiwiki-devel] Text area helpers,Wiki Syntax and WYSIWYG and the strategic importance for TikiWiki

Hi!

My views on Wiki Syntax:
http://tikiwiki.org/Why+Wiki+Syntax+Is+Important

However, there is a big demand for WYSIWYG.
http://www.wikimatrix.org/statistic/Most+flagged

And WYSIWYG has many benefits but brings its set of challenges. For example:
http://dev.tikiwiki.org/WYSIWYG+observations

Part of the problem is that our integration with CKeditor is not as
seamless as it could be. But also, that WYSIWYG is a hard problem.  I
have heard for at least 5 years, "Wiki syntax is going to disappear,
and everything will be WYSIWYG". Yet, here we are.

"In 2009, there is no available 'ready-to-go' package for
incorporating full WYSIWYG into the MediaWiki software. The problem is
that any WYSIWYG editor would have to know wikitext grammar, and no
full grammar for wikitext exists - the "parser" doesn't parse, it's a
twisty series of regular expressions. So present WYSIWYG editors
either have to (a) reverse-engineer as much of a grammar as they can,
or (b) forget wikitext and just write HTML."
Source: http://www.mediawiki.org/wiki/WYSIWYG_editor

I just checked again, and CKEditor is __not__ using CKEditor for its
own wiki. If you create an account and click the following link, you
will see they are using the MediaWiki tools, which are very much like
our old quicktags.
http://docs.cksource.com/index.php?title=User_talk:Fredck&action=edit&redlink=1

Interesting, is it not?  CKeditor is using a wiki (they see value in a
wiki), but it's not WYSIWYG (you would think they should be able, no?)
So to all that are wondering if wiki projects (that are not doing both
Wiki & WYSIWYG) __are sitting on their hands__: If it was an easy
problem, it would be reliably solved by now!  :-)

A friend once told me that for some projects (not Tiki projects, but
another CMS), they "sell" WYSIWYG, but once the project starts, when
there are issues, they deactivate and resort to text. Mind you, the
type of application they were making was mostly forms and comments. So
WYSIWYG is less important for small text boxes.

I think the long term solution may very well be WYSIWYG, with a
smaller set of features and that generates Wiki Syntax. And Stéphane
(sept_7) is working on this. But it's more for Tiki5. It's not easy,
as work is needed on the parser first.
http://dev.tikiwiki.org/WikiParser


Looking down the road:
1- Perhaps there are some interesting things with CK editor, version 3.
2- Perhaps the jQuery way?
3- Perhaps this will be handled better in the browser? (even with a plugin)
4- Look at MoinMoin, XWiki, Foswiki/TWiki, etc for ideas (and hopefully code!)


Another idea: A perpetually refreshing second window, in AJAX, which
shows the output every 3-4 seconds?  Imagine a perpetually refreshing
preview section. Do you think this could work, and bring value?



But for now, people that need it to work reliably (I mean rock-solid,
no stressful support requests), what are we to do?

I think one of the reasons WYSIWYG is in demand is that it's perceived
easier to do certain things.  "my users won't learn code, etc. " I
disagree that wiki syntax for bold, italic, headers, etc. is a
barrier. The text is perfectly readable and there are tools (aka
quicktags). I teach users all the time, and it works.

Of course,
1- if you are not convinced yourself
2- if you don't explain the benefits of wiki syntax
3- if you don't show users how the toolbar removes their need to learn
any syntax

you'll be in trouble!

But show them section edit, headers and maketoc and see their eyes
light up. Show them beautiful diffs which are only possible with wiki
syntax!


However, things like making a hyperlink, and especially adding a
picture, etc are too difficult. This part I agree. So we need:
1- more "helpers"  -> http://ui.tikiwiki.org/Text+area+editing+helper
2- To keep the wiki syntax clean

Thus, Jonny has been putting a lot of efforts to improve these
helpers. We maintain Wiki syntax, but we make it easier to create.
Louis-Philippe had done a lot of great work in Tiki3 for plugins,
where you fill out a form instead of copy-pasting the code from docs
or help and then, editing.

Text area helpers are a star feature for Tiki4 and they are of
strategic importance for Tiki. I ask everyone for your help to make
this better. And safe enhancements here can be an exception to the
feature freeze. We are now starting to reap major benefits from
jQuery. Special thanks to Jonny & Matthew for their energy in this
direction!

In short, if we have enough helpers, which are jQuery-based and
cross-browser, we can improve the usability of the wiki syntax editing
and reduce demand for WYSIWYG. (call it quasi-WYSIWYG)

This makes Tiki easier to use, and yet as powerful and stable as
before. And the current CKeditor option is there, as always.

In my next email, I will send some specific suggestions to improve the
current text area helpers.

Best regards,


--
Marc Laporte

http://MarcLaporte.com
http://TikiWiki.org/MarcLaporte
http://AvanTech.net
http://OurWiki.net

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

[Marc Laporte-4]

> I just checked again, and CKEditor is __not__ using CKEditor for its
> own wiki. If you create an account and click the following link, you
> will see they are using the MediaWiki tools, which are very much like
> our old quicktags.
> http://docs.cksource.com/index.php?title=User_talk:Fredck&action=edit&redlink=1
>
> Interesting, is it not?  CKeditor is using a wiki (they see value in a
> wiki), but it's not WYSIWYG (you would think they should be able, no?)
> So to all that are wondering if wiki projects (that are not doing both
> Wiki & WYSIWYG) __are sitting on their hands__: If it was an easy
> problem, it would be reliably solved by now!  :-)
>

On a related note, another well-known editor "TinyMCE", doesn't use
WYSIWYG for its own wiki:
http://wiki.moxiecode.com/

Now, Jonny did a fantastic job, and I feel we now have quasi-WYSIWYG
in Tiki4. We have helpers for almost everything. This will refine over
time. Great stuff!

Now, back to CKEditor-style WYSIWYG:  I __may__ be involved on a
WYSIWYG project for Tiki5. However, I will not do so unless I have a
serious contingent of people that will volunteer for testing.

For all people that say WYSIWYG is important, I have a challenge for
you. I am asking you to put your time where your mouth is :-)

You can look at all the wiki engines or CMS's open source or not.
Please try to find at least one
- wiki engine that has WYSIWYG, that maintains wiki syntax.
- or does the round-trip in a reliable way.

__Don't__ tell me
* there is a plugin, or
* it's on the feature list, or
* in the next version, it's coming
* If there is progress, I will sign-up as a Beta tester.
* I found this page that talks about it
*etc.

I need credible action/proof, that there is a real desire/need/energy.
WYSIWYG will need lots of testers, with all the browsers.

This is an example of credible action:
http://dev.tikiwiki.org/WYSIWYG+observations
I expect such a page for each solution that is found.

The benefit of WYSIWYG while maintaining wiki syntax, is that we could
disable for less reliable browsers. Ex.: WYSWYG only for FF3, for
example.

I need you to find or setup a live demo that we can all play with.

If no one follows up on this, I will conclude that ->
A- There are no examples or real World solutions so it's "impossible"
with the state of current technology. So it's a losing battle.
or
B- It's not a real-enough need in our community and we won't be able
to have enough Beta testers to make this reliable. So it's a losing
battle.

Either way, I will not embark in the project.

But if some of you put your time where your mouth is... :-)

So, any volunteers?

Thanks!

M ;-)

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

 Hi Marc

As you know I am totally convinced that there is a large user constituency
'out there' that will only work with a wysiwyg editor no matter how 'smooth'
a wiki text editor we have. This type of user base is one that has little or
no technical background and they just find the use of exposed control
characters to create styling etc too alien. Although interestingly they
readily accept the use of plugins and other { } functions that do special
things for them eg {toc}.

The good news from my perspective is that this user base isn't too demanding
- the CKEditor functionality is pretty good, although there are some gaps,
which may be just to do with the Tiki implementation. What I think we just
need to do is focus on making it a lot more bullet proof.

Since I'm living with a growing body of users that use the current wysiwyg
editor every day I am building up quite a body of knowledge of where it goes
wrong etc., and will continue to add to the 'observation' pages. So I'm more
than happy to test tiki developments and help focus upon some of the key
problems. I also have a Tiki test site that I synch regularly with trunk
that I would be more than happy to be used for on-going Tiki wysiwyg testing
by anyone that wants to use it. This test site already has a range of
configs/test pages for various wysiwyg issues. I'm also increasingly testing
with a browser set that includes IE7/8, Chrome, Safari, and Opera plus FF of
course which is my standard.

I've not researched what else is 'out there' but my time is absolutely
available for anything that moves us forward with this.

Cheers

geoff



-----Original Message-----
From: Marc Laporte [mailto:marclaporte@...]
Sent: 01 November 2009 17:14
To: Tikiwiki developers
Subject: Re: [Tikiwiki-devel] Text area helpers,Wiki Syntax and WYSIWYG and
the strategic importance for TikiWiki

> I just checked again, and CKEditor is __not__ using CKEditor for its
> own wiki. If you create an account and click the following link, you
> will see they are using the MediaWiki tools, which are very much like
> our old quicktags.
> http://docs.cksource.com/index.php?title=User_talk:Fredck&action=edit&
> redlink=1
>
> Interesting, is it not?  CKeditor is using a wiki (they see value in a
> wiki), but it's not WYSIWYG (you would think they should be able, no?)
> So to all that are wondering if wiki projects (that are not doing both
> Wiki & WYSIWYG) __are sitting on their hands__: If it was an easy
> problem, it would be reliably solved by now!  :-)
>

On a related note, another well-known editor "TinyMCE", doesn't use WYSIWYG
for its own wiki:
http://wiki.moxiecode.com/

Now, Jonny did a fantastic job, and I feel we now have quasi-WYSIWYG in
Tiki4. We have helpers for almost everything. This will refine over time.
Great stuff!

Now, back to CKEditor-style WYSIWYG:  I __may__ be involved on a WYSIWYG
project for Tiki5. However, I will not do so unless I have a serious
contingent of people that will volunteer for testing.

For all people that say WYSIWYG is important, I have a challenge for you. I
am asking you to put your time where your mouth is :-)

You can look at all the wiki engines or CMS's open source or not.
Please try to find at least one
- wiki engine that has WYSIWYG, that maintains wiki syntax.
- or does the round-trip in a reliable way.

__Don't__ tell me
* there is a plugin, or
* it's on the feature list, or
* in the next version, it's coming
* If there is progress, I will sign-up as a Beta tester.
* I found this page that talks about it
*etc.

I need credible action/proof, that there is a real desire/need/energy.
WYSIWYG will need lots of testers, with all the browsers.

This is an example of credible action:
http://dev.tikiwiki.org/WYSIWYG+observations
I expect such a page for each solution that is found.

The benefit of WYSIWYG while maintaining wiki syntax, is that we could
disable for less reliable browsers. Ex.: WYSWYG only for FF3, for example.

I need you to find or setup a live demo that we can all play with.

If no one follows up on this, I will conclude that ->
A- There are no examples or real World solutions so it's "impossible"
with the state of current technology. So it's a losing battle.
or
B- It's not a real-enough need in our community and we won't be able to have
enough Beta testers to make this reliable. So it's a losing battle.

Either way, I will not embark in the project.

But if some of you put your time where your mouth is... :-)

So, any volunteers?

Thanks!

M ;-)



No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 8.5.423 / Virus Database: 270.14.40/2471 - Release Date: 11/01/09
07:38:00


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

[luci aka luciash d' being]

+1 for your reply geoff :)

On 11/01/2009 07:57 PM, geoff@enmore wrote:

>  Hi Marc
>
> As you know I am totally convinced that there is a large user constituency
> 'out there' that will only work with a wysiwyg editor no matter how 'smooth'
> a wiki text editor we have. This type of user base is one that has little or
> no technical background and they just find the use of exposed control
> characters to create styling etc too alien. Although interestingly they
> readily accept the use of plugins and other { } functions that do special
> things for them eg {toc}.
>
> The good news from my perspective is that this user base isn't too demanding
> - the CKEditor functionality is pretty good, although there are some gaps,
> which may be just to do with the Tiki implementation. What I think we just
> need to do is focus on making it a lot more bullet proof.
>
> Since I'm living with a growing body of users that use the current wysiwyg
> editor every day I am building up quite a body of knowledge of where it goes
> wrong etc., and will continue to add to the 'observation' pages. So I'm more
> than happy to test tiki developments and help focus upon some of the key
> problems. I also have a Tiki test site that I synch regularly with trunk
> that I would be more than happy to be used for on-going Tiki wysiwyg testing
> by anyone that wants to use it. This test site already has a range of
> configs/test pages for various wysiwyg issues. I'm also increasingly testing
> with a browser set that includes IE7/8, Chrome, Safari, and Opera plus FF of
> course which is my standard.
>
> I've not researched what else is 'out there' but my time is absolutely
> available for anything that moves us forward with this.
>
> Cheers
>
> geoff
>
>
>
> -----Original Message-----
> From: Marc Laporte [mailto:marclaporte@...]
> Sent: 01 November 2009 17:14
> To: Tikiwiki developers
> Subject: Re: [Tikiwiki-devel] Text area helpers,Wiki Syntax and WYSIWYG and
> the strategic importance for TikiWiki
>
>  
>> I just checked again, and CKEditor is __not__ using CKEditor for its
>> own wiki. If you create an account and click the following link, you
>> will see they are using the MediaWiki tools, which are very much like
>> our old quicktags.
>> http://docs.cksource.com/index.php?title=User_talk:Fredck&action=edit&
>> redlink=1
>>
>> Interesting, is it not?  CKeditor is using a wiki (they see value in a
>> wiki), but it's not WYSIWYG (you would think they should be able, no?)
>> So to all that are wondering if wiki projects (that are not doing both
>> Wiki & WYSIWYG) __are sitting on their hands__: If it was an easy
>> problem, it would be reliably solved by now!  :-)
>>
>>    
>
>
> On a related note, another well-known editor "TinyMCE", doesn't use WYSIWYG
> for its own wiki:
> http://wiki.moxiecode.com/
>
> Now, Jonny did a fantastic job, and I feel we now have quasi-WYSIWYG in
> Tiki4. We have helpers for almost everything. This will refine over time.
> Great stuff!
>
> Now, back to CKEditor-style WYSIWYG:  I __may__ be involved on a WYSIWYG
> project for Tiki5. However, I will not do so unless I have a serious
> contingent of people that will volunteer for testing.
>
> For all people that say WYSIWYG is important, I have a challenge for you. I
> am asking you to put your time where your mouth is :-)
>
> You can look at all the wiki engines or CMS's open source or not.
> Please try to find at least one
> - wiki engine that has WYSIWYG, that maintains wiki syntax.
> - or does the round-trip in a reliable way.
>
> __Don't__ tell me
> * there is a plugin, or
> * it's on the feature list, or
> * in the next version, it's coming
> * If there is progress, I will sign-up as a Beta tester.
> * I found this page that talks about it
> *etc.
>
> I need credible action/proof, that there is a real desire/need/energy.
> WYSIWYG will need lots of testers, with all the browsers.
>
> This is an example of credible action:
> http://dev.tikiwiki.org/WYSIWYG+observations
> I expect such a page for each solution that is found.
>
> The benefit of WYSIWYG while maintaining wiki syntax, is that we could
> disable for less reliable browsers. Ex.: WYSWYG only for FF3, for example.
>
> I need you to find or setup a live demo that we can all play with.
>
> If no one follows up on this, I will conclude that ->
> A- There are no examples or real World solutions so it's "impossible"
> with the state of current technology. So it's a losing battle.
> or
> B- It's not a real-enough need in our community and we won't be able to have
> enough Beta testers to make this reliable. So it's a losing battle.
>
> Either way, I will not embark in the project.
>
> But if some of you put your time where your mouth is... :-)
>
> So, any volunteers?
>
> Thanks!
>
> M ;-)
>
>
>
> No virus found in this outgoing message.
> Checked by AVG - www.avg.com
> Version: 8.5.423 / Virus Database: 270.14.40/2471 - Release Date: 11/01/09
> 07:38:00
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
> -------------------------------------------
> Modern Hosting PIPNI - http://www.pipni.cz/
>
>  

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

[Marc Laporte-3]

Hi!

Thank you all for your messages of support. You are all saying it's
important and a good project.

People want WYSIWYG like World Peace :-)

However, my last email was not about asking people if they thought it
was a good idea. I had a specific challenge, and in 3 weeks, no one
has taken it up. So for the reasons explained previously, I will
__not__ be taking on this project. I do hope someone else does, cause
I want WYSIWYG too!

However, I will continue to push to improve usability of the Wiki
interface. Here are some ideas on the next steps:
http://dev.tikiwiki.org/WYSIWYG-ish+wiki   ( I'd appreciate some feedback )

Best regards,

M ;-)


On Sun, Nov 1, 2009 at 3:56 PM, luci aka luciash d' being <sf@...> wrote:

> +1 for your reply geoff :)
>
> On 11/01/2009 07:57 PM, geoff@enmore wrote:
>>  Hi Marc
>>
>> As you know I am totally convinced that there is a large user constituency
>> 'out there' that will only work with a wysiwyg editor no matter how 'smooth'
>> a wiki text editor we have. This type of user base is one that has little or
>> no technical background and they just find the use of exposed control
>> characters to create styling etc too alien. Although interestingly they
>> readily accept the use of plugins and other { } functions that do special
>> things for them eg {toc}.
>>
>> The good news from my perspective is that this user base isn't too demanding
>> - the CKEditor functionality is pretty good, although there are some gaps,
>> which may be just to do with the Tiki implementation. What I think we just
>> need to do is focus on making it a lot more bullet proof.
>>
>> Since I'm living with a growing body of users that use the current wysiwyg
>> editor every day I am building up quite a body of knowledge of where it goes
>> wrong etc., and will continue to add to the 'observation' pages. So I'm more
>> than happy to test tiki developments and help focus upon some of the key
>> problems. I also have a Tiki test site that I synch regularly with trunk
>> that I would be more than happy to be used for on-going Tiki wysiwyg testing
>> by anyone that wants to use it. This test site already has a range of
>> configs/test pages for various wysiwyg issues. I'm also increasingly testing
>> with a browser set that includes IE7/8, Chrome, Safari, and Opera plus FF of
>> course which is my standard.
>>
>> I've not researched what else is 'out there' but my time is absolutely
>> available for anything that moves us forward with this.
>>
>> Cheers
>>
>> geoff
>>
>>
>>
>> -----Original Message-----
>> From: Marc Laporte [mailto:marclaporte@...]
>> Sent: 01 November 2009 17:14
>> To: Tikiwiki developers
>> Subject: Re: [Tikiwiki-devel] Text area helpers,Wiki Syntax and WYSIWYG and
>> the strategic importance for TikiWiki
>>
>>
>>> I just checked again, and CKEditor is __not__ using CKEditor for its
>>> own wiki. If you create an account and click the following link, you
>>> will see they are using the MediaWiki tools, which are very much like
>>> our old quicktags.
>>> http://docs.cksource.com/index.php?title=User_talk:Fredck&action=edit&
>>> redlink=1
>>>
>>> Interesting, is it not?  CKeditor is using a wiki (they see value in a
>>> wiki), but it's not WYSIWYG (you would think they should be able, no?)
>>> So to all that are wondering if wiki projects (that are not doing both
>>> Wiki & WYSIWYG) __are sitting on their hands__: If it was an easy
>>> problem, it would be reliably solved by now!  :-)
>>>
>>>
>>
>>
>> On a related note, another well-known editor "TinyMCE", doesn't use WYSIWYG
>> for its own wiki:
>> http://wiki.moxiecode.com/
>>
>> Now, Jonny did a fantastic job, and I feel we now have quasi-WYSIWYG in
>> Tiki4. We have helpers for almost everything. This will refine over time.
>> Great stuff!
>>
>> Now, back to CKEditor-style WYSIWYG:  I __may__ be involved on a WYSIWYG
>> project for Tiki5. However, I will not do so unless I have a serious
>> contingent of people that will volunteer for testing.
>>
>> For all people that say WYSIWYG is important, I have a challenge for you. I
>> am asking you to put your time where your mouth is :-)
>>
>> You can look at all the wiki engines or CMS's open source or not.
>> Please try to find at least one
>> - wiki engine that has WYSIWYG, that maintains wiki syntax.
>> - or does the round-trip in a reliable way.
>>
>> __Don't__ tell me
>> * there is a plugin, or
>> * it's on the feature list, or
>> * in the next version, it's coming
>> * If there is progress, I will sign-up as a Beta tester.
>> * I found this page that talks about it
>> *etc.
>>
>> I need credible action/proof, that there is a real desire/need/energy.
>> WYSIWYG will need lots of testers, with all the browsers.
>>
>> This is an example of credible action:
>> http://dev.tikiwiki.org/WYSIWYG+observations
>> I expect such a page for each solution that is found.
>>
>> The benefit of WYSIWYG while maintaining wiki syntax, is that we could
>> disable for less reliable browsers. Ex.: WYSWYG only for FF3, for example.
>>
>> I need you to find or setup a live demo that we can all play with.
>>
>> If no one follows up on this, I will conclude that ->
>> A- There are no examples or real World solutions so it's "impossible"
>> with the state of current technology. So it's a losing battle.
>> or
>> B- It's not a real-enough need in our community and we won't be able to have
>> enough Beta testers to make this reliable. So it's a losing battle.
>>
>> Either way, I will not embark in the project.
>>
>> But if some of you put your time where your mouth is... :-)
>>
>> So, any volunteers?
>>
>> Thanks!
>>
>> M ;-)
>>
>>
>>
>> No virus found in this outgoing message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.423 / Virus Database: 270.14.40/2471 - Release Date: 11/01/09
>> 07:38:00
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Tikiwiki-devel mailing list
>> Tikiwiki-devel@...
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>> -------------------------------------------
>> Modern Hosting PIPNI - http://www.pipni.cz/
>>
>>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

--
Marc Laporte

http://MarcLaporte.com
http://TikiWiki.org/MarcLaporte
http://AvanTech.net
http://OurWiki.net

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel