Inline editing, the Drupal / Spark way

[teppo]

Just came across this and found it quite interesting; Spark project (by Acquia) brings inline content editing for Drupal: http://buytaert.net/...iting-in-drupal. Seems way more streamlined than Mercury Editor and other similar solutions.

There was some discussion about similar concepts in the AdminBar topic and at IRC some time ago, so I'm sure that I'm not the only one interested in concepts like these. Would love to see something similar brought to ProcessWire at some point.. ;-)

[ryan]

Thanks for posting, this implementation looks pretty cool. I think Drupal lends itself particularly well to this sort of thing given that it's a markup generator where there are a lot of known factors both in structure and markup. What I usually think of as a disadvantage becomes an advantage with this sort of thing. It seems like a natural progression for Drupal as the admin side often is just an extension of the front-end already.

I would also like to see something similar in ProcessWire at some point. But as a fun module useful for specific situations, not as a recommended way to edit most content. Inline editing is eye candy rather than something that's actually positive for the online experience. It really sends the wrong message when it comes to content portability and accessibility. Editors need to be focused on the content, not "this viewport." It goes against the nature of markup and regresses one back to thinking on print terms. I can see one of my clients trying to put a line break in the headline to make it look the way they want it, and then ending up with what looks like an error on mobile and feeds. That's just the tip of the iceberg. It also means you are no longer editing an an environment designed for editing. A place ideal for viewing and one ideal for editing may be very different places. But I like the potential of having a front-end editing capability for those times when the developer determines that the front-end is a good place to edit some things. Spark will be a good project to keep an eye on.

[Soma]

For same reason Ryan mentions. I believe there's this need, as the web is a child of print, but those rules/habbits that were true to the print medium doesn't apply well in the new dynamic medium. The industry, and people in general need to first grow on it, and is only yet adapting which will take some more years or even decades. I don't say there's no solution for this problem in particular mentioned here and maybe wasn't really a problem as of now (devices are not only desktops anymore), so it's coming back at us for not yet considering/knowing.

[pideluxe]

To show off another project with inline-editing, you can have a look at the gpEasy CMS (www.gpeasy.com). It is a file-based CMS with true WYSIWYG based on the CKEditor. You also get a page manager, asset managment and drag'n'drop rearrangement of layout elements. You can assign different Templates to pages, the menus can be auto-generated. The administration is made available via sidebar similar to the admin bar from apeisa. It is NOT a CMS for complex websites, it is fast solution for getting simple websites done with very easy administration, even for the usual client. I used it once for this website: Beautynova.

I know, gpEasy is not comparable to ProcessWire in complexity, expandability or adaptability, but i think, some ideas or concepts can be used for PW to accomplish a better editor experience where it fits into PW.

[MarcC]

I would also like to see something similar in ProcessWire at some point. But as a fun module useful for specific situations, not as a recommended way to edit most content. Inline editing is eye candy rather than something that's actually positive for the online experience. It really sends the wrong message when it comes to content portability and accessibility. Editors need to be focused on the content, not "this viewport." It goes against the nature of markup and regresses one back to thinking on print terms. I can see one of my clients trying to put a line break in the headline to make it look the way they want it, and then ending up with what looks like an error on mobile and feeds. That's just the tip of the iceberg. It also means you are no longer editing an an environment designed for editing. A place ideal for viewing and one ideal for editing may be very different places. But I like the potential of having a front-end editing capability for those times when the developer determines that the front-end is a good place to edit some things. Spark will be a good project to keep an eye on.

Lovely, this is going in my book of web design quotes. Inline editing always struck me as a halfway solution. I used to offer it to my clients as a feature (in CMSes like Joomla and Concrete5), but after a while they all stopped using inline editing. It's a lot easier to talk about a single editing mode rather than two editing modes (inline and control panel), and the existence of two can be really, really confusing for users.

[JeffS]

Inline Editing. What fun that is. Adobe took their standalone inContext editor ( an inline) and added it to their Business Catalyst hosted offering. Developers can add attributes to the code (a div with a proprietary tag) that would be recognized by the inContext editor, to restrict the features of that editors use of it. That can certainly help to control the mayhem. But there is lots of that with inline. Plus I hate to see proprietary elements added to html but you usually do need someway to control the users editing scope.

For the most part, my experience with end users has been that they need a simple structured way to submit content types that followed repeatable patterns while having some latitude within the "textarea" to add media elements and such. A focused backend serves that purpose. So I don't pine for it as a feature in a CMS. What I do like is the ability to control the presentation of the data entry process. PW has those features with the exemption of required data entry on fields (or am I missing that?). +1 for the repeatable fields.

In summary aside from the "wow factor" I feel inline editing is overrated and when available, underutilized. Besides in a few years 60+% of users will be mobile or tablets anyway. Apps rule that space today and will in the future. That means more structure. We will have to create our interfaces to serve the users on the tools they will be using not the ones we do.

I am not planning on giving up my keyboard. In fact you can pry my keyboard from my cold dead hands. Or maybe my keyboard will be the surface of the desk while a kinetic or similar device is reading my finger movements in 3D. Ahh what a wonderful time to be an interface / app developer!