Possible alternative to Canvas editing

[Darren Ferguson]

I've never really enjoyed working with Canvas - so I've toyed with an alternative:

See here for a very quick demo: http://www.screenr.com/THk8 

The solution is unobtrusive to markup (when no Umbraco user is logged in).

It also allows a developer to specify what is editable where - e.g. you can launch an editor for a news item if it is listed on the homepage - it solves one frustration of having to find "widgets" that have been picked from elsewhere in the content tree to edit them.

Thoughts?

I thought of releasing as a package - I think it would need a couple of core mods to make it "non hacked".

D

[hor...@gmail.com]

Looks really interesting :-)

[Jonas Eriksson]

Very interesting! Does it require an aspnetwebform? Would it be difficult to to add a preview feature to it?

[Darren Ferguson]

Doesn't require a any .net just javascript.

It should be easy enough to figure out how to get it to work in with preview mode.

[Jason Prothero]

Looks great!  

Am I correct in assuming that the popup window could host any DataType?  Or is it just Rich Text Editors?  

Would there be a toolbar at the top to allow for creating a new page or is it strictly for editing?

Thanks,

Jason

[Shannon Deminick]

I'm not going to pretend I watched the video, just want to give my blunt 2cents = we shouldn't have canvas editing or anything of the sort. The back office editing is quite sufficient and easily supported. Trying to support front end editing is very very complicated and difficult and I'm pretty sure nearly nobody uses it because it doesn't support much. The more we go down the route of canvas editing the harder things get, the more weird stuff we have to support and the more 3rd party stuff doesn't work.

Just my thoughts.

[Darren Ferguson]

Shannon - I think you should watch the video before contributing here TBH. The thread is titled "alternative to canvas editing" and what is demonstrated isn't Canvas.

It re-uses the existing editors - in a different context. The whole point of it is that you don't have to maintain two editor UIs - just re-use the existing in a different way.

[Shannon Deminick]

OK cool, I'll watch the vid in due time (sorry its very limited atm). I just think that front end editing is really difficult no matter what you do when you involve anything to do with macros or dynamic content which generally makes up a substantial part of websites and therefore limits front end editing to only a few things.

[Darren Ferguson]

The video is just food for thought on how it could be done really - I didn't enjoy canvas very much and a lot of customers ask for context editing still.

[mattbrailsford]

One suggestion could be, similar to how episerver works, if you are logged in as an editor "User" you get a right click context menu / or some other toolbar or such, where you can navigate the site on the front end like a normal visitor, but then right click or some other action and say "Edit this page". Similar to darrens video, you can then just present the entire of the right hand panel from the back office in a dialog or something. 

So, like I say, similar to darrens video, but works at the page level, rather than the property level.

Just an idea.

[Darren Ferguson]

Mat, the editor that opens in the modal is for the whole page - not the specific property.

Also - you can control (unobtrusively in your templates) which region of the page links to an editor, so for example if the homepage lists news items, clicking on the news items edits their individual node.

[mattbrailsford]

Ahh, cool. I think in that instance then, the UX may need a little work, as I would find it somewhat confusing the click on the text area and not be taken to it in the editor (hence why I recommended just a "edit this page" type link).

I do think it's a nice middle ground though, and like you say, can save on implementation.

Matt

[Scott Williams]

I would have it where when you hover over the section then you show a button "Edit {DocType}" this would re-enforce you are editing the page and not just the property and also help with editing lists of nodes

you could also possibly even then have other buttons for other actions, (edit, delete, create child etc)

Scott.

[Chad Rosenthal]

I'm of the group that has never used Canvas and in fact have deactivated it for all of my clients. The reason being that most of my templates don't have <form runat="server"> which breaks Canvas. 

I like the idea of extracting this out into a package and removing it from the core. My main reason for saying this is from my interactions with clients. Early on, they ask if there is inline editing. I say no, but then do the training. Once done, all the clients seem to think that the back-end interface is simple and intuitive. If this is the case, why complicate it?

From what is said above this is a javascript solution and doesn't use .net code. Some questions and concerns.

1. Would we have to include the javascript in all of our templates? (concerned about download speeds and downloading files that aren't necessary for the average user) or would there be a way to inject it if you are already logged in.

2. How would permissions work? How do you ensure the user has the ability to access the page that you are on?

Thanks,
C

and am concerned about Canvas and canvas alternatives.

[Shannon Deminick]

It would be nice to know how many clients actually ask for and actually use canvas style editing? I've never seen or heard of anyone using it or asking for it. Just saying. Developing this no matter which way you do it adds tremendous overhead and is difficult to make compatible with every install.

[Scott Williams]

I think this would make a wonderful community project/package but I don't think it want to actually live in the core, if there are extension points that are needed in the core to make it work smoother then they should be considered for inclusion.

Additionally I would not remove the current, all be it limited, canvas editing until a better community replacement is released.

As a package it would be in the domain of the developer installing the package to make sure all their templates are compatible rather then the core team fighting to make an all encompassing system that will just confuse people when its not working.

Scott.

[Chad Rosenthal]

Agree that it should be a package and if there needs to be an abstraction to allow it, then let's look at that.

I think that Canvas should be removed entirely.It doesn't work right all of the time and it's very easy for developers to break. My feeling is the basic install should work for both the experienced and the novice without needing instructions on how not to break it.

-C

[Darren Ferguson]

1. Would we have to include the javascript in all of our templates? (concerned about download speeds and downloading files that aren't necessary for the average user) or would there be a way to inject it if you are already logged in.

The JS for the prototype is only injected when a backoffice user is logged in.

 

2. How would permissions work? How do you ensure the user has the ability to access the page that you are on?

this was an hour long proof of concept - but trivial to only allow users to edit what they are allowed. 

[Darren Ferguson]

I am only interested in this topic as am often asked for it pre engagement and during training. It would be good to gauge the interest somehow.

I'm not with you on the tremendous overhead though - I disagree there. Have you watched the video yet :)

[Darren Ferguson]

The solution that I put together is developer led - so if you don't specifically allow editing in your templates then it is never exposed to the end user - you wouldn't need to disable it, it would be disabled by default.

If you aren't concerned with it - you'd never know it was there.

[Darren Ferguson]

I'd like to remove Canvas too - it is really hard to take features away from people though, so rather than put a topic up that advocates the removal of Canvas I'm trying to suggest a viable replacement.

One of the really complicated things with canvas is supporting editing of custom datatypes - The solution demoed makes that simple by just reusing editcontent.aspx inline.

[Chad Rosenthal]

Darren - Thanks for the responses. You basically addressed my concerns 100% about replacing Canvas with your alternative. 

So as it stands, could you set-up your alternative as a package (with a nicer name than Alternative to Canvas) so that others can gauge and test it? Then if it seems to meet our needs, we can then push the core team to incorporate it?

In the meantime, while I'd love to remove Canvas, it seems that it would be nicer to keep it in place until there really is an alternative. That way we can keep the bullet point that Umbraco can do inline editing.

-C

[Darren Ferguson]

Chad - please read the original post. the reason i floated the idea here is that some minor core mods are required to make this a package (my original intent).

[Chad Rosenthal]

Ahh. Missed that line. 

Are the core mods generic enough that if a different developer came up with their own solution that they would be able to use them?

-C

[Lee Kelleher]

Back to the original post...

> I thought of releasing as a package - I think it would need a couple of core mods to make it "non hacked".

Darren, is the code online somewhere? Would be good to review, see what the core mods are, etc.

Thanks,
- Lee

[Darren Ferguson]

@Lee - I could write something up.... i'll add it to the list :)

[Meixger]

I'm missing a visual connection between the [canvas] frontend page and the content tree!

Navigating in the content tree, i would like to SEE the actual frontent page.

IMHO this was implemented in a nice way by N2CMS!

Anyone interested in a short video? Unfortunately in the UI Improvement thread noone replied https://groups.google.com/d/msg/umbraco-dev/yK78TXvSVJI/v4q4CHrmth0J

On Sunday, July 8, 2012 11:48:21 AM UTC+2, Darren Ferguson wrote:

I've never really enjoyed working with Canvas - so I've toyed with an alternative:

See here for a very quick demo: http://www.screenr.com/THk8 

The solution is unobtrusive to markup (when no Umbraco user is logged in).

It also allows a developer to specify what is editable where - e.g. you can launch an editor for a news item if it is listed on the homepage - it solves one frustration of having to find "widgets" that have been picked from elsewhere in the content tree to edit them.

Thoughts?

[maa...@gmail.com]

On Wednesday, 11 July 2012 18:03:06 UTC+12, Shannon Deminick wrote:
>...we shouldn't have canvas editing or anything of the sort. The back office editing is quite sufficient and easily supported. Trying to support front end editing is very very complicated and difficult and I'm pretty sure nearly nobody uses it because it doesn't support much.
> .

OMG editing in back office for 99% of users is so far removed from what a real page looks like that we should be striving towards some sort of front end or front end like editing situation. Just because it currently doesn't work does not mean its a bad idea.

It seems the most common things a content editor (the user) does in umbraco in a site with and decent amount of content is add copy and images to a page. These seem to be what everyone is avoiding spending time on moving foward with. We are stuck in the dark ages of filling in forms.

This means we often and end up with generic, awful pages as the use of editors like tiny mce allow too much room for the average content editor to stuff up layout, even when the css for typographic layout has been well thought out and implemented.

Working with multiple column layouts is also less than optimum, often meaning multiple editors. yuk.

Bring on front end editing, bring on drag and drop, bring on selecting or re-ordering pre-formatted html blocks that appear to the user like they do in the actual page and then lets the user populate with content. Bring on decent image manipulation and ease of inserting into a layout.

All this we are doing in small ways but with customisation but we are not there yet.
The web is the future of mainstream publishing, let's make it better instead of being satisfied with the status quo

[Ove Andersen]

That looks exactly like what we need for our users. I think that replacing Canvas with this would make the site much more user friendly for editors.

[Niels Hartvig]

I think what we're seeing with Webblocks is very promising and strike a great balance between the strengths of frontend editing (easy editing of *visible* elements) with the strengths of back office editing (semantic properties, editing of meta data, editing of data that's less content heavy):

http://www.youtube.com/watch?v=xXAdrZY3V5M

The Mentor Digital folks are in the process of open sourcing it and we hope that we can work with them on integrating the ideas for the Belle project.

/n  

[Robert J. Foster]

/drool.

 

Needs some razor helper extensions J

 

Robert Foster

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umbraco-dev...@googlegroups.com.
To post to this group, send email to umbra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/hu4mWw8UnqkJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Meixger]

what about a better preview mode, where the frontend navigation would sync the content tree? http://www.youtube.com/watch?v=jsY_pl4MvgQ

i have sites with more than 10.000 pages and i find it quite difficult to locate a page in a deep content tree.

[Barry Fogarty]

@Neils, that is great news, I just visited this thread to post the same link!

For reference, further info about Web Blocks here: 

http://www.mentordigital.co.uk/updates/mentor-news/2012/november/mentor-web-blocks-presentation-at-umbraco-uk-festival/

http://www.mentordigital.co.uk/updates/dev-lab/2013/february/mentor-web-blocks-development-update-(4th-feb)/

[Pete Duncanson]

Word press has a really simple (and as a result quite clever) editor bar that appears at the top of your site when you navigate around if you are logged in. That as a simple "Edit this page" button that opens up the editor in another window using the page id. Not quite as simple as that when you have macros rendering lists of content etc. (you'll just go to the main page with the marco on it) but its certainly something that would be easy to implement and give value to users for quickly jumping to a page to edit it. Quick win?

[Craig Stevens]

As I've just lost a small contract to Weebly AND I'm constantly getting
hassles from other clients about why editing in Umbraco isn't as WYSIWYG
as they think it should be, I thought I'd bring up the Weebly editing
interface http://www.weebly.com/ (view vid) and Concrete5
http://www.concrete5.org/ (view vid). Both have very intuitive editing
canvases. Maybe not 100% compatible with Umbraco but as clients like
them, certainly food for thought.

Craig

[marcemarc]

This looks alot how we used to have Site Edit in Tridion configured, the hover over content highlighting, but clicking leads to the relevant component in the backend, 

For a large site, it's really handy to have that connection between the displayed page and how you edit it, (particularly in Tridion) but this doesn't need to be canvas or anything like inline editing. 

http://tridionumbracomigrationtrilogy.monosnow.co.uk/post/45442702133/inline-editing

For our migration from Tridion to Umbraco, I've just created the wordpress style 'Edit This' button in the top right that only displays when a user is logged in to umbraco, clicking the link will open up the tridion backend with the relevant node ready for editing, it's not as slick as the video above, but it's simple and  'works as expected'...

[Pete Duncanson]

+1 for the simple word press style button, easy to do in most cases and gives 90% of the desired result.

[brains....@gmail.com]

Any progress on this Darren?

[creat...@gmail.com]

I'm also interested to know whether there's any progress on this..