Add inline editing to Spark

Moving to Spark; closing down Phoenix. See http://buytaert.net/announcing-spark-authoring-improvements-for-drupal-7...

Oh, thanks. :) Good catch.

Also, I'm escalating priority of this issue, since it's the first thing the Spark team plans to work on.

http://drupal.org/project/aloha is worth considering here.

oh! this could be big!

Inline editing is the only thing i feel drupal is defeated when i am showing it to some vp that is interesting in the migration of his old cms, and he is analyzing Drupal against others such as sitecore.

Editable fields is not exactly 'inline editing' but it has done a lot of good work thinking through a potential approach -> http://drupal.org/project/editablefields

The Content editable attribute and aloha only gets you so far and allows only limited types of things to be inline edited. You need still need plain ol' form inputs to allow editing of the variety of fields we have in Drupal (of course with loads of cool js async stuff to make it seem inline!)

In so far as this project goes beyond inline editing to include drag-n-drop interfaces, the Panopoly distribution is the best I've seen so far in tje Drupalshere. Furthermore, while the panels Stylizer functionality that it comes with is very limited at the moment (in fact so much so that have yet to use it on a prod site), I think that the overall workflow and structure is promissing. I.e. Define default templates, let these be overridden for individual nodes, define locked regions or panes, provide previews for content being added, allow me to pick from existing styles or define new reusable ones, then provide the drag-n-drop, etc.

Beyond needing edit-in-place functionality, the panels suite falls short in terms of cohesiveness (so far). I mean, for example, that the Panelizer piece gets you control over the main content area, the mini-panels are for complexe layouts of sub-elements and the "panels everywhere" for taking control of the whole page. The drag-n-drop of one isn't related to the others so, for examlple, you couldn't drag from a mini-panel to a content pane in the main section, etc. But even if you could, you'd need some fancy and yet simple means to confirm/modify the contexts, arguments and such along the way.

Anyway, just a couple thoughts punched out on my mobile device.

Sorry, momentary lapse, wrong issue to comment on.

Hi folks. I finally caught wind of this Spark project. If the Aloha editor is being considered it's also worth considering the Hallo editor. It seems to be taking a more minimalistic approach than Aloha editor and it's a jQuery UI plugin.

http://bergie.github.com/hallo/

I've also been encouraging conversation on this topic in the WYSIWYG issue queue #1514272: Inline Editing and the WYSIWYG module

Also, if a guinea pig is needed, the http://farmhack.net site I've been volunteering hours on could use this functionality sooner rather than later.

There's also some good info at #1514272: Inline Editing and the WYSIWYG module.

Related: Field API Pane Editor — http://drupal.org/project/FAPE.

2 cents: Inline editing needs to have a responsive aspect to it. I.e., it must be possible to use a different editor based on the user agent (response to media query would be sufficient, since the platforms that matter can accommodate that): The editor that works on a desktop won't necessarily work well (or at all) on a phone. Degregation to plaintext might be fine, but the system would have to be able to do that (and if it could do that, it could degrade to a different editor).

Why this is important: In some demographic segments, mobile browsing already makes up over 2/3 of internet usage. This proportion is going nowhere but up, and the usage profile is doing nothing but get more sophisticated, and this is all happening very rapidly. A system that relies on interaction modalities that are optimized for keyboards or even large screens is going to get left behind.

@escoles: indeed, the ability to edit — and edit well (with good UX) — on mobile is very important.

I'm in the mobile first crowd these days. The good news is that editors like Aloha already work with mobile devices. The UX still needs work but it's getting there. Being able to select a different editor depending on the browser would no doubt be useful but I wouldn't necessarily put it on the feature list of minimum viable product, afterall, text boxes aren't that mobile friendly either.

I disagree, at least in part: Having the ability to present UI elements differently (i.e., change the UX) for mobile users is something that really should be supported in core. What you do with it as a developer or distribution-builder is up to you. (and text boxes are generally more phone-friendly than rich text boxes, in my experience.)

I don't think we should get caught up on "mobile-first" thinking, there is no reason that we can't make this mobile friendly in the long run - there are plenty of new techniques being released every week to solve a multitude of problems around mobile UX. This is an experiment in Spark, how to do it so it actually creates a great UX - not a poll? Neither should we assume, that you cant change it - its Drupal, you always can :)

I see http://xing.github.com/wysihtml5/ support html5

Hey, thanks for that! That indeed looks very appealing.

Very Interesting comments in Hacker News (including Wim, Bergie, etc) about #18 and in general wysiwyg editors (Aloha, Hallo, etc)
http://news.ycombinator.com/item?id=4002001

Filed #1595522: Add wysihtml5 to whitelist

With input filters what we want to do on the drupal aloha project is to remove from the editor any formatting options that would be removed by the filter for the field. So if there is a plaintext field, the user won't get the option to add h2, h3, links etc.

#22: I think that when you say "wysihtml5 does not do inline editing", you mean it doesn't seem to use contentEditable, but relies on a textarea instead? Well, it seems like we can actually alter it to make it work without textareas and with contentEditable: https://github.com/xing/wysihtml5/issues/34, https://github.com/xing/wysihtml5/issues/33. We've reached out to them for more information.

Nothing has been decided yet, we're talking to both the Aloha editor and wysihtml5 folks, to make a more informed choice.

Also: nothing of this is truly final. We're just trying to make the best possible WYSIWYG choice for now (and trust me, we do want it to be contentEditable, "true WYSIWYG", "truly inline"). It's not set in stone.

Input formats are indeed hard to deal with. Note that we want to show first how it can work, so we will not deal with e.g. a Markdown-based input format + "true WYSIWYG" right from the start (it's not certain we will ever want to offer WYSIWYG for this; it makes more sense to us right now to just show the node body form inline instead — we can still add this, of course). We will not even deal with things such as tokens for YouTube, Flickr and whatnot embeds from the start. We just want to be able to show a working version of "true WYSIWYG", where the user is limited to just HTML.

But you're right, even there we cannot allow "just about anything" to go from contentEditable=true to contentEditable=false; e.g. if one uses <script> but that is disallowed. I personally think your #2 easy solution is the best approach: as soon as the user saves the content (which was edited through the "true WYSIWYG"), start some animation, do an AJAX callback that saves it, but also renders it and checks whether input == filtered(input). It then displays the filtered input (with e.g. <script> tags removed), stops the animation, replaces the input with the filtered input and tells the user that "unsafe content" has been removed. The user will see that message, but will also see that nothing has changed in the output (in case of the <script>tag), so is going to be satisfied. In general, users shouldn't be seeing that message all too often.

Bojhan, "mobile-first" has a very specific meaning (loading the stylesheet specific to mobile screen dimensions before loading other stylesheets) that doesn't apply to my comments. I'm simply saying that if you want to produce an optimal editing experience for small touch screen devices like phones, you will need to be able to load different editors based on the results of either your media query, the user agent string, or a combination (and potentially other factors as well). It's not going to be sufficient to say you can figure out a way to do that because it's drupal, because mobile use will be utterly dominant within just a few years. Using the web on phones is not a fad, it's not even the future -- it's the present reality.

I'm still not sure what we want to achieve with "inline editing". I'm repeating again some things, but let me add my point of view.

As #22 states, input text filters are very difficult to implement in client-side, for real-time inline editing.

For example, Stackoverflow have had big headaches for couple of years to make match their Markdown Javascript parser (PageDown) with their Markdown parser in server-side (MarkdownSharp) . It's not an easy pie, and we are talking about only 1 input filter.

So if we want to maintain the flexibility of Drupal input filters, the only options we have is server-side processing:
* Semi Real-time: ajax calls to the server in the background and ask "please, process this text for me", and give me the result. (maybe do it every x secs, something like http://drupal.org/project/live )
* Not real-time: Wait that user refreshes the page. (User can have bad surprises that it doesn't look same before and after)

Other option is, at expenses of removing the flexibility of "input filters", creating a much more restricted and simple "HTML inline editing filter", so we have total control of how is processed in the server-side, and we can replicate it in the client with some 3rd party JavaScript library: No surprises for user. The only difference between client and server processing is about sanitizing HTML (script and other dangerous tags)

Is this last option what we are trying to achieve in Spark , true ?

An import aspect we haven't even touched yet is access checks. This issue comment in the Aloha module issue queue reminded me of that: #1486488-1: Roadmap. It's possible that each field has different permissions. If we want to be able to show the user which fields (s)he can edit immediately after switching to edit mode, then we need to do these calculations while the page is being loaded and embed that in the mark-up (e.g. using data- attributes). Yes, one can hack around that, so we'll need to verify this once more upon saving (though that is far less expensive, because it's a single permission check versus potentially hundreds).
There are of course ways to deal with the performance implications of that, but it's something we have to keep in mind.

#25: I agree. We need to think about mobile support right from the start, because depending on what you're dealing with, it's easy to paint yourself into a corner that makes mobile support impossible/unfeasible, to the point where you may have to throw away a lot or most of the work we've already done. "Just" to get mobile support.
Drupal 8 will need to support mobile devices very well.

#26: You're absolutely right. Sorry for not making that clear so far. Thanks for the excellent anecdote as well.
Spark will only do this "true WYSIWYG" thing for the simplest use case. Then why bother at all, I hear you think. Well: it's still awfully useful in maybe not many different use cases, but those use cases tend to have very many users. Say e.g. in the case of a person who has no Drupal, HTML or Markdown experience whatsoever: he installs Drupal and out-of-the-box he can start using this true WYSIWYG functionality. That's great, right? He doesn't need to install & configure more modules. He can do all the text layout things he needs to do.
We would also love to have image insertion (from media library or upload), resizing, alignment and captioning in there. Plus Youtube video insertion. In Wordpress, those things work through the WYSIWYG editor. They do it by having very simple, well-defined transformations. Something like [youtube:<video id>] (similar to Drupal's tokens) is saved to the server, but it is transformed on-the-fly (meaning that you never get to see that token) to the resulting HTML, so that you get to see exactly what it will look like.

For non-HTML input formats, we'll just fall back to the current forms, but we'll load just the relevant part of the form inline. I.e. for the node body, we'll allow you to edit that inline, through the body part of the full node form. Of course, even for "just HTML" input formats, there may be problematic filters, such as the Typogrify filter. That particular filter won't cause problems, but it can cause the eventual HTML to be ever so slightly different from the HTML you see in the server-side rendered end result (Typogrify will e.g. transform -- to —, & to something like <span class="amp">&</span>, etc. to allow for "more typographically correct" output).
So, in that light, yes, it is likely that we'll define a locked (i.e. which the end-user cannot modify) input format that will be used for the "true WYSIWYG" stuff. Maybe you could add "true WYSIWYG" to custom input formats — likely I'd say. But whenever the user would do that, strange behavior could be the result, depending on the filters he adds to the input format…

I'd recommend watching quicksketch's DrupalCon London talk on WYSIWYG: http://drupal.org/sandbox/quicksketch/1088256

As I said at #1564920-19: Explore existing UX-enhancing solutions in Drupal (plus more info on how Panopoly uses it):

http://drupal.org/project/caption_filter for captions. Likely near identical to the solution Wordpress uses because the project page explicitly references it (it was even used to simplify the porting of Wordpress sites to Drupal). Supports alignment. Integrates with lots of existing WYSIWYG things.

The Panopoly distribution includes this module, but doesn't really use it, nor shows it in the WYSIWYG they ship with (TinyMCE) — there's a patch for that though (#1432092-4: Add a caption button for TinyMCE), and it actually appears to break there due to filter ordering in their "WYSIWYG" input format.

(Extensively discussed in quicksketch's DrupalCon London talk: http://drupal.org/sandbox/quicksketch/1088256.)

#28 Thank you Wim for explaining , and yes I believe it's useful in many scenarios, even it's a "locked" input filter, but it's a instant client-side solution, that's what people expects. Specially in mobile .
I'll check quicksketch session

btw, I saw today a commit in a sandbox about wysihtml5 integration with WYSIWYG http://drupalcode.org/sandbox/webflo/1598422.git/commit/refs/heads/7.x-2...

Another module related to inline editing and part of Panopoly: http://drupal.org/project/wysiwyg_filter.

Also: do we want to support adding inline (Google) maps? It'd be nice to have, but it seems low priority to me. (Use case: SME using Drupal for their online presence, they want a map to show where they're located as opposed to a simple textual address.)

This project sounds like aims to tick a lot of this issues' boxes:
http://drupal.org/project/create

It uses Create library which depends on Hallo or Aloha

#32: hah, I've seen it, but I had no idea there was a Drupal module for it. Create.js includes a lot of things we don't really need — most notably VIE.

I just tried FAPE (see #12). Functionality-wise, it's what we want. Except that we want it to be in-place instead of in a pop-up/overlay. Looks like we should be able to reuse parts of its logic, or at least let it inspire us.

We did some work on the editable fields project (in D6) for a huge form for an online competition (so, not for editors, but for registered site-visitors).

One of the things we came across, and had to spend time on during the project, is that there are several tactics of the clickflow for saving a single field value. All have there relevant use-case.

In Angie's video she shows a very elaborate one: put page in edit mode, edit field by clicking the field, save field(s) by clicking a button, save page.

On facebook (for example), you click a link, then edit the field, and step off. There is a lot of scenarios in-between. In our project, saving on a per-field basis was the main reason we used inline editing, as we wanted to secure the data entered (on the server) as soon as possible, without reloading the whole form. In our case, we did use a per-field edit & save button to indicate to users that fields were actually editable.

It would be real great if the spark approach would include different, configurable, ways to make inline editing possible.

#35: Thanks, that's very valuable information/insight! I've forwarded your information to all people involved with Spark :)

Idea: Should we use onbeforeunload event to prevent user forgetting to save changes, (when closing tab or browser) gmail,stackoverflow,facebook, etc does it.

#35/#36: your comment was very well-received: everybody agreed. So, "worst case" scenario for you: we don't offer multiple modes in Spark, but we'll definitely make sure that contrib can override the behavior. So, in any case, this will be taken into account.
Keep the excellent feedback coming! :)

#37: onbeforeunload isn't reliable, unfortunately :(

One of my big questions is what is the user going to be able to edit when they do inline editing? Are they editing the direct field data? Or the rendered field data? My concern is for anything that runs through text format filters like Token filter or Media. If the user changes the output of the rendered, final text, then it's going to be impossible to retain the raw data when you edit the node via node/%node/edit since it would have been replaced. This is bad for example, for Media usage tracking that needs to attempt to stay accurate whenever a media item is used.

If the user sees the raw field data (e.g. sees the raw tokens and Media JSON tokens) that get converted to markup, are modules going to have to provide two different plugins for two possibly different WYSIWYG editors to be able to allow users to perform edits on both "front-end" and "back-end"?

If the user sees the raw field data (e.g. sees the raw tokens and Media JSON tokens) that get converted to markup, are modules going to have to provide two different plugins for two possibly different WYSIWYG editors to be able to allow users to perform edits on both "front-end" and "back-end"?

Not necessarily I don't think http://drupal.org/node/1580210#comment-6069410

Cleaning out the queue. This has been done, thanks to the Edit module.