Hi Amy

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

Hey thanks for taking time to respond.

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/1with 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!

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.

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

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

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/

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

Thank you Joss for pointing us to this thread.

I have read the thread I found some concerns about Aloha Editor. I try to respond on them and invite you to ask more questions or concerns about Aloha Editor.

1. Aloha Editor actively mantained
We try to improve the editor and you may see the changelog here https://github.com/alohaeditor/Aloha-Editor/blob/dev/CHANGELOG.md. Please have also a look at the commit history to see who is contributing and on what has been working on. (check also branches, features are developed there)

2. Distribution and Community support
We think that the adoption of an editor depends on usage in large projects. Aloha Editor has a  plugin for Wordpress  (160k downloads) http://wordpress.org/extend/plugins/front-end-editor/, it is used in TYPO3 Phoenix core and since TYPO3 V4.5 as plugin and Drupal implements Aloha Editor for front-end and backend editing with drupal spark http://drupal.org/project/spark. Further some commercial companies implemented or implement Aloha Editor http://www.ektron.com/web-content-editing-is-fun-again/. Also the WYSIWHAT team decided to go with Aloha Editor. All these projects give valueable feedback from production instances and help making the editing core system more stable.

3. Difference to other editors
* Aloha Editor is designed from scratch as CMS inline Editor.
* We reimplemented contenteditable in JS (kind of a polyfill) to avoid the browser related problems (different formattings on commands or unforeseeable changes on browser updates or different handling of enter and the such). It is a reasonable effort to apply a simple bold action through a variety of tags such as tables, lists, non editable tags and more.
*We also implemented a table plugin, which works much like tables in office products.
* A huge effort has been put in the copy/paste plugin from MS Word (other to follow) as we see this is happening very often in production and results often in strange code. We respect HTML semantics and avoid broken syntax (to in further dev).
* A useful feature is the Aloha blocks plugin which are non editable areas in an editable (http://aloha-editor.org/builds/development/alohaeditor-0.22.1-SNAPSHO...)
* The repository API should make it easy to connect data items (links, images, media, ...) from different backend systems even and provide a single access (trough outcompletion or a browser) to all data stores. You may join flickr images with your backend images through the same interface.
* You can handle the content with your own methods to convert html data to a format your backend can handle. Eg. links may be converted to placeholders, which can be processed by the backend.

We are aware that our communication is not the best: website, updates, roadmap information, documentation. We try to improve these things and provide better information to all developers.

It would be great to see Aloha Editor also in Joomla and we definitely will help you if you want to implement Aloha Editor in Joomla!

Thanks and all best
haymo

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.

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

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

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

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

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!

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.

Am 10.09.2012 17:58, schrieb goldenmean:

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

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

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

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

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!

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

+100 seth

On Sep 11, 2012, at 10:57 AM, Seth Warburton <s...@internet-inspired.com> wrote:

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

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

On Sep 11, 2012, at 11:56 AM, "Nick Savov" <n...@iowawebcompany.com> wrote:

+100 as well Seth ;-)

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

On Tue, Sep 11, 2012 at 11:57 AM, Seth Warburton <s...@internet-inspired.com

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

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