Re: The WYSIWYG of my dreams

[Seth Warburton]

Just found out that Amy Stephen maintains a fork of Redactor from before they changed the license model: 

https://github.com/AmyStephen/redactor-js 

Result!

On Tuesday, September 4, 2012 4:56:04 PM UTC+1, Seth Warburton wrote:

Joomla needs this (or something just like it): http://redactorjs.com/

Beautiful, lightweight and works amazingly well on small (mobile) screens and touch devices. Neither of these are true for Joomla's current editor options.

As it needs only jQuery, which we are thankfully now loading, I can't see any issues with implementation.

Sure, it isn't GPL but their licensing would not seem to prohibit our use (with $99) and they certainly seem open to discussion ("..If you have specific installation needs not covered by this license, please contact us."). Maybe if we ask they would be happy for Joomla to use it under GPL. We can but ask!

[Nick Savov]

+1. Let's add it! :)

Two major areas that are lacking right now in the CMS:
1) Mobile-friendly WYSIWYG editor
2) A user-friendly Media Manager

https://github.com/AmyStephen/redactor-js would solve 1 of 2.

Kind regards,
Nick

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/tlWcDUrPBK0J.
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
>

[Seth Warburton]

Apparently the feature freeze for 3.0 is today. 

If I knew how to integrate this I would be coding it up right now and submitting a pull request. I don't.

There seems to be plenty of community interest (not hard to see why), but integrating this tonight is beyond the power of my kung fu. 

[Donald Gilbert]

I don't think that Joomla wants to be known as the CMS that uses improperly licensed code. While Amy does maintain a fork from before the license change, they did change the license for a reason, and they answer this situation directly. See this faq entry

I’m using Redactor with one of the previous versions of the license. Does the new license terms apply to me?
The current license agreement applies to all previous versions of Redactor.

How much this applies really is questionable, since code authors always maintain copyright with the ability to re-license as they see fit. And for $99, I don't see why it wouldn't be a viable option to just purchase the developer option and support the creators, rather than sticking it to them by distributing their code and not paying their requested price. Karma is a #$%^! they always say.

With that said, I LOVE that editor. If we can find a way to integrate it, it would be fantastic.

[Nick Savov]

Technically, that's illegal and they can't rescind the GPL license (if
that's what they were trying to do). With that being said, I'm not
proposing to "stick it to them", but if Amy is maintaining an open source
copy of it, we're free to do with it as we wish within the terms of the
GPL license that it's under.

Kind regards,
Nick

> I don't think that Joomla wants to be known as the CMS that uses
> improperly
> licensed code. While Amy does maintain a fork from before the license
> change, they did change the license for a reason, and they answer this
> situation directly. See this faq entry
>

> *I�m using Redactor with one of the previous versions of the license. Does
> the new license terms apply to me?*

> The current license agreement applies to all previous versions of
> Redactor.
>
> How much this applies really is questionable, since code authors always
> maintain copyright with the ability to re-license as they see fit. And for
> $99, I don't see why it wouldn't be a viable option to just purchase the
> developer option and support the creators, rather than sticking it to them
> by distributing their code and not paying their requested price. Karma is
> a
> #$%^! they always say.
>
> With that said, I LOVE that editor. If we can find a way to integrate it,
> it would be fantastic.
>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/6FtvAo5bf5cJ.

[Andrew Eddie]

If it was released under the GPL, there's nothing they can do to revoke that (that's the point of copyleft licenses).  However, does that mean it would be appropriate to drop in the core - I think not.  But this is exactly why we have extensions that you can install (hint, hint) :)  The downside is you have to maintain it and resist the urge to copy how they fixed bugs.  CKeditor is still the one for me though :D

Regards,

Andrew Eddie

[Fotis Evangelou]

Or Joomla!/OSM could perhaps kindly ask Imperavi (the company behind Redactor) to issue a special version of the editor to be included with the CMS - properly licensed.

That way, both parties benefit. Imperavi gets to advertise that its editor is used on the biggest (in terms of userbase) CMS in the world and Joomla! benefits from having a lightweight editor in that doesn't suck...

[Chacapamac]

Really nice editor, simple but still complete will be a nice addition. I see that it resize itself to the screen —Cool — I like it

[Matt Thomas]

On Wed, Sep 5, 2012 at 7:07 AM, Fotis Evangelou <fevan...@gmail.com> wrote:

Or Joomla!/OSM could perhaps kindly ask Imperavi (the company behind Redactor) to issue a special version of the editor to be included with the CMS - properly licensed.

+1

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain 

[Nick Savov]

Seth, since it's the WYSIWYG of your dreams :P, could you contact Imperavi
and see if they would be willing to partner with us on this?

Kind regards,
Nick

> On Wed, Sep 5, 2012 at 7:07 AM, Fotis Evangelou
> <fevan...@gmail.com>wrote:
>
>> Or Joomla!/OSM could perhaps kindly ask Imperavi (the company behind
>> Redactor) to issue a special version of the editor to be included with
>> the
>> CMS - properly licensed.
>
>
> +1
>
> Best,
>
> Matt Thomas

> Founder betweenbrain <http://betweenbrain.com/>�

> Lead Developer Construct Template Development

> Framework<http://construct-framework.com/>

> Phone: 203.632.9322
> Twitter: @betweenbrain
> Github: https://github.com/betweenbrain
>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.

[Nick Savov]

That's one that I wanted to integrate into Joomla, but it's not mobile
friendly based on someone else's feedback after testing it. Hopefully
they'll have a new version soon that is.

Kind regards,
Nick

> Before you get too wrapped up with redactor, you should also check out
> Aloha - alohaeditor.org
>
> If you have a Wordpress blog, there is a plugin available that shows off
> how nicely it can be integrated - in this case, incorporating the
> Wordpress image system. It also looks much more modern than redactor, a
> bit closer to Word.
>
>
> Joss

>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.

> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/FAtrJ1J0InwJ.

[Seth Warburton]

"On Wednesday, September 5, 2012 12:07:42 PM UTC+1, Fotis Evangelou wrote:

Or Joomla!/OSM could perhaps kindly ask Imperavi (the company behind Redactor) to issue a special version of the editor to be included with the CMS - properly licensed.

That way, both parties benefit. Imperavi gets to advertise that its editor is used on the biggest (in terms of userbase) CMS in the world and Joomla! benefits from having a lightweight editor in that doesn't suck..."

This would be my preferred option also. If they say no we can go ahead and use the GPL version, either way we will have done the right thing. 

Personally, I think an official approach would be better than me simply asking, though I would be happy to of course. 

[Mark Dexter]

Hi Seth. I think you can say in this regard you are acting on behalf
of the Joomla Production Leadership Team. Obviously, at this stage we
are only exploring the feasibility of this and are making no
commitments. If there is strong support in the community, and if it
works from a legal / licensing standpoint, I would be supportive. I
think we all agree that TinyMCE is not the end-all-be-all of editors.
Mark

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/A5BCa_4nmkIJ.

[Amy Stephen]

For clarification, I forked redactor and rolled back the commits following the license change because Babs and I hoped to include it in Molajo. We are aware that we could pay the developer fee of around $100USD and legally have permission to include it in our GPL v 2/MIT distribution but we are not comfortable passing along the CC no-commercial limitation to users. (Even though their instructions indicate that is fine, they could obviously change that at any time.)

No one should "feel" badly about forking GPL code when maintainers take it in a direction that isn't suitable for your needs. That's not bad Karma or sticking it to anyone, that's a user exercising their rights and it's nothing for anyone to be ashamed of or worried about. <end of my little sermon since I am not at all religious about licenses />

However, we found something we like better that Babs dropped into Molajo and we are evaluating it and leaning in that direction. Would encourage you all to take a good look at http://hallojs.org/ and also a companion product https://github.com/bergie/create

The author, Henri Bergius, is very accomplished https://github.com/bergie and his goal is to provide tools that work for multiple CMS's. He has worked on Aloha. We found Aloha to be buggy and (I'm sorry to say) not well maintained.

Hallo/Create are HTML5 solutions with a great interface for building frontend development experiences in that should dovetail nicely with the Bootstrap work. In addition, it has a very simple, OO approach to adding buttons and functionality that is very similar to Joomla's approach with extensions, so my thinking is it would be a good fit.

It is well maintained and the MIT license will be fine for Joomla.

If we (Molajo) go with Create/Hallo, I will take down my fork. If we use Redactor in Molajo, then obviously we'll support it but look for others willing to act as the maintainer.

In the past few days, about a half dozen Joomla devs forked Redactor from my copy so there is clearly interest in providing this in the Joomla world. Personally, I think it would be great for these devs to form a team and offer it as an extension to gauge the community interest. Maybe by 3.5, it would be clear if it should go into core, or not.

[Nick Savov]

Thanks Amy! It's nice to see that others in the community have been
experimenting with these WYSIWYG editors.

I found the following editor that's mobile friendly, open source, and
packed with features (looks quite mature actually) :
http://jejacks0n.github.com/mercury/

Looks like we have a lot of options, which is a good start.

Kind regards,
Nick

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/CxRQXV1g1twJ.

[piotr_cz]

So there are few options to choose from.


I propose to
- come up with evaluation criteria (licence, maintainability, mobile
friendly, possibility to integrate, extendability, ...)
- compare
- in case few editors are meeting criteria, make a vote either on this
group on Joomla front page.

[Seth Warburton]

My problem with Hallo is not that it isn't awesome, but that I think that it is not an editor for the masses.

Of course, for us us Semantic Samurai this is no problem. My clients at least want something that (cover your ears) looks and functions like Word. Familiar looking buttons to click and clever drop-downs.

For me, it has a couple of killer features that I think make Redactor stand out; 

• Autosave! (how many times this would have saved my ass is unthinkable)
• Copy and paste from Word. If any of you have a client that does not persist in doing this I take my hat of to you. Apparently, Redactor can allow them to do this just silently cleans things up in the background.

I also think the mobile view is very well thought out. Editing is never going to be 100% painless at 320px but this takes it as close as possible I feel.

[Gary Jay Brooks]

Has anyone thought about talking to Ryan from JCE?  

[Nick Savov]

Maybe I'm missing something, but what's so great about Redactor's mobile
view? It basically just gets rid of half the buttons, and in my opinion,
important ones such as the insert an image, file, and link.

From what I can tell, Mercury does it a lot better and preserves all the
functions:
http://jejacks0n.github.com/mercury/

Kind regards,
Nick

>
> My problem with Hallo is not that it isn't awesome, but that I think that
> it is not an editor for the masses.
>
> Of course, for us us Semantic Samurai this is no problem. My clients at
> least want something that (cover your ears) looks and functions like Word.
> Familiar looking buttons to click and clever drop-downs.
>
> For me, it has a couple of killer features that I think make Redactor
> stand
> out;
>
>

> - Autosave! (how many times this would have saved my ass is
> unthinkable)
> - Copy and paste from Word. If any of you have a client that does not

> persist in doing this I take my hat of to you. Apparently, Redactor can
> allow them to do this just silently cleans things up in the background.
>
> I also think the mobile view is very well thought out. Editing is never
> going to be 100% painless at 320px but this takes it as close as possible
> I
> feel.
>
>>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/iEpMhY9UleAJ.

[Amy Stephen]

Mercury was created for use with Rails and will take work rebuilding a lot of the backend functions in order to use with PHP. I am certain that functionality will appear, but it's not available today. Other than that Mercury is very cool.

Agree with Seth on the value of a Word converter. My only concern on Redactor is support. It's not just a license issue. By rolling back the changes, the license issue is resolved, but, I would not put it into core without a team in place that guarantees (whatever that means ;-) ) support it and continued development. That's a big part of picking software. If the Joomla project was going to take it on, then I'd say support is covered, but there aren't many JS experts contributing to core -- would be good to get those folks more involved, first.

I believe it's been mentioned that a working group for this question would be helpful - I agree with that. There is a very strong agreement in the broader community that we have yet to nail WYSIWYG editors -- and many developer teams are taking their turn at bat trying to offer something better. That, and the emergence of HTML5 make it worthwhile to see if Tiny, or something else, is a better solution for the future. A goal of getting a good solution in by 3.5 could be doable.

Since it has not yet been mentioned, make certain to compare the size of these solutions, too. Big difference in load time in some of the offerings. With Mobile, that probably matters most.

[Nick Savov]

Re: Mercury,
Haven't they already rebuilt it without Rails for us? Check out the
following documentation:
https://github.com/jejacks0n/mercury/wiki/Using-Mercury-without-Rails

Kind regards,
Nick

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/lmz5byEPpt8J.

[Amy Stephen]

Yes, that's a birds-eye view on how to get started. This video for integrating it into Rails is worth watching http://railscasts.com/episodes/296-mercury-editor as it shows the elements that would need to be replaced in a PHP environment.  Part of the challenge is Rails uses a RESTful approach and can therefore make certain assumptions about the integration. That would need some thought with Joomla.

When we start seeing Mercury Editor for WordPress it'll be a good sign. =) Maybe that's already available? I've looked but I don't see any active PHP implementations yet. I have found a few Drupal posts and one attempt at integration from a year ago that was closed due to inactivity. But, I have yet to find anyone using it with PHP.

Hopefully, someone will quickly prove me wrong. Would love that.

On Thursday, September 6, 2012 10:16:59 AM UTC-5, Nick Savov wrote:Re: Mercury,

[joss sanglier]

Hi Amy

I noticed what you were saying about Aloha. At the moment it certainly seems to be picking up a lot of interest so maybe it is now being better maintained.

I am not techy (as you well know!), however, I have been using it on Wordpress and am very impressed with the way that it has been integrated; using the WP image system for consistency and so forth. 

Perhaps it is worth revisiting it again? Just from the user point of view (trying all these out on a sample of 3 very non-techy clients) Aloha was the one they all got immediately. It is something about how it looks (with a nod towards MS Word) and that it dances straight to where you need it that they loved. They felt like someone was pointing and saying "type here"

I know the tech is vital, but the usability and friendliness is also important

All the best

Joss

[Amy Stephen]

Hey thanks for taking time to respond.

On Thu, Sep 6, 2012 at 2:53 PM, jejacks0n <jeja...@gmail.com> wrote:

Ok, so that's pretty much covered.. The potential issues I see are more about the core concepts behind Mercury.  Mercury is really about editing content on a page directly -- which differs from a lot of the other things (eg. CKEditor), which are intended to be embedded within an admin interface.  It's editing content within the context that it will actually appear within that Mercury tries to achieve.  And sometimes leads to some additional complication.

On Thursday, September 6, 2012 2:53:42 PM UTC-5, jejacks0n wrote:Ok, so that's pretty much covered.. The potential issues I see are more about the core concepts behind Mercury.  Mercury is really about editing content on a page directly -- which differs from a lot of the other things (eg. CKEditor), which are intended to be embedded within an admin interface.  It's editing content within the context that it will actually appear within that Mercury tries to achieve.  And sometimes leads to some additional complication.

Yup, that is exactly where the integration work begins that Rails is already prepared to handle.

Some of the integration elements that would have to be considered for Joomla would be:

1. Adding a display page in the Administrator that would render the component output. Currently, there is a list and an edit form. There needs to be a plain old rendered page for Mercury to act on.

2. Once the page is rendered, Joomla would essentially redirect to another URL to transfer control to Mercury. That means a bit of routing work.

3. Joomla uses plugins, user options and events to load the editor into a rendered form object -- the "embedding" you are speaking of.

In that process, the form object is built using XML that differs for each component and it is done in a specific way to communicate with JForm upon submission by the user. 

Since Mercury is not part of a rendered page -- but rather needs control of a rendered page, figuring out how to get JForm definitions to Mercury -- without a form -- is part of the puzzle.

4. When the editing session is complete, and a save button is pressed, the JS formats the data and send a JSON string back to the server for processing.

With a RESTful interface, the URL says it all. http://example.com/article/1 with a POST means something (update the article #1). In Joomla, URLs aren't like that -- so that's part of the puzzle..

5. While the controllers in Rails are set up to handle JSON input, Joomla is not. Joomla expects a form post complete with JForm field names so that backend logic would have to be adapted to handle this.

Editors like Tiny and Redactor are included by Joomla inside the page so all of the JForm field names and CSRF token are in place in the way that the Controllers are expecting.

It's not that it can't be done. It's that more integration work is required for Mercury than other options more like Tiny (or Redactor) where Joomla has already been configured to handle that type of interaction.

Most PHP applications deal with editors the same way.

Rails, due to it's RESTful approach and ability to consume JSON input can extend control easier to an external application.

It isn't a concern about Rails -- it's that most PHP apps aren't there yet.

++++

Now, since you are the author -- do you know of any PHP apps that are using this? Studying what they do would be helpful.

Appreciate it very much that you came in to help the Joomla community!

[Amy Stephen]

Joss - I think that whatever the group decides and makes happen is great. Certainly, user friendliness is very important.

In checking out their github repo, it does appear that they have a couple of recent releases in the past month and lots of dev activity. Hopefully, things are picking up since it definitely has potential.

In the end, it will come down to someone making something happen for Joomla. Likely, all of these new options will be available - it's a big community and there are a number of excellent options coming out.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/8N_iDaMXC0YJ.

[Chacapamac]

Thanks Jo —> I know the tech is vital, but the usability and friendliness is also important

I will even say that the friendliness Is EQUALLY important... We talk about CMS (Content Management System) here, if the interface or tools are to complicate and involve lot of knowledge you simply loose the “CMS” part of the CMS 

I take as example the new onboard multilingual setup for Joomla, really pro and completely necessary in any 2012 CMS, but really complicate to master for a non-tekkie administrator or content creator. 

The ultimate editor is something like the CMS “Concrete”— in context edition, I love it....  http://www.concrete5.org

Mercury Editor seem to do exactly that. Imagine this on Joomla, oh boy that will be great...

[Amy Stephen]

Concrete5 is using Tiny and some custom popups, menus, dialog boxes etc.

I agree that they have done a nice job on their Editor interfaces, as has WP.

Several of the examples shared above provide in-page editing in a way that would be more "native" to Joomla. I think these are pretty user friendly, too.

http://hallojs.org/demo/annotate/

http://createjs.org/demo/hallo/

http://aloha-editor.org/

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/AvHqXojBFbkJ.

[joss sanglier]

Beluga on the JUX forum (where this is also being discussed) made the point that Aloha has a plugin for Word and create.js has really useful stuff like auto-save.

I have tried to contact the Aloha team to see if they want to leap in here with any ideas and thoughts

I do have one worry with a lot of this, however, and that is the difference between front end editing and backend editing.

Backend, for very obvious reasons, is not in context, where as front end editing can be.

This leads to different approaches - not so much how an editor functions, but how it appears. Or at least, how it could do.

With a CCK like Seblod, the difference is not so pronounced since you may have several fields (especially text areas) and you want to encourage specific types of input - Only normal and bold in this one, this other you can do a bit more, this other one you can add image.

However, with stock J!3 at the moment, you will still only have one textarea for content. That tends to sit more comfortably with a static editor tool bar.

But, it would be important that the tool bar in that case is obviously related to which ever tool bar is in the front end so that we dont end up back with a plethora of solutions but just one.

There is an exception to this and that is if a template is introduced into the edit area. For instance if, in the backend, you were to introduce a template within the edit area (perhaps three floating DIVs) and you wanted to set different edit criteria for each - that would be fun!

Another thing that is important is that some users will want a fully fledged editor in the background - all singling and dancing like JCE with all its plugins, and that must not be discounted.

Wow - lots of variations, all trying to be served by one solution. Is this possible?

I suppose this comes down to trying to get these various solutions to have some sympathy with each other if they can. Maybe it needs a set of rules/standards to guide development and integration:

1. A common look and feel and nomenclature that reduces the learning curve when changing editors
2. A common, highly developed set of plugins for media (images, video, files, audio,...) that has a very close relationship with a new, powerful media manager and all share a common interface. These should possibly come in flavours of complexity depending on user group membership or use for that field (only upload and thumbnail available here, for editing available in different circumstances, only use existing library image over here...)
3. Multi instance abilities - not just user group based like JCE, but allowing for customised versions that are available to extension developers or different categories or even on a field by field basis
4. A common set of libraries/API, where that is possible, to reduce overheads and allow better future development (this may be wishful thinking, I admit it, allowing for the very different starting points)

I can't speak for the technology behind any of the suggestions so far, but looking at all of them I see that each has interface solutions to offer that suit particular circumstances. 

• Aloha is particularly well suited to editing in context because its small interface will follow you around - especially nice where you have a very complex page where only part of it is the article and it is broken up.
  
• Mercury is better suited to context editing where most of the page is an article and it helps to look at something as a whole - Wikis jump to mind here as an example
• Tiny/JCE comes to its own where an author want to be uninterrupted by what is going on with a site and just wants to work in the same way as they would with Word or Libre Office.

So, how can all these apparently disparate elements be drawn together into a single unified approach that can handle any type of content - not just articles - in a way that does not leave the user feeling that they are leaping from one system to another?

Joss

[joss sanglier]

Haymo - thanks for coming in. This is a really complicated area, not just technically, but because with a content management system (rather than what I call an AMS - Article Management System which most CMSs have been over the years) different users need to manipulate data and text in different ways allowing for the context and the nature of the data.

Any implementation of an editor will need to be able to be customised more or less on the fly to suit the need. This becomes more acute if you start adding CCKs and application development extensions to the mix where you may well have multiple text fields or areas for different reasons and wish to treat each one differently. But also applies to fixed third party extensions. Whichever solution Joomla offers out of the box should really fulfil the needs of the many, and with Joomla that tends to be a long and treacherous list!

So, since I am a lazy dolt (and famous for it) and have only experienced your editor in the Wordpress environment, what would be your thoughts about a management system for your editor so that it can be used in multiple ways and with multiple extensions but still keep a very low footprint, and obviously, only when needed? Sorry, that is a bit vague, but I think you know what I mean. Basically, it needs to be easily adaptable without heavy coding, or any at all, in an ideal world.

My feeling is that there is not a single solution that currently does everything that is needed, so the choice needs to be with a system that is adaptable and can be grown into the ideal solution.

But I may be wrong!

Joss

[joss sanglier]

I agree, I think Ryan ought to have input here - he has done more than most to make Joomla versatile while most of the data input is all in one field - especially with his various plugins.

Personally, I think he should design a new media manager for Joomla :)

I have sent him a note via his contact form pointing him in this direction.

Just call me the messenger boy! (Oh, okay, "old fart" then) 

Joss

[Amy Stephen]

If folks are serious about getting this going, but you don't have the skills to do so, you might consider kicking off a Chipin campaign http://www.chipin.com/overview

We should be doing that more in Joomla. I'm sure if the money were right, a talented dev would step forward and bring Aloha, or the editor of your dreams into J!.

[joss sanglier]

I think I am the only skilless one round here! :)

[Amy Stephen]

I doubt most people posting here have integrated an editor into Joomla. Just making a suggestion, though, please don't take offense. If folks really want it to happen, that might help spur some action. =)

Good discussion!

On Fri, Sep 7, 2012 at 6:41 PM, joss sanglier <jo...@sanglier.co.uk> wrote:

I think I am the only skilless one round here! :)

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/NWERjwb8P9IJ.

[Niels Braczek]

Am 10.09.2012 17:58, schrieb goldenmean:

> [Editors, whose UI were more closely related to the Adobe UI]

Have you ever seen an editor at least going into that direction?

Regards,
Niels

--
| http://barcamp-wk.de · 2. Barcamp Westküste Frühjahr 2013 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[joss sanglier]

It is a good point to make

From my point of view, for Joomla to be a TRUE Content Management System and not basically an Article Management System, then it has to be able to cope with the editing of a lot of different formats and deal with different types of data.

However, the trouble is, to do that at the moment would mean using lots of different editors with different looking interfaces, As a user moves from one data type to another they have to jump into different worlds.

The ideal would be to have one interface style, but be able to customise the tools associated with it on a data-type to data-type basis - even down to customise for individual fields once you add CCK type functionality.

The user should have no surprises. The more consistent data handling tools (of which editors are part) are across the system, while being versatile enough in their core to adapt to most uses, then the more powerful the system as a whole becomes; it becomes more useable, more adaptable and is less likely to force a user to work in a way which is unfamiliar.

Ha! It is all very well me being so philosophical - I don't actually know how to achieve the ideal!

Joss

[draftkraft]

Hi,

sounds interessting to me. I guess from a CMS vendors perspective you would want to address different users with different needs and skills. Say so, you may have designer, editors, admins, and the more. Now a person as user with designing skills would like to add styles to a paragraph in certain situations, where in other situations a company as user may explicitly forbid such modification in order to provide a consistent CI communication. I guess this somehow the most common case, because it makes sense to have a design (with spaces, paddings, margins, etc) that is consistent anyways. So the process of modifying the website design and the website content will be 2 different processes for a different audience or group of users.

That beeing said as of for Aloha Editor is a plain (still very nice :-)) editing tool and imho it can be extended to a designer tool of any degree (with some work, though...). It's quite straight froward to add additional attributes for every single paragraph. We do have dom attribute plugin, that allows you to modify every single attribute of a dom element and lets you freely add new attributes, right now.

It is a reasonable question to ask to what degree an editing tool should be a design tool? You could go even further and ask that design is tightly coupled to images so you might want to have all Photoshop features too, wouldn't you? That would be nice for me(!), but maybe hard for a quite large userbase...

Good to discuss this, because I think that features and simplicity to use sometimes are quite hard to combine.

Cheers

haymo

On Monday, September 10, 2012 5:58:17 PM UTC+2, goldenmean wrote:

I know that I am going to be in the minority here, but I also believe that's why it's so important for me to speak up on this issue. My clients do not expect the editor to function like Microsoft Word, in fact that's the last thing they want. My clients would love it if they had an editor whose UI were more closely related to the Adobe UI. All of the editors being evaluated here are pretty much centered around the idea of inline editing. What about an editor with block level editing capabilities with concepts like layers, margins, and padding?

Professional graphic designers are probably not a huge chunk of the Joomla user base in terms of sheer numbers, but they are an important groups as they have a lot of influence in recommending the platform and CMS for use in big corporate projects which in turn leads to visibility and ubiquity in enterprise environments. I just wanted to raise the specter of a user base whose need are not being met by the current roundup of potential editors.

P.S. Not that I have the answer, and not that I expect someone to do the work for me, but I'd love to see some chatter in this direction.

[joss sanglier]

HI Haymo

The JCE editor ( http://www.joomlacontenteditor.net/ ) does exactly what you are suggesting on permissions. It used the user-group system in Joomla so you can define a particular set of functions to each group. You can also do it on a component basic.

Although this offers a lot of versatility, it could actually go a little further.

For 3rd party plugin developers, being the ability to choose from different editor variations for a particular field, for instance, would be very useful. At the moment, you can install several editors into joomla and choose between them, but you cannot choose from different layouts of the same editor in the same way. Now that would need to be an additional Joomla function, perhaps, or there maybe a cleverer way of doing it using classes on a text area or whatever. That would probably allow for a lot more possibilities.

When it comes to levels of functionality, this gets a bit of a minefield - mostly because admins have a terrible habit of wanting every single possibility available even when the user is only likely to ever use Bold!

I think I would break it down like this:

• Basic Typography - the sort of thing that google helpfully put on the tool bars on this page. Obviously, being able to limit them to just one or two options if that is all that is needed.
  
• Insert Plugins - Images (using a file manager type plugin), Media (with embedding options), Files and so on. Personally, I think these plugins should be developed centrally as part of the Joomla core and then the editor be able to make use of them. At the moment editors tend to do their own thing basically because the Joomla media management system pre-dates Noah's Ark. Obviously, this does not stop people still designing their own (Ryan at JCE as created some very powerful plugins), but we really could do with some consistency. It could be that Joomla has core plugins for media management, but that these can be supplanted by third party versions using the same basic wrapping system. The editors then would pick up which ever plugin is specified.
• Tables and Layers - these scare the living death out of me in editors. Not so much because they exist but because they can confuse the daylights of some users.  Again, perhaps these could be treated as plugins to a certain extent. This then leaves the option for including these tools specified for very particular uses
• Advanced Styling - By the time we get to messing with CSS, we are ending up creating an online Dreamweaver rather than something for writing an article. To a certain extent although this has some uses, probably to the site where the admin is the only user, I personally think these tool go beyond the normal remit of an editor. Having said that, I will probably be yelled at!

Maybe the way to look at this is offering two editor routes.

• Route One - A fully configured, all singing and dancing, HTML page creating beast that offers everything out of the box. Perfect for very small sites where the users have some level of technical ability. This would tend to be welded to the top of text areas as we are used to currently. Robust, good and you can do anything with it. There are several good implementations all ready out there.
  
  
• Route Two - a very versatile editor solution which is aimed primarily at simple text manipulation and inserting stuff. It would be always assumed that each instance of this editor has a very minimal toolbar and is set up just for that particular field or content area. This would make use of the global media management systems (much like Aloha does on Wordpress). This would be perfect for the website where admins want the users to have a very low-tech experience - making like as easy and fast as possible. Particularly good where you have authors who do not want to mess around with lots of buttons but just get on with the job.

I must admit, the more I think through this, the more I realise how "back to basics" needs to be the thinking here. 

Joss

[Seth Warburton]

Sorry, I couldn't disagree more. There's only one place for styling and that's the stylesheet. 

To do this in an editor would mean inline-styling, the very antithesis of web standards!

[joss sanglier]

Web standards aside, a lot of editors do have styling plugins and of course, you can edit the source. But this just comes back to what should an editor be for?

Mostly, we all use editors that allow you to work with HTML to a very high level, and that seems to have become the norm. But I agree it is probably the wrong approach.  With a CMS you should be creating or adding "content" - data, if you will. You should not be creating "web pages" - that is the job of the mechanics of the CMS. (Yeah, okay, the line between the two is a bit blurry, but you get the philosophy)

We have a problem here and this is the continuing issue of a "CCK" of some description and whether there should be one in the core.

I use Seblod for some projects. That allows me to create loads of fields for a particular content type. For instance, with an article I might add a new field for a listing plugin, a separate field for the category listing, another for an article intro (that will be treated separately in the template), another for a text field in a sidebar on the article and so on and so forth.

If I really want to nail down my formatting, I actually don't need an editor at all. I can make sure the result of each field is styled in the specific template. But inevitably, I might need something if I do not want to create a specific content type for every article! But that might just be letting the user make text bold, or italic ... or add a link. And so on.

So, that is great on Seblod or the other CCK extensions out there. But on bog standard Joomla you only have two fields - the Title and the rest. That means there is a very high chance that someone somewhere along the line is going to need at least some basic typography functions in the editor to make the article look good.

Allowing the fact that anyone is welcome to override anything and add a bells and whistles HTML editor, what should Joomla be supplying at the core? How versatile should it be? Should it be adaptable so it can be modified by third party plugins? Should it have a styling policy to ensure consistency? What features should it have and where should it draw the line?

The thing that attracts me to things Like Aloha is that it is slick, but carefully limited - it is just about making text look a bit better. On top of that you can add plugins of course, but just having that basic starting point with an intuitive, modern interface seems like at least one possible solution.

Joss

[Victor Drover]

+100 seth

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/Rzf_Oo8QMVwJ.

[Nick Savov]

There are some cases where it's best to do inline styling and where
modifying a CSS file is not needed and is impractical. For example, if
you only want to modify one particular part in one particular article and
you don't need the same styling for another other part of your site,
inline styling is best.

That being said, usually a CSS stylesheet is best for most cases.

Kind regards,
Nick

[Victor Drover]

it is more work to update the style sheet, but that doesn't make it wrong. And for my end users, allowing them to add inline styles is the very last thing i would ever want (giant red blinking text, for example).

[Matt Thomas]

+100 as well Seth ;-)

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

--

[reynaldo celaya III]

about styling and inline styles

We now have a great base of css through Bootstrap that this next editor should take advantage of. Writing html w/bootstrap selectors will ensure consitency with minimal need to override. Inline styles can be replaced with classes (class='pull-left' as opposed to style='float:left;'). The editor should use the grid to ensure fluid/ or responsive sites dont break because of the content. It should provide configuration settings if someone wants to override the bootstrap classes.

As it is now it seems all templates will have to use bootstrap or override bootstrap css in order to avoid breaking components that use (JHtml::_('bootstrap.framework')). It makes sense to base the editor on it.

[Seth Warburton]

I can see what you mean Nick, but even in such limited cases it is better not to style inline. 

You can use the editor to attach a class or ID to an element sure, but that should only be a hook you can then target that with your css. 

Seth

[joss sanglier]

I have just caught myself adding an in-line style to a post on my own website and am now feeling terrible guilt pangs!

Whatever the ins and outs of best practice, this is really down to editorial control of a site and whether there should be that sort of enforced control on all sites.

For example, a site editor might decide on three different images to be used on a bullet list; a cross, a tick and a smiling face. What happens when one article needs a sad face? Does the editor phone up the web designer who has access to the template and can come up with a new style? Or does the editor use an inline style to achieve what is needed instantly?

Calling the web designer might be the right way of going about it, but if you are desperate to put up a post, you probably don't want to wait. After all, editors like JCE allow you to customise things like lists without having to know any html, or very little.

Even with a site for a one man band (like me), going to the hassle of getting into the template and creating a new style when you are halfway through typing some wonderful, creative blog entry, rather kills the moment.

So, there is a play-off here; good practice versus practicality.

Maybe there is a solution. Perhaps our wonderful editor/template/media system can have a way of creating a style on the fly while editing content that is then written to a custom style sheet correctly. This style sheet would need to be called outside of the template system since you still want the article to be displayed correctly even if the site template is changed. This style plugin would need to be permission sensitive, of course, so that only certain user groups have access, and the style sheet should also be editable independent of the editor/content situation. And the interface would need to be as simple and quick to use as possible.

Perhaps you could also set this on-the-fly style to be only available to that particular article, or only that category, or only one or more content types (allowing for a CCK here), or globally.

Thinking about it, that would not be a bad idea generally - a component that manages the style system where specific use styles can be created or changed and allocated to one particular scope.

If you want to enforce good practice, two things have to happen:

1. You must not allow people to edit the source of anything
   
2. You must supply tools that allow variation while keeping strict control on the output.

Joss

[Chad Windnagle]

I think the main thing with the image / media manager is that the current media manager is simply old and crusty, and really needs to be reworked from the ground up. I've spoken to a few devs about this. We need a media manager solution that works well for content, of course. But also one that is going to make sense for extension developers too. That means it has to be configurable (programmatically) devs to use. Because of this, I don't think we can just 'drop in' a simple image uploader, media management is much more than that. We need some database fields, and to handle more than just images. 

A bootstrapped image uploader for content might be a step in the right direction, but ultimately we need something a bit more robust.

Regards,
Chad Windnagle
Fight SOPA

On Wed, Sep 26, 2012 at 9:29 AM, mr9sky <mr9...@gmail.com> wrote:

Hi everyone! I am new here. I have watching the thread for some time now (thanks admin for approving me! :) )

I would like to point to some points I made in the JUX forums here and here regarding the same issue. redactorjs is great but its licence puts it beyond Joomla.

Personally, I believe J3.0 need (a) a modern WYSIWYG editor and (b) an integrated image uploader/manager which will create a more congruent experience for the user.
And since J3.0 is using Bootstrap, it makes sense for the editor to use it too.

Here are editors which I find to fit the bill:

Bootstrap WYIWYG editor:

• bootstrap-wysihtml5 - simple, clean editor.
  
• PageDown-bootstrap - with undo options, not updated regularly though...
  

Bootstrap Image uploader:

• jQuery-File-Upload - a jquery twitter bootstrap based image uploader.
• Pop-up Image Manager - A complete image manager using the image uploader mentioned above.
  

Please note I am in no way affiliated with the project above. I am just sharing interesting resources which I would be excited to see added to Joomla 3.0.
I hope I am not off-topic here...

What do you guys thinks? Can this be done?

Best Regards,
mr9sky

On Tuesday, 4 September 2012 23:56:04 UTC+8, Seth Warburton wrote:

Joomla needs this (or something just like it): http://redactorjs.com/

Beautiful, lightweight and works amazingly well on small (mobile) screens and touch devices. Neither of these are true for Joomla's current editor options.

As it needs only jQuery, which we are thankfully now loading, I can't see any issues with implementation.

Sure, it isn't GPL but their licensing would not seem to prohibit our use (with $99) and they certainly seem open to discussion ("..If you have specific installation needs not covered by this license, please contact us."). Maybe if we ask they would be happy for Joomla to use it under GPL. We can but ask!

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/7ce5MLmz_5YJ.

[Nick Savov]

Joomla 3.1 is 6 months away and I, personally, have three goals that I'm
trying to achieve for it:

1) An Improved media manager

2) Integrate:
a. Mercury Editor (http://jejacks0n.github.com/mercury/)
and
b. Aloha Editor (http://aloha-editor.org/) into the core

3) Integrate Julio's override plugin into the core:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=29031

I think #1 and #2 will round things out nicely for a full user-friendly
experience for users.

Today, someone mentioned to me that Joe LeBlanc was working on a project
for Media Manager. So, I have to look into that and get a hold of Joe so
that I can help him out and get this into 3.1, if he's still working on
it.

If anyone wants to work with me on any of the above tasks, please message
me :)

Thanks in advance!

Kind regards,
Nick

> I think the main thing with the image / media manager is that the current
> media manager is simply old and crusty, and really needs to be reworked
> from the ground up. I've spoken to a few devs about this. We need a media
> manager solution that works well for content, of course. But also one that
> is going to make sense for extension developers too. That means it has to
> be configurable (programmatically) devs to use. Because of this, I don't
> think we can just 'drop in' a simple image uploader, media management is
> much more than that. We need some database fields, and to handle more than
> just images.
>
> A bootstrapped image uploader for content might be a step in the right
> direction, but ultimately we need something a bit more robust.
>
> Regards,
> Chad Windnagle

> Fight SOPA <https://www.google.com/landing/takeaction/>

>
>
> On Wed, Sep 26, 2012 at 9:29 AM, mr9sky <mr9...@gmail.com> wrote:
>
>> Hi everyone! I am new here. I have watching the thread for some time now

>> *(thanks
>> admin for approving me! :) )*

>>
>> I would like to point to some points I made in the JUX forums

>> here<http://ux.joomla.org/forum/Roundtable-Discussion/890-Is-it-time-to-join-the-backend-to-the-frontend?limit=8&start=24>and
>> here<http://ux.joomla.org/forum/Joomla-30-Administrator-Template/1070-Please-a-new-editor-skin-and-a-working-image-uploadermanager?limit=8&start=8>regarding

>> the same issue. redactorjs is great but its licence puts it
>> beyond Joomla.
>>

>> Personally, I believe J3.0 need (a) *a modern WYSIWYG editor* and (b) an
>> *integrated
>> image uploader/manager* which will create a more congruent experience

>> for
>> the user.
>> And since J3.0 is using Bootstrap, it makes sense for the editor to use
>> it
>> too.
>>
>> Here are editors which I find to fit the bill:
>>

>> *Bootstrap WYIWYG editor:*
>>
>> -
>> bootstrap-wysihtml5<http://jhollingworth.github.com/bootstrap-wysihtml5/>-
>> simple, clean editor.
>> -
>> PageDown-bootstrap<http://dl.dropbox.com/u/2690345/pagedown-bootstrap-demo/demo/browser/demo.html>-

>> with undo options, not updated regularly though...
>>

>> *Bootstrap Image uploader:*
>>
>> - jQuery-File-Upload <http://blueimp.github.com/jQuery-File-Upload/>

>> -
>> a jquery twitter bootstrap based image uploader.

>> - Pop-up Image
>> Manager<http://codecanyon.net/item/popup-image-manager/2834343>- A

[Nick Savov]

Hi and welcome, mr9sky!

It's great to have you part of the discussion!

Kind regards,
Nick

[Youssef Kh]

i agree amazing :)

but you should see if its load faster ?

[mr9sky]

Hi Nick,

I agree with your goals too. 

Mercury is looking amazing by the way. The only issue is integrating it in the frontend and backend.
I suggest full-screen content editing in the backend by default. The content editing experience will be more full featured.

When you mention 'an improved media manager' I believe you are not referring to a media uploader right?
Yes. A  media manager with a media uploader plugin that editors and other extensions can use will be awesome.

All the best to you towards your goals for Joomla 3.1!

Best Regards,
mr9sky

[Nick Savov]

Thanks for the support!

Yes, I'm referring to Media Manager:
index.php?option=com_media

But one of the goals is also to make the process easier to add images,
etc, via content areas, similar to the way that JCE currently does it.

Kind regards,
Nick

>> <javascript:>>

>> joomla-...@googlegroups.com<javascript:>.

>>
>> >> To unsubscribe from this group, send email to

>> >> joomla-dev-cm...@googlegroups.com <javascript:>.

>> >> For more options, visit this group at
>> >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> >>
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Joomla! CMS Development" group.
>> > To post to this group, send an email to

>> joomla-...@googlegroups.com<javascript:>.

>>
>> > To unsubscribe from this group, send email to

>> > joomla-dev-cm...@googlegroups.com <javascript:>.

>> > For more options, visit this group at
>> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> >
>> >
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.

> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/YuIHLDPk-BEJ.

[mr9sky]

Hi Chad,

Yup,  you are right Chad. It sure is rusty and in need of some bootstrap and JUX loving care.

But why re-invent the wheel? I say we take one of the better current open source implementations and integrate with Joomla 3.1.
If you check out Sebastian Tschan ,the one who wrote the jQuery File Upload, he has a complete implentation of his uploader with an image gallery script.
Someone used his stuff to create to create an image manager.
For other file types, we can look at Mercury's implementation too.

Best Regards,
mr9sky