Front end editing and the web site toolbar

Thursday 24 February 2011 10:22:19 am

I was very happy to see that front end editing was one of the focal points of eZ Publish 4.5. However, now that I've had the chance to do a quick test run of the first beta, my excitement has faded.

In my opinion, one of the biggest problems of the existing front end editing functionality in eZ Publish is it's modularity, or lack thereof. Implementing front end editing into a custom site is something that, in my opinion, should be as easy as activating an extension. That's currently not the case.

I'm not saying that there hasn't been made progress in this area, though. Taking the web site toolbar out of ezwebin and putting it into its own extension was a step in the right direction, and so is the new feature of 4.5 which places the toolbar floating on top of the site as apposed to having to be squeezed into it.

Still, the default edit and other management templates are sure to break your design without some custom CSS modifications, and even then, the custom design you've built might not be suited to fit those templates. As a result, our company rarely implements front end editing unless we have to, probably resulting in a worse usability reputation for eZ Publish.

To me, eZ Publish front end editing is missing two key features which are required in order to make it truely useful (and implementable):

Edit/mangement views in modular boxes

If all the edit and other management views of the front end were handled in modular boxes, or in some other type of separate overlay, there wouldn't be any need to customize the design to fit these templates. Also, the website toolbar could be shipped with a set of CSS files styling just these views, without conflicting with the rest of the site.

It seems to me that this way of handling front end editing is the solution emerging as the best practice.

Inline editing

Most templates (pages) are a combination of several content objects. Still, the toolbar assumes that you're only interested in editing the main node of the page, giving you only one edit button.

I would make the case that 90% of the time, you're only interested in editing 1 of the attributes in the class (that is, unless you're creating a new object).

As a result, it would be much better if you, when logged in with the proper priveliges, could hover over any element outputted by the attribute_view_gui (just a suggestion for how this could be fairly easily implemented) and have a set of edit/management icons appear which in turn would make that content editable in a modular box.

I've already sent these ideas to eZ when I heard that they were working on front end editing (without them taking much notice), so I guess this is just my cry for help (or to see if anyone agrees that this is a sorely needed improvement).

Sincerely,

Eirik Alfstad Johansen
http://www.netmaking.no/

Thursday 24 February 2011 2:11:31 pm

Please, don't take this as a promise or anything, but as far as I'm concerned, your cry for help isn't ignored. Without digging into implementation details, the idea of making anything displayed with {attribute_view_gui} is very sexy. Really. We couldn't deliver as much as we wanted to regarding front-end editing for various reasons, but the topic is far from being abandoned.

I hope this makes you feel at least a tiny bit better (digital hug) ;-)

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Thursday 24 February 2011 2:49:06 pm

Hello Eirik

Attribute level editing has surfaced quite a few times in the past. The content model implemented with eZ Publish makes it quite hard to achieve this (editing an attribute means editing the whole object).

See for example the discussion http://share.ez.no/forums/setup-design/is-it-possible-to-edit-only-1-attribute-of-a-contentobject a bit over 3 years ago

So its not new, but it requires some fundamental changes in the paradigms used by eZ Publish (which I proposed as part of Project V)

Paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Friday 25 February 2011 2:14:34 am

Hi all,

Re: inline attribute editing.

I've been working on extension to do this. It's kind of half-way through but I don't have the time to finish it at the moment (I don't work with eZ Publish in my day job)

I'd love peole to contribute/take it over/use the ideas:

https://github.com/stevoland/ez_sedit

The frontend is quite nice - the backend is a total hack + the inline attribute editing feature won't work.

Think it's compatible with 4.3/4.4.

Cheers

Friday 25 February 2011 4:35:34 am

I think i understand Paul, specially when you think about searching and things like that. i mean, is doable to edit an attribute and only one attribute, but from there, we have to think in how ez works in some aspects.

For example, versioning. should we create a new version for every attribute editing inline? for instance, article class. we have title, short-title, body, tags, image... ok. we want inline editing for all, but should we create a new version for one?

if so, how to proceed if two attrs are being edited at the same time? i mean, probably one of your editors takes only care about the body and other take care of the images. editor 1 wants to change body of the article. he hover the body, and start editing. 1 minute later, image editor wants to change the image. he hover the images and start the process...

actually ez publish warns you if the same object is being edited. should we do the same with inline attribute? should we tell the image editor "hey, wait until the content editor finish"?

Other thing to note is related to searching. Actually, many ez publish projects are leaving ezfind the fetch content operations, because you can make more flexible queries from there. but actually, for reindex the title of one of your articles you need to reindex the whole object. if i'm not wrong solr will permit attribute indexing, but do know if this is possible right now.

so, back to the example, if you edit title, short-title and all the others, we would need to republish thewhole object in order to be reindexed? If you don't do that, you will probably get search results having title or texting you typed previously and not the updated by this inline editing thing.

Even if you have delayingindexing enabled, you still need to republish the object in order to be indexed by the cron.. right?

So, yep, still doable and really cool to have it. just thinking about possible unwanted sideeffects :)

Friday 25 February 2011 7:26:11 am

well, i say Solr because i can't imagine a search module in ez without it :) but the thing is just the same for the standard ezsearchengine.

fortunately there are things that could help here. i mean, default version history limit is set to 10. that can be increased, but also it can increase the whole database size...

and my other worries it's about perfomance. Suppose you have lot of attribs in one case. suppose 30 maybe. for some of them you're probably using custom indexing capabilites... and even more, probably you can be using content -> publish -> after workflows.

my worry it's if wouldn't take too much time editing one attribute because of it...

while writing this i realized about workflows. would you execute that workflow for each attribute editing? and what about 'approving stuff'?

surely Paul can explain it much better, but i think things like this is what he was talking about :).

Sunday 27 February 2011 3:51:11 am

Whoa, quite a large discussion, that's great.

First, I think that the fact that we currently can't really edit one attribute only shouldn't be considered a problem. While it is true that under the hood, editing one attribute means editing the object, it is still possible to edit an attribute only, and not pass the others at all. So very pragmatically, yes, one attribute only can be edited.

I think we're getting very close from the proof-of-concept stage: yes, not everything has been addressed. Yes, there are many aspects to this (UI, permissions, ...). But we know:

• what we can apply this to: attribute_view_gui / content_view_gui
• what we need to target it at: content/edit, as if "Send for publishing" was clicked

Isn't that sufficient as of now ? This topic is so wide it would be a shame not to at least try ! I know for sure I'm interested in contributing, and that it would be a killer feature. My personal time is a bit limited between my three babies (my soon-to-be son, eZ Market, eZ Publish 4.5 beta), but hell it's cool !

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Sunday 27 February 2011 7:34:59 am

As I've said, it's not easy, just possible and fun :-)

About versioning, well, I don't think we actually need drafts when doing frontend editing like this. Or do we ? One goal could be that such an interface will let you edit one (or more ?) attributes in an inline fashion. Either we create the edit interface the best we can, and deal with creating the version & publishing it in one go on the server side handler, or we use AJAX to create a real-draft, and are back to a close-to-standard workflow. About workflows, yes, interruptions of the publishing workflow are tough to answer. We need to look at the possibilities, the constraints, and the actual needs. But let's say this would apply to direct editings.

Now, another solution that could work: whenever node_view_gui / content_view_gui / attribute_view_gui are used, we know which node/object/attribute is viewed, and can therefore know which node/object/attribute could be edited from here. But when using attribute_view_gui, several attributes of the same object could be displayed on the same page. What about adding _ if edit permissions are there _ markup data that will let us scan the page for editable objects, and when asked (through a variant of ezwt ?) to switch to edit mode, buttons would be added (or maybe a side bar ?) that would popup an edit overlay for the edited object. Wouldn't that be sexy ? It ain't as seamless as swapping view with edit, but the display size between view & edit can be totally different, and it wouldn't work at all sometimes...

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Sunday 27 February 2011 1:12:47 pm

That's the question :). If not the thing could be easier, but if so, it's possible without doing it at object level?

sure it would be sexy, but i would go even further. no need to click in anything. I think a mix between Eirik's idea and yours would it make even more sexy.

the markup will depend on permission, right, but i wasn't thinking in side bars nor ezwt. i'm more of the idea of this buttons can be show on hovering. and, well, as ez works now, if you have rigths to edit the object, you will have the rights to edit all the attributes of that object.

and yep, after an edit overlay different for each datatype could do the job.

first part could be like this, and, ok, if we choose not versioning can be doable setting the content for that specific contentobject attribute. if we need versioning thin is still doable, but i just worried about performance in terms of editing.

Cheers

Thursday 03 March 2011 10:46:22 am

@STEVO: Would you care to elaborate on how the extension should be set up, and how we can confirm that it works? I tried downloading it from github and putting it in extension/_sedit. I then enabled the extension globally, cleared the cache and tried logging into the frontend. However, all I can see is a blank button in the toolbar with the tooltip "Edit content inline".

BTW, this was done on a (fairly) fresh 4.4.0 installation with ezwebin.

Sincerely,

Eirik Alfstad Johansen
http://www.netmaking.no/