what could really help c5
Permalink 2 users found helpfulits 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.
C
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.
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.
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.
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.
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.
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..
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)
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.
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 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
The auto-resize image thing sounds kind of nice though. :)
> 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'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 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.
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?
> 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
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...
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 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).
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
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.
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?
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
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.
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.
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,
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. ;)
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 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.
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 :)
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.
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.
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?
> 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
http://nicedit.com/
Which appears to show up inline while in edit mode - a toolbar is put above all areas of editable text.
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.
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 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 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.
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?
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. ;)
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.
> "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 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.
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.
Chad
<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.
> 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
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
> 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
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.
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โฆ
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%;}
> 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
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
> 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
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.
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
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
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... "
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
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
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
What exactly do you mean by that?
-Steve
Like the "new guy" up front.
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.)
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."
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 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
> 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
Feel free to try again.
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
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.
Did anyone have any further thoughts on Tony's in-context editing and/or moving to another editor?
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!).
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).
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.
I've even seen the cursor jump up again, after an enter and switch of style, completely scrambling other styles.
sorry I' haven't read the entire post :/ could happend that someone noticed that earlier
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.