what could really help c5
Permalink 2 users found helpful
is a better content editor. need something like unify:http://unify.unitinteractive.com/... -- i know its built on tinymce.
its been quite a pain getting the editor to behave correctly. clients are constantly struggling. i can't expect them to learn html and dig through all the messy code it adds.
its been quite a pain getting the editor to behave correctly. clients are constantly struggling. i can't expect them to learn html and dig through all the messy code it adds.
umm... i have quite a few sites with c5. as a web designer i care a great deal about how my typography renders. i'm not saying "unify" is the solution but rather a great example of how a good editor could work. unify is obviously too small scale of a solution to be a cms.
So then your issue is that Font's don't render accurately in the TinyMCE in your opinion?
C
C
I like that BlueRoom site btw. great design.
thanks!
ya, my major issue is with tinymce producing some ugly code and causing formatting issues that my clients can't fix without knowing html. they should just be able to cut and paste into the editor and have it produce clean markup.
ideally, it would display like unify where it actually renders like it does on the page in the editor. but more importantly having the editor keep the code clean.
ya, my major issue is with tinymce producing some ugly code and causing formatting issues that my clients can't fix without knowing html. they should just be able to cut and paste into the editor and have it produce clean markup.
ideally, it would display like unify where it actually renders like it does on the page in the editor. but more importantly having the editor keep the code clean.
Tinymce can be bitch when inserting stuff. For example why the heck it has to wrap <p> tags around <img>.
would be nice to have editor that does clean code that is predictable.
This is something that could be solution:http://www.concrete5.org/marketplace/addons/textile/...
if that addon has ability to upload images etc. i think it could be saver for us and clients... even its not wysiwyg.
would be nice to have editor that does clean code that is predictable.
This is something that could be solution:http://www.concrete5.org/marketplace/addons/textile/...
if that addon has ability to upload images etc. i think it could be saver for us and clients... even its not wysiwyg.
I would not call this a major problem though. All that need to be done is set the css for that P tag to whatever you like.
We have used a good few CMS' and C5 is without doubt the best of them all in my opinion. My clients find it so easy to use.
We have used a good few CMS' and C5 is without doubt the best of them all in my opinion. My clients find it so easy to use.
are you telling us your clients never screw up the formatting? it happens almost daily for me. extra p tags, span madness, etc.
considering the content editor is a HUGE component of a cms, i think its major. and could really help this cms break through to a whole new level.
campaign monitor (an email system) uses a modified fckeditor which i think works great. highly recommend checking that out along with the unify editor.
considering the content editor is a HUGE component of a cms, i think its major. and could really help this cms break through to a whole new level.
campaign monitor (an email system) uses a modified fckeditor which i think works great. highly recommend checking that out along with the unify editor.
I like how quick it is to edit content on the unify demo. it doesn't seem too flexible, but it's super easy.
These extra tags tend to come from coping text from a word doc into the editor. Happens in Dreamweaver too.
Only thing I do is tell my clients to convert there word docs to a plain text file before a copy and paste and it gets rid of the extra tags word puts in.
And to be honest, we have never really had a problem with clients editing the sites if they follow what I say above.
Only thing I do is tell my clients to convert there word docs to a plain text file before a copy and paste and it gets rid of the extra tags word puts in.
And to be honest, we have never really had a problem with clients editing the sites if they follow what I say above.
I run into content issues with TinyMCE usability for our clients almost on a weekly basis. Coupled with the fact that I cannot use the mce source editor in safari (Causes big crash almost every time).
We are getting ready to replace all our content blocks with CKEditor... I really wish I could give this away to the community but unfortunately I don't own the rights to it :(
But I'm more than willing to help work on a (OSS) solution..
We are getting ready to replace all our content blocks with CKEditor... I really wish I could give this away to the community but unfortunately I don't own the rights to it :(
But I'm more than willing to help work on a (OSS) solution..
this kinda deals with a different problem than the shortcomings of tinymce, but it sort of applies here anyway.
One of my frustrations is that it seems like editing content takes too many clicks, especially if you just want to correct a spelling mistake or get some thoughts down on the page without distractions. so I made up a block that lets you edit content without needing to be in edit mode. just click on the text and it's swapped out with a textarea to make changes. Every time you save it takes a block version snapshot, outside of the normal versioning system.
can some of you test this out and give me some feedback?
http://demo.inneroptics.net/quick-edit/...
username: demo
password: demo123
any other suggestions to make it a nicer user experience?
I was thinking about giving an option of autoformating (just with nl2br and  ) instead of the default HTML mode, is it worth adding a rich text editor to this thing? (I don't really need it, but if there's some interest then maybe I'll add it)
One of my frustrations is that it seems like editing content takes too many clicks, especially if you just want to correct a spelling mistake or get some thoughts down on the page without distractions. so I made up a block that lets you edit content without needing to be in edit mode. just click on the text and it's swapped out with a textarea to make changes. Every time you save it takes a block version snapshot, outside of the normal versioning system.
can some of you test this out and give me some feedback?
http://demo.inneroptics.net/quick-edit/...
username: demo
password: demo123
any other suggestions to make it a nicer user experience?
I was thinking about giving an option of autoformating (just with nl2br and  ) instead of the default HTML mode, is it worth adding a rich text editor to this thing? (I don't really need it, but if there's some interest then maybe I'll add it)
I second comments made on this thread - the content editor is a concern.
It would be great if 'in-context' editing meant it worked DIRECTLY with the content on the page, rather than via a pop-up box.
It would be great if 'in-context' editing meant it worked DIRECTLY with the content on the page, rather than via a pop-up box.
in response to the orig poster, the code the editor adds is actually not too bad. what can be a problem is when people paste directly from Word into the edit area.
To get around this issue, enable Settings-->Rich Text Editor --> Advanced in the Dashboard. Two little buttons with a Word "W" icon and a "T" icon for Text/Notepad appear. Have your clients click either one of those buttons (whichever is appropriate) to copy/paste into a new field that will appear.
After that, there are usually a few spacing issue where paragraphs need to be closed up but aside from that things are pretty good. Try to encourage clients not to change text sizes manually to create titles, but use the H1,H2,H3 styles. I tell them this helps with the search engines. Bullets and underlining can be an issue as well. Bullets are often hardcoded asterisks and not li's and underlining conveys the sense that the item is clickable when it's not).
Here's a short video I made to help users do basic edits.
http://www.concrete5.org/community/forums/documentation_efforts/a_v...
I made it a while back so it's not updated for the latest C5 versions but it should give them the general idea.
EDIT: nice work tony. i think this might help people.
To get around this issue, enable Settings-->Rich Text Editor --> Advanced in the Dashboard. Two little buttons with a Word "W" icon and a "T" icon for Text/Notepad appear. Have your clients click either one of those buttons (whichever is appropriate) to copy/paste into a new field that will appear.
After that, there are usually a few spacing issue where paragraphs need to be closed up but aside from that things are pretty good. Try to encourage clients not to change text sizes manually to create titles, but use the H1,H2,H3 styles. I tell them this helps with the search engines. Bullets and underlining can be an issue as well. Bullets are often hardcoded asterisks and not li's and underlining conveys the sense that the item is clickable when it's not).
Here's a short video I made to help users do basic edits.
http://www.concrete5.org/community/forums/documentation_efforts/a_v...
I made it a while back so it's not updated for the latest C5 versions but it should give them the general idea.
EDIT: nice work tony. i think this might help people.
> It would be great if 'in-context' editing meant
> it worked DIRECTLY with the content on the page,
> rather than via a pop-up box.
Yes, absolutely! I wholeheartedly agree with FullFlavour. While Tony's Quick-Edit add-on is a step in the right direction, it's still far from the optimal user experience. I really like the way that Unify preserves the appearance/styling of the editable content but would prefer that the content remain in context instead of opening in a separate pop-up. The tool/formatting palette might need to appear in a draggable resizable pop-up, but the editable content should remain in place.
What would be cool is if you could simply start typing when a C5 page was in edit mode. You could drag images to position them instead of having to click, poke, and fiddle with text boxes, pop-up menus, tab panels, and other UI widgets. Resizing an image smaller would automatically generate a new down-sampled version of the image file (i.e. create a thumbnail) when the page is published (instead of simply scaling the full res version for display).
This might entail using an editable iframe for the entire C5 page, and certain operations might be constrained to block bounds (e.g. couldn't drag an image from one block to another, but it would be a quantum leap forward in the user experience.
With regard to Quick-Edit specifically, using an editable iframe with a WYSIWYG editor instead of a textarea would be a great improvement. But then again, if it couldn't be used with existing blocks - even if only content blocks - it might not be that useful to me.
-Steve
> it worked DIRECTLY with the content on the page,
> rather than via a pop-up box.
Yes, absolutely! I wholeheartedly agree with FullFlavour. While Tony's Quick-Edit add-on is a step in the right direction, it's still far from the optimal user experience. I really like the way that Unify preserves the appearance/styling of the editable content but would prefer that the content remain in context instead of opening in a separate pop-up. The tool/formatting palette might need to appear in a draggable resizable pop-up, but the editable content should remain in place.
What would be cool is if you could simply start typing when a C5 page was in edit mode. You could drag images to position them instead of having to click, poke, and fiddle with text boxes, pop-up menus, tab panels, and other UI widgets. Resizing an image smaller would automatically generate a new down-sampled version of the image file (i.e. create a thumbnail) when the page is published (instead of simply scaling the full res version for display).
This might entail using an editable iframe for the entire C5 page, and certain operations might be constrained to block bounds (e.g. couldn't drag an image from one block to another, but it would be a quantum leap forward in the user experience.
With regard to Quick-Edit specifically, using an editable iframe with a WYSIWYG editor instead of a textarea would be a great improvement. But then again, if it couldn't be used with existing blocks - even if only content blocks - it might not be that useful to me.
-Steve
I'll just be honest...all this is kind of goofy to me. C5 already offers an editing experience that is a million times better than most CMS's...it's half the reason I use C5. What you are talking about is major modification to the way C5 functions. I'm totally fine with Click Block -> Edit -> Make Changes -> Update. It's not that hard.
The auto-resize image thing sounds kind of nice though. :)
The auto-resize image thing sounds kind of nice though. :)
> C5 already offers an editing experience that is
> a million times better than most CMS's
Perhaps, but it's not as good as it could be IMO. Just because something's good does not mean it can't be improved. And yes, I realize that what's considered an "improvement" by some might not be perceived as such by others.
> What you are talking about is major modification
> to the way C5 functions.
So what. I think it would be a change for the better - especially given that C5 itself boasts in-context WYSIWYG editing which, strictly speaking, is a bit misleading. The "editing" does not in fact take place in the context of the web page.
> I'm totally fine with Click Block -> Edit ->
> Make Changes -> Update.
That's cool. The only problem is that you're not the one maintaining my client's sites. ;-)
> It's not that hard.
That doesn't mean many aspects of it couldn't be easier and friendlier. There's a lot of block-specific detail in your "Make Changes" step that I think could be improved. I hope C5 doesn't rest on its laurels in that regard. There are better editing experiences out there.
-Steve
> a million times better than most CMS's
Perhaps, but it's not as good as it could be IMO. Just because something's good does not mean it can't be improved. And yes, I realize that what's considered an "improvement" by some might not be perceived as such by others.
> What you are talking about is major modification
> to the way C5 functions.
So what. I think it would be a change for the better - especially given that C5 itself boasts in-context WYSIWYG editing which, strictly speaking, is a bit misleading. The "editing" does not in fact take place in the context of the web page.
> I'm totally fine with Click Block -> Edit ->
> Make Changes -> Update.
That's cool. The only problem is that you're not the one maintaining my client's sites. ;-)
> It's not that hard.
That doesn't mean many aspects of it couldn't be easier and friendlier. There's a lot of block-specific detail in your "Make Changes" step that I think could be improved. I hope C5 doesn't rest on its laurels in that regard. There are better editing experiences out there.
-Steve
I agree with most of the comments here. C5 is a great system, BUT. Some of the issues with the editor are valid. I have experienced inputing content, only to have it look different after posting. Mainly the size is different.
I'm not an expert in any way, other then basing my view on how intuitive the editor process presents. I've recently evaluated Drupal, Wordpress, Xoops, Joomla, Concrete5, and CMSimple. The editor options and menu management were the best in CMSimple, as compared to the rest.
Concrete5 won out overall, because the block dropin, themes, and layout selection was by far the easiest. Also, CMSimple has four competing development groups releasing various different versions, which is a turn-off. So, back to Concrete5. Though each of the various editors has their quirks, giving the content user a choice is the way to go. I hope C5 moves in that direction.
I'm not an expert in any way, other then basing my view on how intuitive the editor process presents. I've recently evaluated Drupal, Wordpress, Xoops, Joomla, Concrete5, and CMSimple. The editor options and menu management were the best in CMSimple, as compared to the rest.
Concrete5 won out overall, because the block dropin, themes, and layout selection was by far the easiest. Also, CMSimple has four competing development groups releasing various different versions, which is a turn-off. So, back to Concrete5. Though each of the various editors has their quirks, giving the content user a choice is the way to go. I hope C5 moves in that direction.
I agree with most of the comments here. C5 is a great system, BUT. Some of the issues with the editor are valid. I have experienced inputing content, only to have it look different after posting. Mainly the size is different.
I'm not an expert in any way, other then basing my view on how intuitive the editor process presents. I've recently evaluated Drupal, Wordpress, Xoops, Joomla, Concrete5, and CMSimple. The editor options and menu management were the best in CMSimple, as compared to the rest.
Concrete5 won out overall, because the block dropin, themes, and layout selection was by far the easiest. Also, CMSimple has four competing development groups releasing various different versions, which is a turn-off. So, back to Concrete5. Though each of the various editors has their quirks, giving the content user a choice is the way to go. I hope C5 moves in that direction.
I'm not an expert in any way, other then basing my view on how intuitive the editor process presents. I've recently evaluated Drupal, Wordpress, Xoops, Joomla, Concrete5, and CMSimple. The editor options and menu management were the best in CMSimple, as compared to the rest.
Concrete5 won out overall, because the block dropin, themes, and layout selection was by far the easiest. Also, CMSimple has four competing development groups releasing various different versions, which is a turn-off. So, back to Concrete5. Though each of the various editors has their quirks, giving the content user a choice is the way to go. I hope C5 moves in that direction.
I like this concept a lot.
I think it might be important, however, to integrate it into the main versioning system. Imagine working on a page like this with all of the different updates on each little section and then deciding you wanted the original - you would have to go back and revert each block...
Otherwise I think it's a great quick edit tool.
I think it might be important, however, to integrate it into the main versioning system. Imagine working on a page like this with all of the different updates on each little section and then deciding you wanted the original - you would have to go back and revert each block...
Otherwise I think it's a great quick edit tool.
hmm, well, it is still integrated with the main version system, in that if you role back to an earlier version of the page, then you'll get the earlier version of that block too with the eariler content. the thinking behind also having the block level versioning was that since it's so easy to create change the content, it should be super-simple to role back, without having to also rollback every other block on the page. maybe this needs some more thought though?
it's not gonna save the changes (in the main version system) until you make a change to another block though, right? That's the only place where I see it to be an issue.
it won't make an entirely new page version with a new bID for that content block until you enter edit mode, make some changes, and exit mode.
The more I think about it, I think the versioning thing might be an issue BECAUSE it doesn't have a rich text editor.
The way it's currently set up, you (or a client) would need a LOT more blocks on a page to accomplish breaking up subsections on a page. If one wanted to have different areas with an <H1> title and then a <p> for the content below it, that would require two blocks.
For areas that might not be as important to change AS often, and a standard content block is used, a client might not understand why some blocks are REALLY easy to edit and others take more steps.
At the same rate, with the different types of content editor blocks that could be used on the same page and multiple edits being made - it might be hard to explain why some of the edits saved and others didn't should things get way out of hand.
I think if the "in page" content editing that you created could be applied to the standard content block - it might be a home run.
Am I over thinking this?
The way it's currently set up, you (or a client) would need a LOT more blocks on a page to accomplish breaking up subsections on a page. If one wanted to have different areas with an <H1> title and then a <p> for the content below it, that would require two blocks.
For areas that might not be as important to change AS often, and a standard content block is used, a client might not understand why some blocks are REALLY easy to edit and others take more steps.
At the same rate, with the different types of content editor blocks that could be used on the same page and multiple edits being made - it might be hard to explain why some of the edits saved and others didn't should things get way out of hand.
I think if the "in page" content editing that you created could be applied to the standard content block - it might be a home run.
Am I over thinking this?
I'm not sure I totally follow your line of thought, but I like the idea of giving an option to use the full-text editor in there.
> I think if the "in page" content editing that you
> created could be applied to the standard content
> block - it might be a home run.
I agree. I hinted at that with my last post, but you stated it much more succinctly.
-Steve
> created could be applied to the standard content
> block - it might be a home run.
I agree. I hinted at that with my last post, but you stated it much more succinctly.
-Steve
This block of Tony's is perfect for me. I have my custom styles and fonts set in css but they can't help but click on those buttons to make it bold, italic, red, and everything an h1. I only want them to be able to change the text; zero formatting options, except maybe list items.
Tony, I just found this very old post of yours and was surprised [while reading other posts] that there is actually someone else thinking like me.
It is very simple and logical - C5 way of editing content. It is all a client can wish for in 99% of the cases. Why no one even bothered to leave a comment there?
What have you done with this? Is there a way to have it, from marketplace or you directly? Looks like an abandoned idea... Please take a moment to respond, I'd much appreciate it.
Once again, I wonder why core team didn't offer something like this as a basic way of entering content? I know you were one of them...
It is very simple and logical - C5 way of editing content. It is all a client can wish for in 99% of the cases. Why no one even bothered to leave a comment there?
What have you done with this? Is there a way to have it, from marketplace or you directly? Looks like an abandoned idea... Please take a moment to respond, I'd much appreciate it.
Once again, I wonder why core team didn't offer something like this as a basic way of entering content? I know you were one of them...
http://www.concrete5.org/marketplace/addons/lerteco-simple-content/
Thanks 12345j, I've checked the rest of the posts in the meantime and it seams like the app flow/usability is the issue, not the inline editing feature as such, which is true.
Frantz has a point, it might be tricky to set it in a non-confusing way, though I see it as reasonably easy to solve. Even though it looks like a trivial feature, it has a huge impact on overall impression, so I strongly believe it has its place in C5 core.
An add-on should just extend such core functionality, it shouldn't be the only way to have it. What Tony started makes sense and is a good example of such core functionality: simple and straight forward. I wouldn't go much further. The apple way, as someone said. I'm quite aware that having it easy isn't usually easy at all. At least not easy to think of the right way to implement it.
My general impression is that the core team is in a need of design/usability resources as they are busy, and should be busy dealing with number of other complex tasks. It is not reasonable to expect them to deal with the code and usability issues equally well. However, I haven't seen any request for assistance in this respect. I'm sure many of us would gladly help.
This also stands for tighter standardisation of approved add-ons as well. Do I need to mention Apple again...? Even though some developers are nagging about some aspects of their approach, the outcome is incomparable ease of use, stability and predictability.
For example, inline editing add-on presently offered in marketplace, the one you have mentioned is quite visually confusing. As Frantz said - it is far from obvious and/or what users got used to. Not to mention total inconsistency with the rest of the C5 admin interface.
Ease of use of Concrete5 is its strong selling point. I wouldn't like to see it gradually deteriorating.
Frantz has a point, it might be tricky to set it in a non-confusing way, though I see it as reasonably easy to solve. Even though it looks like a trivial feature, it has a huge impact on overall impression, so I strongly believe it has its place in C5 core.
An add-on should just extend such core functionality, it shouldn't be the only way to have it. What Tony started makes sense and is a good example of such core functionality: simple and straight forward. I wouldn't go much further. The apple way, as someone said. I'm quite aware that having it easy isn't usually easy at all. At least not easy to think of the right way to implement it.
My general impression is that the core team is in a need of design/usability resources as they are busy, and should be busy dealing with number of other complex tasks. It is not reasonable to expect them to deal with the code and usability issues equally well. However, I haven't seen any request for assistance in this respect. I'm sure many of us would gladly help.
This also stands for tighter standardisation of approved add-ons as well. Do I need to mention Apple again...? Even though some developers are nagging about some aspects of their approach, the outcome is incomparable ease of use, stability and predictability.
For example, inline editing add-on presently offered in marketplace, the one you have mentioned is quite visually confusing. As Frantz said - it is far from obvious and/or what users got used to. Not to mention total inconsistency with the rest of the C5 admin interface.
Ease of use of Concrete5 is its strong selling point. I wouldn't like to see it gradually deteriorating.
I sincerely hope concrete5 never behaves like Apple in their treatment of the developers or users.
Sorry mate, that isn't the subject here, I think I was quite clear inc. note re: developers.
I did attempt to jump in and try to start cleaning the tinyMCE interface, adding in close buttons and the bootstrap style into some of the plugins(emotes, chars). But that was back on the 5.5.0 beta release and I would assume it needs more work now.
I do like tinymce we have used it for a long time, albeit a slimmed down version with basic functions like, bold/italic/underline/paragraph aligns/ bullets / header-paragraph style
But I would like to see an improved integration or better looking editor. I do like JShannon's editor too its great for quick edits and would like to see the core team (at some point tidy up the current method).
I do like tinymce we have used it for a long time, albeit a slimmed down version with basic functions like, bold/italic/underline/paragraph aligns/ bullets / header-paragraph style
But I would like to see an improved integration or better looking editor. I do like JShannon's editor too its great for quick edits and would like to see the core team (at some point tidy up the current method).
Sure, TinyMCE should stick around as medium to advanced users do feel comfortable with it. However, even those users, not to mention clients, don't really need most of it, most of the time. And when they mess something up, or it acts unpredictably, they tend to attach their frustration to CMS instead of themselves. And they are half-right: It should be simple and reasonably error resistant. And more accessible.
Hi... I thought alot about the interface and consistency when I created that add-on.
There are currently three ways of adding content to the c5 front-end. I'm a bit rusty on c5 right now so can't provide examples offhand.
1. Through the dashboard. This is the "joomla" (and most other CMS'). There are, indeed, add-ons (probably some core add-ons, too) that use this interface.
2. Through a 'edit page -> right click on block -> edit' dialog box. ie, the common c5 interface. This is, by far, the most common.
3. Editing directly on the page, by going into a "per-block" edit mode. My addon (simple content) is the only add-on that I know of that does this.
Personally, I think all three have a place. At least for now. My #3 is admittedly inconsistent with #2 (though add-ons using #1 are also inconsistent with #2). However, I think that for someone who's a "c5 virgin", my #3 interface actually makes much more sense. Also, there are benefits to editing in-line (see the demo on my site where you literally edit around a floated block in real-time).
It's been a while since I read this entire thread (and I'm not about to do it again), but I think Tony's and my solution are essentially the same. If you're ok with his mockup, then mine should be ok, too.
Yes, it'd be great if every add-on had a consistent interface (but thisn't isn't true for all iphone apps, let alone apple's own apps), but I don't think that should prevent developers from creating something that works best for their app, let alone pushing the envelope forward. Personally, I'd like to see all of c5 add-ons use an interface like my simple content editor. Imagine building a form in-line!
James
There are currently three ways of adding content to the c5 front-end. I'm a bit rusty on c5 right now so can't provide examples offhand.
1. Through the dashboard. This is the "joomla" (and most other CMS'). There are, indeed, add-ons (probably some core add-ons, too) that use this interface.
2. Through a 'edit page -> right click on block -> edit' dialog box. ie, the common c5 interface. This is, by far, the most common.
3. Editing directly on the page, by going into a "per-block" edit mode. My addon (simple content) is the only add-on that I know of that does this.
Personally, I think all three have a place. At least for now. My #3 is admittedly inconsistent with #2 (though add-ons using #1 are also inconsistent with #2). However, I think that for someone who's a "c5 virgin", my #3 interface actually makes much more sense. Also, there are benefits to editing in-line (see the demo on my site where you literally edit around a floated block in real-time).
It's been a while since I read this entire thread (and I'm not about to do it again), but I think Tony's and my solution are essentially the same. If you're ok with his mockup, then mine should be ok, too.
Yes, it'd be great if every add-on had a consistent interface (but thisn't isn't true for all iphone apps, let alone apple's own apps), but I don't think that should prevent developers from creating something that works best for their app, let alone pushing the envelope forward. Personally, I'd like to see all of c5 add-ons use an interface like my simple content editor. Imagine building a form in-line!
James
All true. Oh, I probably should have mentioned that this is otherwise a great add-on. I took it goes without saying.
Design and usability is pretty much my field so this is an angle I'm taking and a point at which I make a difference between Tony and what you've done. I know it is basically the same but even though your solution looks and feels complete, Tony got it right: it stays out of your way and wastes non of your time getting used to it. It just blends. Only if polished.
As a designer, my urge is to make thing beautiful and push the envelope, but as a professional designer I know that brilliance comes with an extra carriage, in this order:
1. Serve the purpose
2. Communicate well with a consumer [inc. learning curve]
3. Fit in the environment
4. Look & Feel
5. Peace and harmony between 1-4.
So, your response proves my point, developers do need our help and it is not just about shiny icons. There's much more to it. Design brings your code to its real value if not adding more to it.
Note: Bringing apple as an example was obviously a mistake since there are emotions involved and lack of understanding of design requirements and terminology.
In a word, Design is good only if serves the purpose well, otherwise it is simply a standalone piece of art or not even that.
Design and usability is pretty much my field so this is an angle I'm taking and a point at which I make a difference between Tony and what you've done. I know it is basically the same but even though your solution looks and feels complete, Tony got it right: it stays out of your way and wastes non of your time getting used to it. It just blends. Only if polished.
As a designer, my urge is to make thing beautiful and push the envelope, but as a professional designer I know that brilliance comes with an extra carriage, in this order:
1. Serve the purpose
2. Communicate well with a consumer [inc. learning curve]
3. Fit in the environment
4. Look & Feel
5. Peace and harmony between 1-4.
So, your response proves my point, developers do need our help and it is not just about shiny icons. There's much more to it. Design brings your code to its real value if not adding more to it.
Note: Bringing apple as an example was obviously a mistake since there are emotions involved and lack of understanding of design requirements and terminology.
In a word, Design is good only if serves the purpose well, otherwise it is simply a standalone piece of art or not even that.
I am prepared to give the tinymce reskin another go. There is no reason why we could not take it and create a custom c5 theme.
We could create another thread get some community input and try to create a slimmed down basic version that fits the bill.
Maybe better integration of the editor bar? (the Add Image, Add File Add Link).
I'm no tinymce expert and struggled with the last lot of changes but more then willing to have another go. If anyone else would like to help out?
We could create another thread get some community input and try to create a slimmed down basic version that fits the bill.
Maybe better integration of the editor bar? (the Add Image, Add File Add Link).
I'm no tinymce expert and struggled with the last lot of changes but more then willing to have another go. If anyone else would like to help out?
We actually have consciously extracted the concrete5 stuff from
TinyMCE as much as possible.
Way back when we were commercial we followed some of the ideas
outlined here and found them to generally be very hard to maintain and
not intuitive at all.
In-page editing doesn't work that well. The tool bars mess with the
div space and don't fit in smaller content spaces. Or you have to
build toolbars into the main CMS toolbar which makes the whole thing
intimidating at the top of your browser. Not having save/discard on
exit a block makes saving changes and page versioning a bit of a
nightmare.
Building a form inside of the page the form is going to live on is
actually a huge nightmare. There's no space to put any chrome for
building the form. The modal overlay is a great universal solution to
these problems, and it works for all blocks. Some blocks are pretty
complicated, the modal overlay is really nice. We had a mixed model
for a while, that was a confusing experience for users.
We've used FCKEditor in the past (amongst others) and tried to do deep
integration (had my UX hat on) Looked great when we launched it. Then
a new version of FCKEditor came out. Had to redo all that work again.
Then another new version of FCKEditor came out. Did all that work
again. Lather, rinse repeat....Every time a new version of either our
app or their app came out, we lost half a day at best worried about
our deep integration. That real world experience is why there's a
concrete5 toolbar above TinyMCE in concrete5 today. It's that we don't
know how, it's that it will slow every process down dramatically to
have to do that.
We also have an accomplished designer here on staff full time. It's
not through lack of interest or ability that things are the way they
are, its because of our own experiences with it. I'm sure we've made
many mistakes and less than ideal decisions over the years, but
there's some of the thinking behind why concrete5 works the way it
does today - for what it's worth.
Of course, I'm just sharing that as some background and I encourage
you guys to do whatever you think is best with your own time.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
TinyMCE as much as possible.
Way back when we were commercial we followed some of the ideas
outlined here and found them to generally be very hard to maintain and
not intuitive at all.
In-page editing doesn't work that well. The tool bars mess with the
div space and don't fit in smaller content spaces. Or you have to
build toolbars into the main CMS toolbar which makes the whole thing
intimidating at the top of your browser. Not having save/discard on
exit a block makes saving changes and page versioning a bit of a
nightmare.
Building a form inside of the page the form is going to live on is
actually a huge nightmare. There's no space to put any chrome for
building the form. The modal overlay is a great universal solution to
these problems, and it works for all blocks. Some blocks are pretty
complicated, the modal overlay is really nice. We had a mixed model
for a while, that was a confusing experience for users.
We've used FCKEditor in the past (amongst others) and tried to do deep
integration (had my UX hat on) Looked great when we launched it. Then
a new version of FCKEditor came out. Had to redo all that work again.
Then another new version of FCKEditor came out. Did all that work
again. Lather, rinse repeat....Every time a new version of either our
app or their app came out, we lost half a day at best worried about
our deep integration. That real world experience is why there's a
concrete5 toolbar above TinyMCE in concrete5 today. It's that we don't
know how, it's that it will slow every process down dramatically to
have to do that.
We also have an accomplished designer here on staff full time. It's
not through lack of interest or ability that things are the way they
are, its because of our own experiences with it. I'm sure we've made
many mistakes and less than ideal decisions over the years, but
there's some of the thinking behind why concrete5 works the way it
does today - for what it's worth.
Of course, I'm just sharing that as some background and I encourage
you guys to do whatever you think is best with your own time.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
This pretty much wraps it up. Reasonable explanation + decision not to waste precious time on text editing flow = no core changes in this respect any time soon.
However, input like this [with a bit more detailed history and set of requirements] may help others take it from the right angle and maybe suggest or even come up with a solution good enough to be adopted by the core.
I can only repete in more articulate way what I envisage as a desired flow in this case:
1. Put the page in edit mode
[ Due to present C5 flow, page versioning and consistency, though this global flow could be improved as well, which is another subject ]
2. Click on a block containing some text [usually a paragraph or a headline]
3. Choose "Edit" from the displayed menu [again consistency]
4. Simple in-line editing frame appears with no formatting tools* and very few options:
"Save", "Cancel" and "Rich Text Edit" [or similar label].
5. If "Rich Text" option is chosen, TinyMCE [or whichever is set by default] appears in modal, the usual way.
5a. Once in Rich Text Editor, user could have an option [checkbox]: "Always open as "Rich Text" [or similar].
5b. Ability to enable/disable "Rich Text Edit option" for a block by an admin at the point of adding a block. Such global preference should find its place in dashboard.
---
* Gray area: Where to draw a line? Should there be an extremely condensed set of formatting options enabled, such as bold, italic, underline and...maybe html.
This could trigger some headache so I better state what the ultimate goal of the above should be [IMHO]:
1. Make more than 60-70% of common editing faster.
2. Prevent end users from messing it up, having streamlined, less intimidating, positive experience while still having an option to have full set of features [at their own risk] :-)
I hope this makes sense.
However, input like this [with a bit more detailed history and set of requirements] may help others take it from the right angle and maybe suggest or even come up with a solution good enough to be adopted by the core.
I can only repete in more articulate way what I envisage as a desired flow in this case:
1. Put the page in edit mode
[ Due to present C5 flow, page versioning and consistency, though this global flow could be improved as well, which is another subject ]
2. Click on a block containing some text [usually a paragraph or a headline]
3. Choose "Edit" from the displayed menu [again consistency]
4. Simple in-line editing frame appears with no formatting tools* and very few options:
"Save", "Cancel" and "Rich Text Edit" [or similar label].
5. If "Rich Text" option is chosen, TinyMCE [or whichever is set by default] appears in modal, the usual way.
5a. Once in Rich Text Editor, user could have an option [checkbox]: "Always open as "Rich Text" [or similar].
5b. Ability to enable/disable "Rich Text Edit option" for a block by an admin at the point of adding a block. Such global preference should find its place in dashboard.
---
* Gray area: Where to draw a line? Should there be an extremely condensed set of formatting options enabled, such as bold, italic, underline and...maybe html.
This could trigger some headache so I better state what the ultimate goal of the above should be [IMHO]:
1. Make more than 60-70% of common editing faster.
2. Prevent end users from messing it up, having streamlined, less intimidating, positive experience while still having an option to have full set of features [at their own risk] :-)
I hope this makes sense.
This is a bit nicer
http://thebigreason.com/blog/2008/09/29/thebigreason-tinymce-skin...
You have to install it to the core which is stoopid, but it's nice enough. I'm not sure if famfam silk icons are c5 licence compatible, but that gets me through the horror of the ugly as all ugly look of tiny mce default without diy'ing it.
add
In the editor config file.
http://thebigreason.com/blog/2008/09/29/thebigreason-tinymce-skin...
You have to install it to the core which is stoopid, but it's nice enough. I'm not sure if famfam silk icons are c5 licence compatible, but that gets me through the horror of the ugly as all ugly look of tiny mce default without diy'ing it.
add
skin: "thebigreason",
In the editor config file.
Then add this to the theme to get rid of that somewhat past it's prime c5 bar
div.ccm-editor-controls, div.ccm-editor-controls-right-cap { background: none !important; } div.ccm-editor-controls-left-cap { border: 1px solid #ccc; background-image: linear-gradient(bottom, rgb(235,235,235) 20%, rgb(240,240,240) 60%) !important; background-image: -o-linear-gradient(bottom, rgb(235,235,235) 20%, rgb(240,240,240) 60%) !important; background-image: -moz-linear-gradient(bottom, rgb(235,235,235) 20%, rgb(240,240,240) 60%) !important; background-image: -webkit-linear-gradient(bottom, rgb(235,235,235) 20%, rgb(240,240,240) 60%) !important; background-image: -ms-linear-gradient(bottom, rgb(235,235,235) 20%, rgb(240,240,240) 60%) !important; background-image: -webkit-gradient( linear, left bottom, left top,
Viewing 15 lines of 19 lines. View entire code block.
Yes, I think finding a better theme for TinyMCE, if it feels like that theme is going to be maintained well, would be a great idea.
Updating the UI of the concrete5 tool bar above tinyMCE to feel more bootstrappy makes sense to me too. do it once, leave it be. yay. ;)
Updating the UI of the concrete5 tool bar above tinyMCE to feel more bootstrappy makes sense to me too. do it once, leave it be. yay. ;)
I really like this idea, thanks for the how to, Ill be playing with that pretty soon.
the real in-context thing doesn't seem that hard, and cleaning up messy HTML code be done pretty easily by running it throughhttp://htmlpurifier.org/, but does anyone have a better open-source alternative to tinymce, since everyone agrees that it's a pain?
TinyMCE is a bit of a pain. Our customers and even my co-workers tend to always come across something goofy, or something they can't figure out. If c5 could integrate or make something slicker/nicer that would obviously be nice. I'll start looking around for an alternative as well.
p.s. that's a pretty bad ass quick edit. I'd love to have something like that for my clients. When will that be available?
p.s. that's a pretty bad ass quick edit. I'd love to have something like that for my clients. When will that be available?
i'd imagine that after html5 is standard, text editors are going to get a lot nicer since html5 has better support for things like text selections. i don't think it's practical to expect concrete to develop their own wysiwyg though, it's just too huge of a project.
tony, your quick edit is definitely onto something.
i think the rollover cue is nice but its not super obvious which things are editable. i also think some formatting things would be nice (just very very basic ones -- bold, italic, ul lists, ol lists, and format (p, h1, etc). ideally there would be internal/external link capabilities and html (source) mode as well. i'd pay a lot of $ for this though i think it would make a nice edition to the core.
regarding tinymce again, i even have issues just copy and pasting content from one content block to another. the only way to not screw it up is to copy the source code.
i think the rollover cue is nice but its not super obvious which things are editable. i also think some formatting things would be nice (just very very basic ones -- bold, italic, ul lists, ol lists, and format (p, h1, etc). ideally there would be internal/external link capabilities and html (source) mode as well. i'd pay a lot of $ for this though i think it would make a nice edition to the core.
regarding tinymce again, i even have issues just copy and pasting content from one content block to another. the only way to not screw it up is to copy the source code.
I agree, the quick edit looks fantastic. There's another open source CMS called MySourceMini which has in-context editing that doesn't open a window - you just type directly on the page. You can see a demo of it here (http://mini.squiz.net/features/inline-editing ) - it's pretty impressive. You can get the CMS here:http://mini.squiz.net/download
although they seem to require running it in a VM bizarrely.. they seem to be pushing the purchase of services/hosting very strongly, because it's not very easy to get a copy of that CMS and just download and self-host it (which is the reason I decided against building my org's site with it).
Anyway, if someone more expert than me digs around the source they might be able to get the inline editing code and repurpose it for c5's use.
Ironically, it was only after seeing a demonstration of /that/ CMS that I looked for an alternative which also had in-page editing, which brought me to concrete5. My initial thought was that MySourceMini's editing was better, but c5's was good enough for noob users.. maybe we can use their code and supercharge c5's in-context editing :)
although they seem to require running it in a VM bizarrely.. they seem to be pushing the purchase of services/hosting very strongly, because it's not very easy to get a copy of that CMS and just download and self-host it (which is the reason I decided against building my org's site with it).
Anyway, if someone more expert than me digs around the source they might be able to get the inline editing code and repurpose it for c5's use.
Ironically, it was only after seeing a demonstration of /that/ CMS that I looked for an alternative which also had in-page editing, which brought me to concrete5. My initial thought was that MySourceMini's editing was better, but c5's was good enough for noob users.. maybe we can use their code and supercharge c5's in-context editing :)
my two cents...
While I agree that TinyMCE does have it's issues, I do believe it's one of the better editors out there. When I build C5 templates I try to set them up in such a way that the only HTML that's going to be editable is basic stuff like <p>,<h1-5>,<ul>,<img> and maybe a few minor things here and there, and keep a much formatting as possible in the CSS alone. I think that we must build themes with non-geeks in mind as well, so that editing can be as basic as possible.
With regard to literal in-context editing (like Tony's quick edit) as opposed to C5's in-context editing via pop-up...I could go either way. I don't think there is much of a downside to the pop-up. It even seems like having the area directly on the page could be tricky depending on the size of the area and things like that. I do like the ease and "quickness" of the quick edit, but for most clients I don't see a strong advantage of that over going into Edit Mode and editing a block.
One last thought - regarding that unify editor - to me, that's more confusing than the TinyMCE editor. That may be because I only looked at it for about 30 seconds. But I think that's the advantage of TinyMCE - it's similar to something like MS Word, so it doesn't intimidate non-geek users. They know how to use it without anyone explaining it to them.
All that to say, sure TinyMCE has it's flaws, but I don't think it's holding Concrete5 back by ANY means. Some additional options for editors would be helpful as add-ons (I just purchased eylon's code editor add-on yesterday and I love it because it's like the HTML block but with code highlighting and it integrates with C5's file manager/site map), but I honestly haven't come across any yet that I think are a significantly better solution.
While I agree that TinyMCE does have it's issues, I do believe it's one of the better editors out there. When I build C5 templates I try to set them up in such a way that the only HTML that's going to be editable is basic stuff like <p>,<h1-5>,<ul>,<img> and maybe a few minor things here and there, and keep a much formatting as possible in the CSS alone. I think that we must build themes with non-geeks in mind as well, so that editing can be as basic as possible.
With regard to literal in-context editing (like Tony's quick edit) as opposed to C5's in-context editing via pop-up...I could go either way. I don't think there is much of a downside to the pop-up. It even seems like having the area directly on the page could be tricky depending on the size of the area and things like that. I do like the ease and "quickness" of the quick edit, but for most clients I don't see a strong advantage of that over going into Edit Mode and editing a block.
One last thought - regarding that unify editor - to me, that's more confusing than the TinyMCE editor. That may be because I only looked at it for about 30 seconds. But I think that's the advantage of TinyMCE - it's similar to something like MS Word, so it doesn't intimidate non-geek users. They know how to use it without anyone explaining it to them.
All that to say, sure TinyMCE has it's flaws, but I don't think it's holding Concrete5 back by ANY means. Some additional options for editors would be helpful as add-ons (I just purchased eylon's code editor add-on yesterday and I love it because it's like the HTML block but with code highlighting and it integrates with C5's file manager/site map), but I honestly haven't come across any yet that I think are a significantly better solution.
@jgarcia
How do you prevent other things from being edited with tinymce? do you edit the toolbar? I am building a site which needs to be as noob-proof as possible and tiny mce does have its problems on that front. Simplifying the interface is one way forward I guess, but there's no doubt it spits out some questionable code at times, even for basic edits.
How do you prevent other things from being edited with tinymce? do you edit the toolbar? I am building a site which needs to be as noob-proof as possible and tiny mce does have its problems on that front. Simplifying the interface is one way forward I guess, but there's no doubt it spits out some questionable code at times, even for basic edits.
Well, I don't prevent them from doing certain things in the editor...I just make it so that they don't have to. For example, if the page title needs appear inside of an h1 on every single page, I don't put that in the editable content, I put it in the template itself via $c->getCollectionName().
It really all depends...my viewpoint is just that you can do a lot of limitation within the theme itself to make the actual editable text as plain as possible, and thus prevent a lot of the problems that many people have with TinyMCE. Does that help/make sense?
It really all depends...my viewpoint is just that you can do a lot of limitation within the theme itself to make the actual editable text as plain as possible, and thus prevent a lot of the problems that many people have with TinyMCE. Does that help/make sense?
Ah I see. I take that approach too (e.g. embedding the title), but it doesn't get round situations where for example the editor wants to insert an image in a content block and have it float to the right with a particular style applied (it's not as simple as is might be for a non-HTML-savvy editor). Other tags cause miscellaneous trouble too, e.g. linebreaks and horizontal rules. It also inserts blank paragraphs with non-breaking linespaces instead of proper linebreak tags, which is annoying.
> does anyone have a better open-source alternative
> to tinymce, since everyone agrees that it's a pain?
I've used ckEditor as a WordPress plug-in and even integrated it into an SMF forum (used HTMLPurifier and ckEditor in place of the native bbcode nonsense), and I liked its features and configurability.
http://ckeditor.com/
(I was sorely disappointed that C5 didn't do something similar for its forum instead of jumping on the bbcode bandwagon.)
-Steve
> to tinymce, since everyone agrees that it's a pain?
I've used ckEditor as a WordPress plug-in and even integrated it into an SMF forum (used HTMLPurifier and ckEditor in place of the native bbcode nonsense), and I liked its features and configurability.
http://ckeditor.com/
(I was sorely disappointed that C5 didn't do something similar for its forum instead of jumping on the bbcode bandwagon.)
-Steve
Hmm I do like the look and feel of that. I wonder how difficult it would be to replace TinyMCE in c5? I had a dig around the javascript for TinyMCE the other day and it looked (to my inexpert eye) fairly well embedded. I wonder what the devs think?
There's this too:
http://nicedit.com/
Which appears to show up inline while in edit mode - a toolbar is put above all areas of editable text.
http://nicedit.com/
Which appears to show up inline while in edit mode - a toolbar is put above all areas of editable text.
A quick google for "ckeditor vs tinymce" shows quite a lot of support for the former and quite a bit of derision for the latter (apparently the devs don't even want to receive bug reports!).
I think the question of whether there is something better out there is definitely worth considering in order to keep c5 at the helm of the CMS crowd.
I think the question of whether there is something better out there is definitely worth considering in order to keep c5 at the helm of the CMS crowd.
I know this problem. The WYSIWYG area is just too general purpose to be the best for a lost of content situations.
What I think I'm going to end up doing is building a lot of custom blocks that are basically just a few data areas + a simple template.
Maybe I have some nice content styled with a floating image and a styled header wrapped in a neat way around some content. I create a custom block that has fields for each section, textarea for header, imagepicker, and then the block outputs just the right HTML for that situation. Sometimes there's a few options for some variations.
Basically using blocks like people use Page Attributes. I do wish it was possible to create/edit such blocks right from the interface, like how you can add Page attributes. I'd like to tweak the block templates right from the block config screen actually, that'd be sweet. Obviously would only work for simple blocks like I'm talking about.
What I think I'm going to end up doing is building a lot of custom blocks that are basically just a few data areas + a simple template.
Maybe I have some nice content styled with a floating image and a styled header wrapped in a neat way around some content. I create a custom block that has fields for each section, textarea for header, imagepicker, and then the block outputs just the right HTML for that situation. Sometimes there's a few options for some variations.
Basically using blocks like people use Page Attributes. I do wish it was possible to create/edit such blocks right from the interface, like how you can add Page attributes. I'd like to tweak the block templates right from the block config screen actually, that'd be sweet. Obviously would only work for simple blocks like I'm talking about.
I like WYMeditorhttp://www.wymeditor.org/.
wymeditor fails. just copy and paste in that editor and you got some ugly a$$ code.
a combination of a really basic toolbar editor combined with that quickedit block would be a dream! clean code is all i ask. quickedit would also only be available if the user clicks "edit"
i think my major issue is that i don't want my clients in control. the WYSIWYG gives them that. and they ultimately screw things up which defeats the purpose of even having a CMS since i have to fix it.
clients aren't designers. clients shouldn't be able to do anything but:
- bold
- italic
- ul, ol
- format select (h1,h2,h3,h4,h5,h6,p or just custom ones we assign)
- internal link, external link
i'm not even sure i want them adding images in the editor. if so, this needs to be done in a way where its foolproof. otherwise, this should be done using layout and using an image specific block.
i think my major issue is that i don't want my clients in control. the WYSIWYG gives them that. and they ultimately screw things up which defeats the purpose of even having a CMS since i have to fix it.
clients aren't designers. clients shouldn't be able to do anything but:
- bold
- italic
- ul, ol
- format select (h1,h2,h3,h4,h5,h6,p or just custom ones we assign)
- internal link, external link
i'm not even sure i want them adding images in the editor. if so, this needs to be done in a way where its foolproof. otherwise, this should be done using layout and using an image specific block.
Wow this is a long thread that's covering a lot of ground...
I just thought I'd point out, we actually already had "in-page in-context editing" with earlier versions of concrete cms. Perhaps Tony doesn't remember or it was before his time, but when we first architected this thing in 2003 that was the original idea.. the page looks EXACTLY the same in edit mode and view mode except you can change stuff in edit mode. It sounded nice.
It kinda fell apart in practice.
1) There are many places where the editing space is just too thin. If you have a side bar or whatnot the inline wysiwyg editor becomes a huge pain. Yes you can split the editing toolbars up and to the top of the page - but now you're introducing weird usability issues around the application UI. Start having butt loads of toolbars turn off and on in spots that are visually non-connected to what you're editing and you're not building a very mom-friendly UI.
2) There are many blocks where you need a lot more space than in-line for options. This whole conversation falls apart when you're talking about putting a product list block in edit mode. The whole metaphor goes out the window.
3) It misses the point. The huge advantage of in-context editing is the context - not wysiwyg. The workflow of realizing you have something you want to change on a page as you look at it, and THEN having to go somewhere else entirely on the backend to change it is so very painful. Being able to put a page in edit mode right then is way better. That's the payoff. Confusing that with "the page must look exactly the same in edit mode" is a mistake from my experience. The client wants the page to be easy to edit.. easy is the goal, not pixel perfect WYSIWYG.. ... if WYSIWYG leads to easy, thats great, but if it makes things more intimidating, that's not.
4) its a huge pain to keep track of all these tweaks.. if you lose putting a block in and out of edit mode you lose a great way to save data as you go.
So look I'm not saying any of these issues aren't resolvable, I'm just letting ya know this is a road we've been down and then walked back up. Take that for what it's worth.
That aside, yes I hate hate hate tinyMCE so very very much. It's better than FCKEditor which is what we were using in concrete v4. If there's a better editor we can integrate as the default content editor and will work from a license prospective, I'm all for it.
Huge pain to change, but I agree, tinyMCE does some funky stuff and I wish it would be cleaner.. Can't say I'd ever want to solve the problem they're solving, but yup.
I just thought I'd point out, we actually already had "in-page in-context editing" with earlier versions of concrete cms. Perhaps Tony doesn't remember or it was before his time, but when we first architected this thing in 2003 that was the original idea.. the page looks EXACTLY the same in edit mode and view mode except you can change stuff in edit mode. It sounded nice.
It kinda fell apart in practice.
1) There are many places where the editing space is just too thin. If you have a side bar or whatnot the inline wysiwyg editor becomes a huge pain. Yes you can split the editing toolbars up and to the top of the page - but now you're introducing weird usability issues around the application UI. Start having butt loads of toolbars turn off and on in spots that are visually non-connected to what you're editing and you're not building a very mom-friendly UI.
2) There are many blocks where you need a lot more space than in-line for options. This whole conversation falls apart when you're talking about putting a product list block in edit mode. The whole metaphor goes out the window.
3) It misses the point. The huge advantage of in-context editing is the context - not wysiwyg. The workflow of realizing you have something you want to change on a page as you look at it, and THEN having to go somewhere else entirely on the backend to change it is so very painful. Being able to put a page in edit mode right then is way better. That's the payoff. Confusing that with "the page must look exactly the same in edit mode" is a mistake from my experience. The client wants the page to be easy to edit.. easy is the goal, not pixel perfect WYSIWYG.. ... if WYSIWYG leads to easy, thats great, but if it makes things more intimidating, that's not.
4) its a huge pain to keep track of all these tweaks.. if you lose putting a block in and out of edit mode you lose a great way to save data as you go.
So look I'm not saying any of these issues aren't resolvable, I'm just letting ya know this is a road we've been down and then walked back up. Take that for what it's worth.
That aside, yes I hate hate hate tinyMCE so very very much. It's better than FCKEditor which is what we were using in concrete v4. If there's a better editor we can integrate as the default content editor and will work from a license prospective, I'm all for it.
Huge pain to change, but I agree, tinyMCE does some funky stuff and I wish it would be cleaner.. Can't say I'd ever want to solve the problem they're solving, but yup.
Well said, frz...especially on #3.
Question for you, since you would have more knowledge of this than anyone else...exactly how difficult WOULD it be to 1)Have a default editor built-in to C5 OR 2)Have a different editor available as an add-on? Even possible?
Question for you, since you would have more knowledge of this than anyone else...exactly how difficult WOULD it be to 1)Have a default editor built-in to C5 OR 2)Have a different editor available as an add-on? Even possible?
i dont think the integration with tinyMCE is THAT horrible of a thing to undo.. we actually made that little c5 toolbar above instead of trying to hook into the editor deeper from like the image icon or whatever in an effort to make it easier to keep it separated.
go for it..
Easiest way to win at this would be copy the content block and call it awesomeContent .. get whatever LGPL/MIT licensed editor you can working as it - and if its a better experience for you and some beta folk we'll consider swapping it out with content block in a core release.
lotso karma points for that one for sure..
it'd be fun to hate something that isn't tinyMCE for a while. ;)
go for it..
Easiest way to win at this would be copy the content block and call it awesomeContent .. get whatever LGPL/MIT licensed editor you can working as it - and if its a better experience for you and some beta folk we'll consider swapping it out with content block in a core release.
lotso karma points for that one for sure..
it'd be fun to hate something that isn't tinyMCE for a while. ;)
it's good to see some people above into that quick edit block. note that as I mentioned above, the main reason for making that was because I wanted to be able to edit quicker. it can edit a small chunk of content in about 5 seconds (just 2 clicks, 1 ajax call), when even on my fast local connection it takes about 30+ second with the old content editor (with 6+ clicks, 2 pages refreshes, multiple ajax calls). If I'm at a coffee shop with a slow connection, the core way of editing content can take a couple of minutes to make an simple text edit.
So to address franz's points, yes, I do remember when things were inline, and for most block types in makes total sense to use a popup. I don't think that's the case for all scenarios though. for text, I personally like the idea of most desktop software, where you just click on the text you want to edit, without having to enter an edit mode.
1) yeah, it would be easy to add a WYSIWIG in that quick edit block, but franz is right that you run into problems when the content is too narrow. I think that Unify example above addresses that problem brilliantly though. Another solution would be just to provide an option for in-context vs. popup in the block edit screen.
2) yeah, I don't think people are really wanting more complex block interfaces in-context though.
3) agreed.
4) edit mode currently only saves one version per editing session. so if you type something brilliant, edit it again and accidentally delete a big section or mess something up, you can't get it back. that's part of the reason for the block level versioning on that block, which takes a snapshot of every save.
btw, did we figure out a way to turn off that versions panel? For me I'd rather it just auto-approved, and exited edit mode faster without seeing that panel.
So to address franz's points, yes, I do remember when things were inline, and for most block types in makes total sense to use a popup. I don't think that's the case for all scenarios though. for text, I personally like the idea of most desktop software, where you just click on the text you want to edit, without having to enter an edit mode.
1) yeah, it would be easy to add a WYSIWIG in that quick edit block, but franz is right that you run into problems when the content is too narrow. I think that Unify example above addresses that problem brilliantly though. Another solution would be just to provide an option for in-context vs. popup in the block edit screen.
2) yeah, I don't think people are really wanting more complex block interfaces in-context though.
3) agreed.
4) edit mode currently only saves one version per editing session. so if you type something brilliant, edit it again and accidentally delete a big section or mess something up, you can't get it back. that's part of the reason for the block level versioning on that block, which takes a snapshot of every save.
btw, did we figure out a way to turn off that versions panel? For me I'd rather it just auto-approved, and exited edit mode faster without seeing that panel.
> I just thought I'd point out, we actually already had
> "in-page in-context editing" with earlier versions of
> concrete cms.
Intertesting, I didn't realize that.
> It kinda fell apart in practice.
> 1) There are many places where the editing space
> is just too thin.
Only if the toolbar is "attached" to the content being edited.
> Yes you can split the editing
> toolbars up and to the top of the page - but now you're
> introducing weird usability issues around the application
> UI.
The there are more ways to approach the issue and just the two methods you mention which utilize toolbars.
> 2) There are many blocks where you need a lot more space
> than in-line for options.
Of course. And I can envision a "window" which presents those options, but it wouldn't be "modal." And changing the options would cause the page to be updated in real time.
> This whole conversation falls
> apart when you're talking about putting a product list block
> in edit mode. The whole metaphor goes out the window.
No, the conversation just starts getting interesting. What I mean by "in-context" and WYSIWYG is not constrained to editing only "content" type blocks (although a content block does seem ideally suited to the "conventional" in-context WYSIWYG editor.)
> 3) It misses the point.
I don't know about you, but my point is to make editing as quick and easy as possible for the site maintainer.
> The huge advantage of in-context
> editing is the context - not wysiwyg.
I think they're both important. For instance... Why, when I'm on a page editing my breadcrumb AutoNav block, am I forced to click a "Preview" tab only to see something that doesn't look anything like what I'm editing. Why can't changes to the block be reflected on the page itself. The "Preview" tab seems superfluous (and even potentially confusing).
> 4) its a huge pain to keep track of all these tweaks..
Pain for whom?
> if you lose putting a block in and out of edit mode
> you lose a great way to save data as you go.
That can (and perhaps should) be handled behind the scenes.
> I hate hate hate tinyMCE so very very much.
> It's better than FCKEditor which is what we were using in
> concrete v4.
Better how?
BTW, FCKEditor is no more; it's ckEditor. I don't know how long ago Concrete v4 was around, but having used ckEditor just a few months (not years) ago, I thought it was well documented, flexible, configurable, and generated clean mark-up. It's also very easy to add/remove buttons and button groups. I haven't looked at very many such editors. ckEditor suited my needs at the time, so I went with it. (YUI looked pretty good too.)
-Steve
> "in-page in-context editing" with earlier versions of
> concrete cms.
Intertesting, I didn't realize that.
> It kinda fell apart in practice.
> 1) There are many places where the editing space
> is just too thin.
Only if the toolbar is "attached" to the content being edited.
> Yes you can split the editing
> toolbars up and to the top of the page - but now you're
> introducing weird usability issues around the application
> UI.
The there are more ways to approach the issue and just the two methods you mention which utilize toolbars.
> 2) There are many blocks where you need a lot more space
> than in-line for options.
Of course. And I can envision a "window" which presents those options, but it wouldn't be "modal." And changing the options would cause the page to be updated in real time.
> This whole conversation falls
> apart when you're talking about putting a product list block
> in edit mode. The whole metaphor goes out the window.
No, the conversation just starts getting interesting. What I mean by "in-context" and WYSIWYG is not constrained to editing only "content" type blocks (although a content block does seem ideally suited to the "conventional" in-context WYSIWYG editor.)
> 3) It misses the point.
I don't know about you, but my point is to make editing as quick and easy as possible for the site maintainer.
> The huge advantage of in-context
> editing is the context - not wysiwyg.
I think they're both important. For instance... Why, when I'm on a page editing my breadcrumb AutoNav block, am I forced to click a "Preview" tab only to see something that doesn't look anything like what I'm editing. Why can't changes to the block be reflected on the page itself. The "Preview" tab seems superfluous (and even potentially confusing).
> 4) its a huge pain to keep track of all these tweaks..
Pain for whom?
> if you lose putting a block in and out of edit mode
> you lose a great way to save data as you go.
That can (and perhaps should) be handled behind the scenes.
> I hate hate hate tinyMCE so very very much.
> It's better than FCKEditor which is what we were using in
> concrete v4.
Better how?
BTW, FCKEditor is no more; it's ckEditor. I don't know how long ago Concrete v4 was around, but having used ckEditor just a few months (not years) ago, I thought it was well documented, flexible, configurable, and generated clean mark-up. It's also very easy to add/remove buttons and button groups. I haven't looked at very many such editors. ckEditor suited my needs at the time, so I went with it. (YUI looked pretty good too.)
-Steve
Uhh. Yeah.. I haven't looked at ckEditor since they dropped the F.. probably a good branding idea..
in terms of the rest of the inline reply - i dunno man.. cms is a big challenge to solve, in-context really helps site owners feel like they can make changes when they want to. That's super important. I maintain that keeping the entire experience as WYSIWYG as possible is far less important than creating a interface that can easily adapt to unpredictable situations well. I feel like our modal block edit windows do that, and I doubt that rethinking that would make it any easier for the 3rd party developers trying to deliver great work in the marketplace.
but, yeah. it'd be awesome if someone wanted to prototype ckEditor integration into c5.
in terms of the rest of the inline reply - i dunno man.. cms is a big challenge to solve, in-context really helps site owners feel like they can make changes when they want to. That's super important. I maintain that keeping the entire experience as WYSIWYG as possible is far less important than creating a interface that can easily adapt to unpredictable situations well. I feel like our modal block edit windows do that, and I doubt that rethinking that would make it any easier for the 3rd party developers trying to deliver great work in the marketplace.
but, yeah. it'd be awesome if someone wanted to prototype ckEditor integration into c5.
jhart, have you used this successfully on any of your c5 sites?
Clients are not designers. They don't just have a tendency to, but _always_ blow up their site--no matter how many times you tell them not to make their text rainbowed and blinking.
So, on that note, one of the things I would like to see--whether it be with tinyMCE or another editor--would be the ability to further customize what icons show up when editing content.
Without going any further, I know that you can select the "Custom" option in the Dashboard and edit some stout looking code to limit the icons/functionality available for certain users.
What would be better would be to have some check-boxes where one could select what they wanted to have appear and not appear when choosing the "Custom" option.
Thoughts on this? I apologize for being slightly off topic.
So, on that note, one of the things I would like to see--whether it be with tinyMCE or another editor--would be the ability to further customize what icons show up when editing content.
Without going any further, I know that you can select the "Custom" option in the Dashboard and edit some stout looking code to limit the icons/functionality available for certain users.
What would be better would be to have some check-boxes where one could select what they wanted to have appear and not appear when choosing the "Custom" option.
Thoughts on this? I apologize for being slightly off topic.
just have a little icon in the plain editor that can "pop-up" the toolbar. you can then pretty much keep your editor like it is Tony, and just extend it.
Chad
Chad
almost every editor i looked at screws code up. for instance i wrote "hello there!" in the ckeditor... copy, paste that line... the source outputs like this:
fail. i don't know about you guys but my clients copy and paste a lot in the editor ("lets put that paragraph first"... "move that word/sentence here", etc). i don't really care if it looks like unify and replicates styles. i don't care if its a popup or not. i just care that things are consistently rendered correctly. the new basecamp editor (http://basecamphq.com/help/messages#wys_text_editor) seems to be on the right track. and campaign monitor has manipulated ckeditor pretty well where it forces a clean paste. might be worth looking at.
i'm a designer. clients pay me to make their sites look good. its very important that the text editor doesn't get in the way of this.
<p> hello there!</p> <p> </p> <div style="font-family: Arial, Verdana, sans-serif; font-size: 12px; color: rgb(34, 34, 34); background-color: rgb(255, 255, 255); "> <p> hello there!</p> </div>
fail. i don't know about you guys but my clients copy and paste a lot in the editor ("lets put that paragraph first"... "move that word/sentence here", etc). i don't really care if it looks like unify and replicates styles. i don't care if its a popup or not. i just care that things are consistently rendered correctly. the new basecamp editor (http://basecamphq.com/help/messages#wys_text_editor) seems to be on the right track. and campaign monitor has manipulated ckeditor pretty well where it forces a clean paste. might be worth looking at.
i'm a designer. clients pay me to make their sites look good. its very important that the text editor doesn't get in the way of this.
> for instance i wrote "hello there!" in the ckeditor...
> copy, paste that line... the source outputs like this...
I don't know which implementation of the editor you're using or why you copy and paste, but when I type that into my WordPress blog (which uses the ckEditor plug-in) and view the source, I see the following:
I'm not trying to defend ckEditor; I'm just curious as to why you get the output you do.
-Steve
> copy, paste that line... the source outputs like this...
I don't know which implementation of the editor you're using or why you copy and paste, but when I type that into my WordPress blog (which uses the ckEditor plug-in) and view the source, I see the following:
<p>hello there!</p>
I'm not trying to defend ckEditor; I'm just curious as to why you get the output you do.
-Steve
Oh ok, I understand now that you're simply copying and pasting the line within the editor to see how it behaves! I got similar results. That IS bizarre!
Just out of curiosity, are you on a Mac? I wonder if the system paste functionality (which attempts to preserve formatting) is interfering somehow.
Hmm, strange.
-Steve
Just out of curiosity, are you on a Mac? I wonder if the system paste functionality (which attempts to preserve formatting) is interfering somehow.
Hmm, strange.
-Steve
> I wonder if the system paste functionality (which
> attempts to preserve formatting) is interfering
> somehow.
I think that's precisely what's happening. If I use ckEditor's "Paste as Plain Text" button, it pastes nice and clean, but that's awkward.
...wait! I just tried Firefox, and copying and pasting using plain old Command-V works great and generates clean mark-up! Interesting!
-Steve
> attempts to preserve formatting) is interfering
> somehow.
I think that's precisely what's happening. If I use ckEditor's "Paste as Plain Text" button, it pastes nice and clean, but that's awkward.
...wait! I just tried Firefox, and copying and pasting using plain old Command-V works great and generates clean mark-up! Interesting!
-Steve
ya, i'm on mac. safari + chrome don't like it but firefox is behaving.
running the pasted html through htmlPurifier would help cleanup some of that messy code, provided it was set up right.
I agree with what riotaj said.
In the short experiences I've had with MS-Word-familiar clients using TinyMCE, I'm wishing results could be better. Most of the time I want to strip all the options down to just the straight HTML text markup, a link, and *maybe* an image tag.
Here's the thing… I don't feel like a full-fledged WYSIWYG editor is necessary. IMHO all you need is the standard HTML text markup: h1, h2, h3, p, blockquote, etc. Maybe a few custom span.yourspecialclass styles, and that's it. Most of my few (so far) C5-based clients would be happy with such restrictive options because it simplifies things for them. It's not the number of options that you need—it's the consistency of the options.
What I think would be the best solution is something like the Pages styles drawer in iWork (a screenshot of it can be found here:http://moultriecreek.us/media/styles3-20090517-064931.jpg... ). Show the clients their different markup options, completely styled as they will appear in the theme itself, within that drawer. When they click on one style, the style is set; they click on another OR start a new line, and the style is unset, etc. There doesn't need to be a host of little options for font resizing, colors, etc.
Maybe it is a bit draconian, but it gives the styling power to the designer via CSS, contextual to the site's theme—which is where it should be.
(Besides, in TinyMCE you don't actually see how the text will look until you actually hit "Publish" and the text is being styled by the theme. Defeats the whole point of WYSIWYG IMO).
I'm a newbie at JS and PHP, but if I ever get to the level that I can create something like that, I will. I know my clients would like it—their headaches have been on occasion unknowingly been caused by using TinyMCE. I think it would be a great alternative to the community, too.
In the short experiences I've had with MS-Word-familiar clients using TinyMCE, I'm wishing results could be better. Most of the time I want to strip all the options down to just the straight HTML text markup, a link, and *maybe* an image tag.
Here's the thing… I don't feel like a full-fledged WYSIWYG editor is necessary. IMHO all you need is the standard HTML text markup: h1, h2, h3, p, blockquote, etc. Maybe a few custom span.yourspecialclass styles, and that's it. Most of my few (so far) C5-based clients would be happy with such restrictive options because it simplifies things for them. It's not the number of options that you need—it's the consistency of the options.
What I think would be the best solution is something like the Pages styles drawer in iWork (a screenshot of it can be found here:http://moultriecreek.us/media/styles3-20090517-064931.jpg... ). Show the clients their different markup options, completely styled as they will appear in the theme itself, within that drawer. When they click on one style, the style is set; they click on another OR start a new line, and the style is unset, etc. There doesn't need to be a host of little options for font resizing, colors, etc.
Maybe it is a bit draconian, but it gives the styling power to the designer via CSS, contextual to the site's theme—which is where it should be.
(Besides, in TinyMCE you don't actually see how the text will look until you actually hit "Publish" and the text is being styled by the theme. Defeats the whole point of WYSIWYG IMO).
I'm a newbie at JS and PHP, but if I ever get to the level that I can create something like that, I will. I know my clients would like it—their headaches have been on occasion unknowingly been caused by using TinyMCE. I think it would be a great alternative to the community, too.
Although I agree with all your points (esp that a restrictive set of options would be beneficial), it's not true that TinyMCE doesn't show WYSIWYG editing - if you duplicate the theme's text styles in typography.css you'll see the same styles in the TinyMCE window, which is close to WYSIWYG.
Really! Learn something new everyday…
Sorry - off topic, but which file is that? The typography.css in the default theme for the C5 core?
I tried to do an override of the selector there, but it didn't seem to work…
Sorry - off topic, but which file is that? The typography.css in the default theme for the C5 core?
I tried to do an override of the selector there, but it didn't seem to work…
Basically you copy the relevant text-related styles into typography.css in your theme's main folder (create that file if need be). I didn't always find it 100% reliable, but it was a great step forward to WYSIWYG editing.
There's a short intro on Remo's blog here:http://www.codeblog.ch/2009/05/concrete5-css-features/...
..and obviously, since TinyMCE is used all over the place, this feature is documented quite a bit all over the internet.
Others appear to have had problems getting it to work with c5 but I haven't had any real trouble, except for tweaking the CSS itself to work.
Here is the contents of my typography.css, if it helps:
There's a short intro on Remo's blog here:http://www.codeblog.ch/2009/05/concrete5-css-features/...
..and obviously, since TinyMCE is used all over the place, this feature is documented quite a bit all over the internet.
Others appear to have had problems getting it to work with c5 but I haven't had any real trouble, except for tweaking the CSS itself to work.
Here is the contents of my typography.css, if it helps:
#tinymce{font-size:90%;} /* Header styles */ h1,h2,h3,h4{font-family:Arial,Helvetica,sans-serif;} /* Headings */ h1{font-size:1.4em;color:#499;margin-bottom:20px;} h1.newstitle{margin:0px;padding:0px;} h2{font-size:1.2em;color:#058;padding:20px 0px;;margin:0px;text-indent:0;} h2.green{color:#499;} h3{font-size:0.9em;color:#058;padding:15px 0px;} h3 a{color:#058;} h3.newspagetitle{font-size:1.0em;} h3.newspagetitle a:hover{color:#499;} h4{font-size:1em;font-weight:bold;color:#058;padding:10px 0px;} /* Paragraphs */ p{font-family:Arial,Helvetica,sans-serif;font-size:0.9em;color:#058;line-height:140%;}
Viewing 15 lines of 36 lines. View entire code block.
> if you duplicate the theme's text styles in
> typography.css you'll see the same styles
> in the TinyMCE window, which is close to
> WYSIWYG.
IMO, that's a hoop you simply shouldn't have to jump through. And when you update/tweak the styles for the site, you have to change them in two places? Yuck!
-Steve
> typography.css you'll see the same styles
> in the TinyMCE window, which is close to
> WYSIWYG.
IMO, that's a hoop you simply shouldn't have to jump through. And when you update/tweak the styles for the site, you have to change them in two places? Yuck!
-Steve
i agree steve.
Not experienced in this field, but would it be possible to parse one CSS file so that when a user is logged in / in edit mode the correct typography styles are loaded?
Maybe separate the layout from styles you want to see in TinyMce like so in your main.css file?
/* Layout and stuff not to appear in TinyMCE */
#content { float:left; ... } etc.
/* Typography - styles and classes to appear in TinyMCE */
h1, h2 { color:#990000;... } etc.
Then you only edit on CSS file...
Let me know if there's a gaping flaw in that idea!
osu
Maybe separate the layout from styles you want to see in TinyMce like so in your main.css file?
/* Layout and stuff not to appear in TinyMCE */
#content { float:left; ... } etc.
/* Typography - styles and classes to appear in TinyMCE */
h1, h2 { color:#990000;... } etc.
Then you only edit on CSS file...
Let me know if there's a gaping flaw in that idea!
osu
just move all of the styles you want to display in tinymce to typography. no duplication then.
> just move all of the styles you want to
> display in tinymce to typography. no
> duplication then.
Aha! I should have looked more closely at the markup. I now see the typography.css is included whether you're in edit mode or not. :-/
-Steve
> display in tinymce to typography. no
> duplication then.
Aha! I should have looked more closely at the markup. I now see the typography.css is included whether you're in edit mode or not. :-/
-Steve
I've always thought that tinymce and the others was just too much for a client and needs to be locked down heavily to make even usable.
After having thoughts about this for the past year, and reading this exchange, I decided to create a new editor block that does in-place editing and heavily restricted and simplistic formatting options.
Please take a look and tell me what you think:
http://c5demo.lerteco.com/index.php/login?uName=ceo...
Because the block is integrated into c5's permissions system, you'll have to have edit permissions:
Username: ceo
Password: ceoceo
After that, check out the home page. Looks normal, but hover over one of the content blocks ("Welcome..." or "Sidebar"). You should get a little pencil button. Click that and you get a highly configurable editor.
Feel free to message me with comments / suggestions.
After having thoughts about this for the past year, and reading this exchange, I decided to create a new editor block that does in-place editing and heavily restricted and simplistic formatting options.
Please take a look and tell me what you think:
http://c5demo.lerteco.com/index.php/login?uName=ceo...
Because the block is integrated into c5's permissions system, you'll have to have edit permissions:
Username: ceo
Password: ceoceo
After that, check out the home page. Looks normal, but hover over one of the content blocks ("Welcome..." or "Sidebar"). You should get a little pencil button. Click that and you get a highly configurable editor.
Feel free to message me with comments / suggestions.
Very nice, jshannon! I like the in-context approach. Very clever technique to avoid using an IFRAME!
I noticed that clicking the add file or add image icon just inserts a hyphen. Perhaps that's just disabled or you haven't implemented it yet?
Cool idea...
-Steve
I noticed that clicking the add file or add image icon just inserts a hyphen. Perhaps that's just disabled or you haven't implemented it yet?
Cool idea...
-Steve
Thanks.
Actually, no... The hypen is a hack to get around a firefox bug on something else. The image and file insertion "works for me". :)
What browser were you using? Version? And how did you click the image / file buttons? Did you select something first? All the text? etc.
Yeah... I hate the IFRAME approach. But if you want to support most browsers it appears you have to do it. I find it messy and you lose the ability to inherit styles on the page (you have to reload individual stylesheets). I'm fine supporting "modern" browsers.
James
Actually, no... The hypen is a hack to get around a firefox bug on something else. The image and file insertion "works for me". :)
What browser were you using? Version? And how did you click the image / file buttons? Did you select something first? All the text? etc.
Yeah... I hate the IFRAME approach. But if you want to support most browsers it appears you have to do it. I find it messy and you lose the ability to inherit styles on the page (you have to reload individual stylesheets). I'm fine supporting "modern" browsers.
James
That's pretty sweet. Couple of questions
1) Is this something you wrote from scratch? I saw another editor along these lines recently somewhere ... aloha? but it was GPL and that makes it difficult for us.
2) I could really see integrating something like this into the core if it complimented tinyMCE well.. As in I put the page in edit mode i can still use tinyMCE to do bigger changes - perhaps we'd even make TInyMCE load bigger with more toolbars, etc.. But as you say if i just want to make a quick typo fix i don't need to bother with it..
Certainly food for thought.
My only concern with this is does it actually make the editing experience/learning curve MORE confusing for the new user.. "Wait, i put the page in EDIT MODE to add a form?!?? I never had to do that before... "
1) Is this something you wrote from scratch? I saw another editor along these lines recently somewhere ... aloha? but it was GPL and that makes it difficult for us.
2) I could really see integrating something like this into the core if it complimented tinyMCE well.. As in I put the page in edit mode i can still use tinyMCE to do bigger changes - perhaps we'd even make TInyMCE load bigger with more toolbars, etc.. But as you say if i just want to make a quick typo fix i don't need to bother with it..
Certainly food for thought.
My only concern with this is does it actually make the editing experience/learning curve MORE confusing for the new user.. "Wait, i put the page in EDIT MODE to add a form?!?? I never had to do that before... "
1. Yes. I wrote it from scratch. Though that wasn't in the original plan. I couldn't find an editor that I liked, that didn't use iframes, and that also could have the toolbar divorced from the editor itself. I'm using the rangy library for a few selection-related aspects, and that's MIT licensed.
2. I see the theory behind tinymce complementing this. On the other hand, my plan in the future is to, on the server side, lock down the submission from edit mode. I see this in the Apple sort of way -- the less options the end user has, the better. That means both for the "quick edit" of a typo, but for all editing all the time. In my experience with clients, you want them to have as little control as possible, and why bother giving them more control if they open the window? Dunno.... I'll be curious on how people actually use this.
3. Valid point. But I think that the idea of going into edit mode isn't too hard a leap for when "more complicated" stuff has to be edited. When you get into more advanced stuff, one has to go to the dashboard for some stuff that isn't purely administrative. Stuff like permissions can be done in both places... I think people figure that out. Plus, isn't that just as much of an argument for all blocks being edited in "live mode" instead? ;)
James
2. I see the theory behind tinymce complementing this. On the other hand, my plan in the future is to, on the server side, lock down the submission from edit mode. I see this in the Apple sort of way -- the less options the end user has, the better. That means both for the "quick edit" of a typo, but for all editing all the time. In my experience with clients, you want them to have as little control as possible, and why bother giving them more control if they open the window? Dunno.... I'll be curious on how people actually use this.
3. Valid point. But I think that the idea of going into edit mode isn't too hard a leap for when "more complicated" stuff has to be edited. When you get into more advanced stuff, one has to go to the dashboard for some stuff that isn't purely administrative. Stuff like permissions can be done in both places... I think people figure that out. Plus, isn't that just as much of an argument for all blocks being edited in "live mode" instead? ;)
James
Yeah I hear ya on #3.. certainly something worth ongoing consideration...
We're looking at cleaning up advanced permissions alot with the next
version of concrete5.
Ideally that would let you do everyting you're asking.
I do think its really counter intuitive to ONLY be able to edit text
this way vs. tinyMCE - if its in the core the possibility to use
both/either on the same content should be allowable through
permissions.
I also wonder if there couldn't be a way to drop the page in edit mode
for other blocks too.
The other potential issue i see with this is making too many versions.
Ive seen sites with THOUSANDS of versions of a page and that creates
performance issues. We'd want to do some cleanup with that.
I almost can imagine putting a page in edit mode to be someting you
only have to do when you want to make a whole set of changes as one
version, and using this more fluid approach for content, or even
blocks, if you really know its gonna be one change and you dont need
to put a comment on the version.. that type of thinking might make
sense to a casual user..
any rate - really great work, you've got me scratching my head at least. ;)
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
We're looking at cleaning up advanced permissions alot with the next
version of concrete5.
Ideally that would let you do everyting you're asking.
I do think its really counter intuitive to ONLY be able to edit text
this way vs. tinyMCE - if its in the core the possibility to use
both/either on the same content should be allowable through
permissions.
I also wonder if there couldn't be a way to drop the page in edit mode
for other blocks too.
The other potential issue i see with this is making too many versions.
Ive seen sites with THOUSANDS of versions of a page and that creates
performance issues. We'd want to do some cleanup with that.
I almost can imagine putting a page in edit mode to be someting you
only have to do when you want to make a whole set of changes as one
version, and using this more fluid approach for content, or even
blocks, if you really know its gonna be one change and you dont need
to put a comment on the version.. that type of thinking might make
sense to a casual user..
any rate - really great work, you've got me scratching my head at least. ;)
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
Thanks.
I agree that it is a bit counterintuitive if it's the only option.
I think some blocks are able to be edited pretty easily in a "pseudo-edit" mode, but others not so much. It depends, I guess, on the size of the column, and how much overhead is needed to edit. I think one of the key decisions I made regarding this was to have the floating toolbar where the content div remains a representation of what it'll eventually look like (though not static -- some interaction is done within it). So, for something like the forms block, the original content div would become the rough equivalent of the "preview" tab in edit mode. BUT... you could also use it to do certain things, like reordering the questions. Other things would require a toolbar. And that could get messy if you have 5 blocks in edit mode at the same time... But there are probably ways to handle it decently (like a toolbar that appears when a specific block is being edited).
As for versions, you're right. I just checked my demo, and there are 12 new versions in the last 1.5 hours. I think there are two ways this concept can be approached, maybe both:
1) Blocks like mine (or the default c5 functionality) would lump together all unapproved edits by the same person together into one version. I believe c5 currently creates a new version for each into-edit-mode, and my block mirrors that as much as possible. But maybe if they go back in within x hours (maybe as low as 10 minutes), it just modifies the last version. If you wait over x hours since the last edit, then you get 2 versions (1 old, 1 new) and if someone else makes an edit in the meantime, then you get 3 versions (1 for me, 1 for you, then 1 for me).
2) I believe MOSS does this -- create major versions each time something is approved and minors for unapproved changes. So you might have versions 1 -> 2 -> 2.1 -> 2.2 -> 3 -> 3.1 ... 3.15 -> 4. And then you can occasionally clean up all the minor versions. I don't know how important it is to be able to go back to an OLD version that was never even live.
James
I agree that it is a bit counterintuitive if it's the only option.
I think some blocks are able to be edited pretty easily in a "pseudo-edit" mode, but others not so much. It depends, I guess, on the size of the column, and how much overhead is needed to edit. I think one of the key decisions I made regarding this was to have the floating toolbar where the content div remains a representation of what it'll eventually look like (though not static -- some interaction is done within it). So, for something like the forms block, the original content div would become the rough equivalent of the "preview" tab in edit mode. BUT... you could also use it to do certain things, like reordering the questions. Other things would require a toolbar. And that could get messy if you have 5 blocks in edit mode at the same time... But there are probably ways to handle it decently (like a toolbar that appears when a specific block is being edited).
As for versions, you're right. I just checked my demo, and there are 12 new versions in the last 1.5 hours. I think there are two ways this concept can be approached, maybe both:
1) Blocks like mine (or the default c5 functionality) would lump together all unapproved edits by the same person together into one version. I believe c5 currently creates a new version for each into-edit-mode, and my block mirrors that as much as possible. But maybe if they go back in within x hours (maybe as low as 10 minutes), it just modifies the last version. If you wait over x hours since the last edit, then you get 2 versions (1 old, 1 new) and if someone else makes an edit in the meantime, then you get 3 versions (1 for me, 1 for you, then 1 for me).
2) I believe MOSS does this -- create major versions each time something is approved and minors for unapproved changes. So you might have versions 1 -> 2 -> 2.1 -> 2.2 -> 3 -> 3.1 ... 3.15 -> 4. And then you can occasionally clean up all the minor versions. I don't know how important it is to be able to go back to an OLD version that was never even live.
James
> lock down the submission
What exactly do you mean by that?
-Steve
What exactly do you mean by that?
-Steve
I think he means he wants to be able to setup editors who can ONLY change content this way..
Like the "new guy" up front.
Like the "new guy" up front.
Also, I want to make the style/formatting as limited (ie, white-list) as possible. Right now (as with most other editing tools), the submission code (ie, the code that saves to the database) is somewhat open. I'm less concerned about malicious hackers than dumb content editors ("CEOs") who have an affinity for marquees and bright colors. So, you could paste in something with a bunch of <span style="color: obnoxious-neon-green; font-face: cartoon-text"> and most editors will allow it and save that into the database because it's just a <span> (even if they filter out <blink> tags).
I see the main installers of this block as those people that have better taste and want to enforce it on people they don't believe do. ie, designers and their end-users. :) So I'm less concerned about XSS/etc and more concerned about somebody copy/pasting from Word or another site. And I think we need to prevent that as much as possible. And that's what I (ineloquently) meant by "locking down the submission".
(It's kinda similar to how I added the pilcrows after paragraphs when editing -- to make it easier for those that don't know the difference between a <p> and a <br> to begin to visualize that it at least exists.)
I see the main installers of this block as those people that have better taste and want to enforce it on people they don't believe do. ie, designers and their end-users. :) So I'm less concerned about XSS/etc and more concerned about somebody copy/pasting from Word or another site. And I think we need to prevent that as much as possible. And that's what I (ineloquently) meant by "locking down the submission".
(It's kinda similar to how I added the pilcrows after paragraphs when editing -- to make it easier for those that don't know the difference between a <p> and a <br> to begin to visualize that it at least exists.)
PS: And that's why I'm not so sure about the idea of having a more complex version in editing mode. Because if the designer has the ability to add <blink>, then it wouldn't make sense to disallow someone who has to edit it in the future. If I "lock the submission down" then I'd filter out the <blink> even though the user didn't add it in herself... and I'm fine with that principle -- that you don't have the need to edit something that you don't have the permission to create (insofar as styles). With CSS these days, I believe that you don't need to do anything more than what I've offered (b, u, i, ul, ol, h1, p, and, most importantly, arbitrary classes).
I dunno, I can imagine wanting to lock a client into ridged formatting but still be able to throw a page in edit mode and drop a table/iframe/funky style in when I want to.
w3c is cool and all, but sometimes sh!ts just gotta get done and rules were meant to be broken.
just strikes me as potentially very very annoying to be explaining to people "well you made THAT content with this editor, and THIS content with THAT editor.. sooo."
w3c is cool and all, but sometimes sh!ts just gotta get done and rules were meant to be broken.
just strikes me as potentially very very annoying to be explaining to people "well you made THAT content with this editor, and THIS content with THAT editor.. sooo."
btw: for anyone else as scatter brained as I am at this point, change this thread to be sorted by chronological up top and its WAAAY easier to read.
That's true... but there's a balancing act that allows that, and I'm not really sure what is best. Definitely something to consider.
I've done quick-and-dirty CMS's before where each element was a separate db table and edit. So the h2 would be editable separately from the body, and there'd be a table edited separately (probably based on a special list in the db). You'd also be able to select a few pictures, and that selection would be stored separate from the text. That was the way to go when you didn't have WYSWIG editors and allowed a lot of control over what the end-user could do.
On the other extreme, you have c5 and "general" content blocks where the header and tables and pictures and everything else can be put in one block, edited at the same time, and stored together in the db.
Tony's example requires individual elements (e.g headers) to be edited separately, and that has it's uses.
I'm not sure what's ideal.. though it probably isn't ideal that different elements have different editing processes (ie, pseudo edit mode and edit mode). Luckily, it's not my job to come up with the best solution ;).
James
I've done quick-and-dirty CMS's before where each element was a separate db table and edit. So the h2 would be editable separately from the body, and there'd be a table edited separately (probably based on a special list in the db). You'd also be able to select a few pictures, and that selection would be stored separate from the text. That was the way to go when you didn't have WYSWIG editors and allowed a lot of control over what the end-user could do.
On the other extreme, you have c5 and "general" content blocks where the header and tables and pictures and everything else can be put in one block, edited at the same time, and stored together in the db.
Tony's example requires individual elements (e.g headers) to be edited separately, and that has it's uses.
I'm not sure what's ideal.. though it probably isn't ideal that different elements have different editing processes (ie, pseudo edit mode and edit mode). Luckily, it's not my job to come up with the best solution ;).
James
> I'm not sure what's ideal.
I don't think there is any _one_ ideal solution - no one size fits all. Every client is different, and it seems like you understand your clients pretty well.
-Steve
I don't think there is any _one_ ideal solution - no one size fits all. Every client is different, and it seems like you understand your clients pretty well.
-Steve
> What browser were you using? Version?
> And how did you click the image / file buttons?
> Did you select something first? All the text?
Safari 5.0.3 on Mac. I think I tried both - i.e. with a selection and without, but it wasn't all text.
-Steve
> And how did you click the image / file buttons?
> Did you select something first? All the text?
Safari 5.0.3 on Mac. I think I tried both - i.e. with a selection and without, but it wasn't all text.
-Steve
Hi. Thanks. Safari had a bug (two, actually). I thought testing in chrome would cover both; I guess not.
Feel free to try again.
James
Feel free to try again.
James
I think that looks great. If you could package it up with a Dashboard settings page where buttons could be added/removed/tweaked from the editing bar, it would be a really amazing addon for c5.
Thanks.
See attached image. :) Control over all buttons, plus list of classes available and even filesets to be filtered.
Now it just needs to make it through the approval process; I have 2 other add-ons still in the queue, the first submitted over 2 weeks ago.....
James
See attached image. :) Control over all buttons, plus list of classes available and even filesets to be filtered.
Now it just needs to make it through the approval process; I have 2 other add-ons still in the queue, the first submitted over 2 weeks ago.....
James
For those that are following this thread, my package was just approved. You can download it fromhttps://www.concrete5.org/marketplace/addons/lerteco-simple-content/... .
As this hasn't been extensively tested in a number of environments by a number of users, I'm considering this to be a beta on the brink of final release. Please set your expectations accordingly.
As this hasn't been extensively tested in a number of environments by a number of users, I'm considering this to be a beta on the brink of final release. Please set your expectations accordingly.
awesome. this is a lot like I originally planned for my version (linked to a demo above), but I never got back to working on it. I'd love to see this kind of thing incorporated into the core though. It's so much quicker editing the page when you don't have to take it in and out of edit-mode all the time.
Sorry to resurrect this thread, but there was a lot of useful discussion and it relates potentially to the core of c5 as it develops.
Did anyone have any further thoughts on Tony's in-context editing and/or moving to another editor?
Did anyone have any further thoughts on Tony's in-context editing and/or moving to another editor?
Once I learned a bit about creating a custom profile for tinymce the editing experience changed dramatically.
I almost always take away a lot of the controls (color, font size, etc) and dictate what styles are available to the editor.
Look for abberdab's answer in this thread to get a start on how to do it:http://www.concrete5.org/community/forums/customizing_c5/tinymce-cu...
It's really amazing how much you can control the editing experience (doesn't help with the Word pasting, though!).
I almost always take away a lot of the controls (color, font size, etc) and dictate what styles are available to the editor.
Look for abberdab's answer in this thread to get a start on how to do it:http://www.concrete5.org/community/forums/customizing_c5/tinymce-cu...
It's really amazing how much you can control the editing experience (doesn't help with the Word pasting, though!).
I would really love to be able to control the TinyMCE buttons through a checkbox GUI. Would make for an add-on I would buy for all of my Concrete5 sites or a great core addition.
Edit: Just saw my response from a number of months ago from above. It seems I am still on the same thought pattern.
Kirk: There is a "paste from word" button in TinyMCE. You can see it via the "Office" layout (and maybe others too).
Edit: Just saw my response from a number of months ago from above. It seems I am still on the same thought pattern.
Kirk: There is a "paste from word" button in TinyMCE. You can see it via the "Office" layout (and maybe others too).
riotaj: thanks for the tip on the Word button. I do include that in my custom toolbars, but I can't make the client use it!
That's the mini-hell we all know and love.
Basically I just show it to them, and also show them about the "remove formatting" button (or as I like to call it "the magic eraser").
The checkbox GUI you suggest would need to be far more complex, as you may want to position where the buttons go. Updating the custom init code in the Dashboard is kind of a pain but worth the flexibility. There's so much you can do besides just turn buttons on/off.
That's the mini-hell we all know and love.
Basically I just show it to them, and also show them about the "remove formatting" button (or as I like to call it "the magic eraser").
The checkbox GUI you suggest would need to be far more complex, as you may want to position where the buttons go. Updating the custom init code in the Dashboard is kind of a pain but worth the flexibility. There's so much you can do besides just turn buttons on/off.
Well, for one thing, MCE editor seems VERY unpredictable. setting styles in the pulldown sometimes don't seem to stick when you hit enter (shift enter)
I've even seen the cursor jump up again, after an enter and switch of style, completely scrambling other styles.
I've even seen the cursor jump up again, after an enter and switch of style, completely scrambling other styles.
They use TinyMCE too!http://unifydemo.unitinteractive.com/unify/...
sorry I' haven't read the entire post :/ could happend that someone noticed that earlier
sorry I' haven't read the entire post :/ could happend that someone noticed that earlier
For what it's worth I can't stand TinyMCE even for myself (never mind clients).
I have been wanting to try out whizzywig editor (http://unverse.net/Whizzywig-web-based-rich-text-editor) but can't quite figure out how to integrate it into a C5 block yet.
Just my two cents for what it's worth.
Carlos
I have been wanting to try out whizzywig editor (http://unverse.net/Whizzywig-web-based-rich-text-editor) but can't quite figure out how to integrate it into a C5 block yet.
Just my two cents for what it's worth.
Carlos
of ALL the things I have heard from many many clients, content editing is NOT one of them.
This come across as a troll/promo post to me.
Just saying.