Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
Jason, I'm looking forward to installing your extension. I too like textile (though what drove me to it was the ability to add styles to the tags that it creates -- don't think markdown can handle that). That said, I too would like a markdown toolbar. Personally, I'd start with what Ryan Johnson built over at: http://livepipe.net/control/textarea But the big thing I'd love to see here is a coordinated effort to create a common toolbar that different filters plug into. This way it would offer: * A consistent experience across toolbars (same look, placement, and intent among buttons). This is also why I thought the filter selection might, itself, be made part of the toolbar. * Button(s) to let you add simple Radius tags into the content (so users don't need to know tags either yet can learn by seeing what gets inserted). * Other common buttons (maximize-textarea-to-fit-window anyone?) -Chris Jason Garber wrote: I have a little different take: I really like Markdown for plain text documents that are to be read as plain text and might be converted to HTML, but Textile works better for me when I'm using it as a shortcut to HTML (and it won't be published plain-text). I tried Markdown before I'd ever heard of Textile, but these things got to me: Links: I find it easier to write "links this way":http://radiantcms.org rather than [this way](http://radiantcms.org) when you're writing them all day, every day. Guess it's just personal preference. Maybe it's because quotes and a colon are easier to type than square brackets and parentheses? Numbered lists: I'm a little OCD, so I found myself re-numbering Markdown numbered lists when I added an item in the middle, even though it technically doesn't matter. Textile's use of the number sign is intuitive and saves me trips to the therapist. :-) Textile supports nested lists and, in RedCloth at least, definition lists, but I haven't found a way to do either in Markdown. Blockquotes: Here again, you only technically need one > at the beginning, but there's plenty of room to be obsessive and spend time fixing hard-wrapped blockquotes. Code blocks: Yeah right, like I really want to indent every line of my code by four spaces! Headings: I don't want to have to count how many times I use the pound sign. h4 is less ambiguous than , though My heading looks a lot prettier (esp. when the pound signs are balanced!). Okay, so this is turning into an obsessive-compulsive confession! Now, I don't mean to start a filter war! Just had to defend my choice. I'm glad that Radiant offers both and I wish that I had liked Markdown better than Textile initially because when I started using them a couple years ago, the Ruby Markdown libraries were a lot better than the Textile one! I'd love to see a toolbar for Markdown. I had dreamed of having the same buttons always be on the toolbar and then the output change depending on the filter currently selected (e.g. h2., ##, or ). Unfortunately, textile_editor is meeting my needs, so I don't have time or motivation to make that happen, but I'd welcome a fork that would! Jason On Nov 20, 2008, at 10:21 AM, Simon Rönnqvist wrote: Hi! Personally I feel that Markdown is easier to learn for noobs, and would really have liked to see your extension done with Markdown. However, maybe your toolbar makes the reduces the differences in ease of use between Markdown and Textile. Maybe even Textile is better in conection to buttons, since you can have a H2-button produce h2.Something, but what would you call a button that produces ##Something? Ok, both could be called the more explanatory "Heading 2", but you get my point... in general the button name could look more like the textile code that it produces, than it could look like to markdown code that's produced... which could ease up the learning process, when learning to actually write the code. And the rest of your implementation sounds really promising, I'll definitely give it a shot. Thanx! ;) cheers, Simon On Nov 20, 2008, at 15:50 , Jason Garber wrote: I'm catching up to this interesting thread a couple days late, but I can't believe no one's mentioned my textile_editor extension yet! I'm hurt! (jk!) It would have helped if I'd have announced it to the list when I released it in September, huh? :-) [ANN] radiant-textile_editor-extension makes Radiant really easy to use for non-technical content editors! We have a lot (50-ish?) of technology-impared people working on our university website. We haven't rolled the CMS out to all of them yet but so far in my testing I've found that the Textile editor toolbar helps them a bunch. It seems silly because pushing the H1 button inserts h1. and pressing B adds asterisks, but it works because it overcomes their fear and uncertainty about Textile. They pretty quickly get to the point where it's faster to just type
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
Simon Rönnqvist said the following on 11/20/2008 02:48 PM: > OK, sounds like you did a pretty thorough comparison of the two. > Personally I just picked Markdown cause it seemed easier to teach my > clients doing ## than h2. And also a few other things seemed more > simple to learn, and all of the tags that I needed to get done were > doable using Markdown, even definition lists using Markdown Extra > http://michelf.com/projects/php-markdown/extra/ > ...however that was using Drupal (which has Markdown Extra). I came to all this from the world of Wikis - TWiki MoinMoin and others. Completely different markup and facilities. And lots of entrenchment and 'mark-up wars'. I'm comfortable with either but seem to use Textile for composition and Markdown for posting in from e-mail. If you think about it, non-html type email ends up suing things like underlining for 'titles' ad starts or hashes lists and simple * and _. Or, and > for quotes. So posting email in is a natural. That's when I'm not doing pretty involved stuff in raw html! -- Ignorance is never out of style. It was in fashion yesterday, it is the rage today, and it will set the pace tomorrow. -- Franklin K. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
OK, sounds like you did a pretty thorough comparison of the two. Personally I just picked Markdown cause it seemed easier to teach my clients doing ## than h2. And also a few other things seemed more simple to learn, and all of the tags that I needed to get done were doable using Markdown, even definition lists using Markdown Extra http://michelf.com/projects/php-markdown/extra/ ...however that was using Drupal (which has Markdown Extra). That being said I hate you for converting from Markdown to Textile, umm... sorry... no filter war. :) No, actually after looking at your extension I can confirm what I just said in the last mail, that your extensions are probably reason enough for me to give Textile a try. (Thanks for the hint on getting 'em installed, I'm a bit of a Radiant noob.) cheers, Simon On Nov 20, 2008, at 18:34 , Jason Garber wrote: I have a little different take: I really like Markdown for plain text documents that are to be read as plain text and might be converted to HTML, but Textile works better for me when I'm using it as a shortcut to HTML (and it won't be published plain-text). I tried Markdown before I'd ever heard of Textile, but these things got to me: Links: I find it easier to write "links this way":http://radiantcms.org rather than [this way](http://radiantcms.org) when you're writing them all day, every day. Guess it's just personal preference. Maybe it's because quotes and a colon are easier to type than square brackets and parentheses? Numbered lists: I'm a little OCD, so I found myself re-numbering Markdown numbered lists when I added an item in the middle, even though it technically doesn't matter. Textile's use of the number sign is intuitive and saves me trips to the therapist. :-) Textile supports nested lists and, in RedCloth at least, definition lists, but I haven't found a way to do either in Markdown. Blockquotes: Here again, you only technically need one > at the beginning, but there's plenty of room to be obsessive and spend time fixing hard-wrapped blockquotes. Code blocks: Yeah right, like I really want to indent every line of my code by four spaces! Headings: I don't want to have to count how many times I use the pound sign. h4 is less ambiguous than , though My heading looks a lot prettier (esp. when the pound signs are balanced!). Okay, so this is turning into an obsessive-compulsive confession! Now, I don't mean to start a filter war! Just had to defend my choice. I'm glad that Radiant offers both and I wish that I had liked Markdown better than Textile initially because when I started using them a couple years ago, the Ruby Markdown libraries were a lot better than the Textile one! I'd love to see a toolbar for Markdown. I had dreamed of having the same buttons always be on the toolbar and then the output change depending on the filter currently selected (e.g. h2., ##, or ). Unfortunately, textile_editor is meeting my needs, so I don't have time or motivation to make that happen, but I'd welcome a fork that would! Jason On Nov 20, 2008, at 10:21 AM, Simon Rönnqvist wrote: Hi! Personally I feel that Markdown is easier to learn for noobs, and would really have liked to see your extension done with Markdown. However, maybe your toolbar makes the reduces the differences in ease of use between Markdown and Textile. Maybe even Textile is better in conection to buttons, since you can have a H2-button produce h2.Something, but what would you call a button that produces ##Something? Ok, both could be called the more explanatory "Heading 2", but you get my point... in general the button name could look more like the textile code that it produces, than it could look like to markdown code that's produced... which could ease up the learning process, when learning to actually write the code. And the rest of your implementation sounds really promising, I'll definitely give it a shot. Thanx! ;) cheers, Simon On Nov 20, 2008, at 15:50 , Jason Garber wrote: I'm catching up to this interesting thread a couple days late, but I can't believe no one's mentioned my textile_editor extension yet! I'm hurt! (jk!) It would have helped if I'd have announced it to the list when I released it in September, huh? :-) [ANN] radiant-textile_editor-extension makes Radiant really easy to use for non-technical content editors! We have a lot (50-ish?) of technology-impared people working on our university website. We haven't rolled the CMS out to all of them yet but so far in my testing I've found that the Textile editor toolbar helps them a bunch. It seems silly because pushing the H1 button inserts h1. and pressing B adds asterisks, but it works because it overcomes their fear and uncertainty about Textile. They pretty quickly get to the point where it's faster to just type h3. than to click the button, but f
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
Jason Garber said the following on 11/20/2008 10:38 AM: > Anton, > I wasn't sure what you meant about people your age, so I looked back at > what I sent. I added 50-ish to quantify "a lot," not to describe the > age of the technically-challenged users. Sorry for the > misunderstanding! Life's like that! :-) -- My definition of a free society is a society where it is safe to be unpopular. Adlai E. Stevenson Jr., Speech in Detroit, 7 Oct. 1952 ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
Perhaps you need to do a rake radiant:extensions:update_all? This happens automatically when you install extensions via ./script/ extension install extension_name, but if you installed them by just copying the files in, you may have missed updating the instance with images, javascripts, and stylesheets. Good luck! On Nov 20, 2008, at 10:51 AM, Simon Rönnqvist wrote: Hi! I installed your extension along with the other extensions that you made + page_attachments. I ran rake migrate:db:extensions and everything seemed to go fine... I also saw them show up under Extensions in Radiant. However, no toolbar ever showed up for me, and below the content field I can see the green plus and "Attachments (0)", but nothing happeneds when i click the plus-symbol. What did I do wrong, or miss? cheers, Simon On Nov 20, 2008, at 15:50 , Jason Garber wrote: I'm catching up to this interesting thread a couple days late, but I can't believe no one's mentioned my textile_editor extension yet! I'm hurt! (jk!) It would have helped if I'd have announced it to the list when I released it in September, huh? :-) [ANN] radiant-textile_editor-extension makes Radiant really easy to use for non-technical content editors! We have a lot (50-ish?) of technology-impared people working on our university website. We haven't rolled the CMS out to all of them yet but so far in my testing I've found that the Textile editor toolbar helps them a bunch. It seems silly because pushing the H1 button inserts h1. and pressing B adds asterisks, but it works because it overcomes their fear and uncertainty about Textile. They pretty quickly get to the point where it's faster to just type h3. than to click the button, but for getting over the initial hump of staring at a blank textbox, it's a huge psychological boost! The part of the toolbar I find myself using all the time is the link and image buttons. The way I designed it, not only can you add Textile links and images, but also enkoded email links, attached images, and attached files. Speaking of attachments, the concept is genius for file management. Buckets and asset libraries and all that are too confusing for my users (I tried paperclipped for a while), but they're used to attaching files in webmail, so the page_attachments extension works out great. I use the page_attachments_xsendfile extension to make the attached file available at a friendly URL (the page's URL + filename). That seems to match people's expectations better. You just tell them they can use an attachment on that page or any page under it and they get it. I'm a strong believer in the non-technical user being able to see what's going on. Even if they can't write tags, when they encounter them they'll know what's going on and are less likely to mess up Radius or HTML tags than if they're hidden behind a WYSIWYG editor. Training up front is really the key—and preparing their expectations. So you say, "Textile is going to make your life a whole lot easier. Here are a few things it does and here's a toolbar in case you forget. HTML tags [Radius tags in reality] are mostly for the web team. You're not expected to know how to use them, but I'm glad to show you a few so you know what they do." If you're using Textile, make sure you're using version >= 4.0. A lot of the hate on RedCloth was rooted in how buggy it was for a few years. You'll need the redcloth4 extension to make it work in Radiant 0.9.6. Jason On Nov 18, 2008, at 3:08 PM, Chris Parrish wrote: 1. I think the textareas need to come with a toolbar above them (page parts, snippets, layouts). These toolbars would be filter specific. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
I have a little different take: I really like Markdown for plain text documents that are to be read as plain text and might be converted to HTML, but Textile works better for me when I'm using it as a shortcut to HTML (and it won't be published plain-text). I tried Markdown before I'd ever heard of Textile, but these things got to me: Links: I find it easier to write "links this way":http:// radiantcms.org rather than [this way](http://radiantcms.org) when you're writing them all day, every day. Guess it's just personal preference. Maybe it's because quotes and a colon are easier to type than square brackets and parentheses? Numbered lists: I'm a little OCD, so I found myself re-numbering Markdown numbered lists when I added an item in the middle, even though it technically doesn't matter. Textile's use of the number sign is intuitive and saves me trips to the therapist. :-) Textile supports nested lists and, in RedCloth at least, definition lists, but I haven't found a way to do either in Markdown. Blockquotes: Here again, you only technically need one > at the beginning, but there's plenty of room to be obsessive and spend time fixing hard-wrapped blockquotes. Code blocks: Yeah right, like I really want to indent every line of my code by four spaces! Headings: I don't want to have to count how many times I use the pound sign. h4 is less ambiguous than , though My heading looks a lot prettier (esp. when the pound signs are balanced!). Okay, so this is turning into an obsessive-compulsive confession! Now, I don't mean to start a filter war! Just had to defend my choice. I'm glad that Radiant offers both and I wish that I had liked Markdown better than Textile initially because when I started using them a couple years ago, the Ruby Markdown libraries were a lot better than the Textile one! I'd love to see a toolbar for Markdown. I had dreamed of having the same buttons always be on the toolbar and then the output change depending on the filter currently selected (e.g. h2., ##, or ). Unfortunately, textile_editor is meeting my needs, so I don't have time or motivation to make that happen, but I'd welcome a fork that would! Jason On Nov 20, 2008, at 10:21 AM, Simon Rönnqvist wrote: Hi! Personally I feel that Markdown is easier to learn for noobs, and would really have liked to see your extension done with Markdown. However, maybe your toolbar makes the reduces the differences in ease of use between Markdown and Textile. Maybe even Textile is better in conection to buttons, since you can have a H2-button produce h2.Something, but what would you call a button that produces ##Something? Ok, both could be called the more explanatory "Heading 2", but you get my point... in general the button name could look more like the textile code that it produces, than it could look like to markdown code that's produced... which could ease up the learning process, when learning to actually write the code. And the rest of your implementation sounds really promising, I'll definitely give it a shot. Thanx! ;) cheers, Simon On Nov 20, 2008, at 15:50 , Jason Garber wrote: I'm catching up to this interesting thread a couple days late, but I can't believe no one's mentioned my textile_editor extension yet! I'm hurt! (jk!) It would have helped if I'd have announced it to the list when I released it in September, huh? :-) [ANN] radiant-textile_editor-extension makes Radiant really easy to use for non-technical content editors! We have a lot (50-ish?) of technology-impared people working on our university website. We haven't rolled the CMS out to all of them yet but so far in my testing I've found that the Textile editor toolbar helps them a bunch. It seems silly because pushing the H1 button inserts h1. and pressing B adds asterisks, but it works because it overcomes their fear and uncertainty about Textile. They pretty quickly get to the point where it's faster to just type h3. than to click the button, but for getting over the initial hump of staring at a blank textbox, it's a huge psychological boost! The part of the toolbar I find myself using all the time is the link and image buttons. The way I designed it, not only can you add Textile links and images, but also enkoded email links, attached images, and attached files. Speaking of attachments, the concept is genius for file management. Buckets and asset libraries and all that are too confusing for my users (I tried paperclipped for a while), but they're used to attaching files in webmail, so the page_attachments extension works out great. I use the page_attachments_xsendfile extension to make the attached file available at a friendly URL (the page's URL + filename). That seems to match people's expectations better. You just tell them they can use an attachment on that page or any page unde
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
Hi! I installed your extension along with the other extensions that you made + page_attachments. I ran rake migrate:db:extensions and everything seemed to go fine... I also saw them show up under Extensions in Radiant. However, no toolbar ever showed up for me, and below the content field I can see the green plus and "Attachments (0)", but nothing happeneds when i click the plus-symbol. What did I do wrong, or miss? cheers, Simon On Nov 20, 2008, at 15:50 , Jason Garber wrote: I'm catching up to this interesting thread a couple days late, but I can't believe no one's mentioned my textile_editor extension yet! I'm hurt! (jk!) It would have helped if I'd have announced it to the list when I released it in September, huh? :-) [ANN] radiant-textile_editor-extension makes Radiant really easy to use for non-technical content editors! We have a lot (50-ish?) of technology-impared people working on our university website. We haven't rolled the CMS out to all of them yet but so far in my testing I've found that the Textile editor toolbar helps them a bunch. It seems silly because pushing the H1 button inserts h1. and pressing B adds asterisks, but it works because it overcomes their fear and uncertainty about Textile. They pretty quickly get to the point where it's faster to just type h3. than to click the button, but for getting over the initial hump of staring at a blank textbox, it's a huge psychological boost! The part of the toolbar I find myself using all the time is the link and image buttons. The way I designed it, not only can you add Textile links and images, but also enkoded email links, attached images, and attached files. Speaking of attachments, the concept is genius for file management. Buckets and asset libraries and all that are too confusing for my users (I tried paperclipped for a while), but they're used to attaching files in webmail, so the page_attachments extension works out great. I use the page_attachments_xsendfile extension to make the attached file available at a friendly URL (the page's URL + filename). That seems to match people's expectations better. You just tell them they can use an attachment on that page or any page under it and they get it. I'm a strong believer in the non-technical user being able to see what's going on. Even if they can't write tags, when they encounter them they'll know what's going on and are less likely to mess up Radius or HTML tags than if they're hidden behind a WYSIWYG editor. Training up front is really the key—and preparing their expectations. So you say, "Textile is going to make your life a whole lot easier. Here are a few things it does and here's a toolbar in case you forget. HTML tags [Radius tags in reality] are mostly for the web team. You're not expected to know how to use them, but I'm glad to show you a few so you know what they do." If you're using Textile, make sure you're using version >= 4.0. A lot of the hate on RedCloth was rooted in how buggy it was for a few years. You'll need the redcloth4 extension to make it work in Radiant 0.9.6. Jason On Nov 18, 2008, at 3:08 PM, Chris Parrish wrote: 1. I think the textareas need to come with a toolbar above them (page parts, snippets, layouts). These toolbars would be filter specific. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
Anton, I wasn't sure what you meant about people your age, so I looked back at what I sent. I added 50-ish to quantify "a lot," not to describe the age of the technically-challenged users. Sorry for the misunderstanding! We have about 50 "curators" who update our web site. Most of them are administrative assistants, though some are department chairs with PhDs or even departmental marketing people. They have varying levels of writing skill and technical aptitude, with little correlation to their age. Web publishing is inherently complex. You mention relevant content and grammar. Also, writing for the web (brevity, headlines, photo captions, SEO), layout, and design—it's a tricky business. To manage the inherent complexity, we have to hire well and train well. My aim is just to reduce the incidental complexity for them (and for me). Web publishing should be as simple as possible and no simpler. :-) Jason On Nov 20, 2008, at 9:38 AM, Anton J Aylward wrote: Jason Garber said the following on 11/20/2008 08:50 AM: [...] [ANN] radiant-textile_editor-extension makes Radiant really easy to use for non-technical content editors! [...] If you're using Textile, make sure you're using version >= 4.0. A lot of the hate on RedCloth was rooted in how buggy it was for a few years. You'll need the redcloth4 extension to make it work in Radiant 0.9.6. Jason I'll ignore your comments about people my age since I'm battling trying to get openSUSE to recognise & work with Passenger (thought this isn't reason to give up and go back to Mandriva) and simply ask you to supply details on all of the above, references to github (etc) Some of the younger people at associations & clubs whose sites I have put up on hosting services seem daunted by the idea of editing in a CMS, whereas the old timers just see it as another web interface, no different from gmail or whatever. YMMV. The older people also seem better at coming up with relevant (aka non-gossipy) content and their grammar is better :-) But lowering the threshold of access is always a good thing! -- Results! Why, man, I have gotten a lot of results. I know several thousand things that won't work. Thomas A. Edison ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
Hi! Personally I feel that Markdown is easier to learn for noobs, and would really have liked to see your extension done with Markdown. However, maybe your toolbar makes the reduces the differences in ease of use between Markdown and Textile. Maybe even Textile is better in conection to buttons, since you can have a H2-button produce h2.Something, but what would you call a button that produces ##Something? Ok, both could be called the more explanatory "Heading 2", but you get my point... in general the button name could look more like the textile code that it produces, than it could look like to markdown code that's produced... which could ease up the learning process, when learning to actually write the code. And the rest of your implementation sounds really promising, I'll definitely give it a shot. Thanx! ;) cheers, Simon On Nov 20, 2008, at 15:50 , Jason Garber wrote: I'm catching up to this interesting thread a couple days late, but I can't believe no one's mentioned my textile_editor extension yet! I'm hurt! (jk!) It would have helped if I'd have announced it to the list when I released it in September, huh? :-) [ANN] radiant-textile_editor-extension makes Radiant really easy to use for non-technical content editors! We have a lot (50-ish?) of technology-impared people working on our university website. We haven't rolled the CMS out to all of them yet but so far in my testing I've found that the Textile editor toolbar helps them a bunch. It seems silly because pushing the H1 button inserts h1. and pressing B adds asterisks, but it works because it overcomes their fear and uncertainty about Textile. They pretty quickly get to the point where it's faster to just type h3. than to click the button, but for getting over the initial hump of staring at a blank textbox, it's a huge psychological boost! The part of the toolbar I find myself using all the time is the link and image buttons. The way I designed it, not only can you add Textile links and images, but also enkoded email links, attached images, and attached files. Speaking of attachments, the concept is genius for file management. Buckets and asset libraries and all that are too confusing for my users (I tried paperclipped for a while), but they're used to attaching files in webmail, so the page_attachments extension works out great. I use the page_attachments_xsendfile extension to make the attached file available at a friendly URL (the page's URL + filename). That seems to match people's expectations better. You just tell them they can use an attachment on that page or any page under it and they get it. I'm a strong believer in the non-technical user being able to see what's going on. Even if they can't write tags, when they encounter them they'll know what's going on and are less likely to mess up Radius or HTML tags than if they're hidden behind a WYSIWYG editor. Training up front is really the key—and preparing their expectations. So you say, "Textile is going to make your life a whole lot easier. Here are a few things it does and here's a toolbar in case you forget. HTML tags [Radius tags in reality] are mostly for the web team. You're not expected to know how to use them, but I'm glad to show you a few so you know what they do." If you're using Textile, make sure you're using version >= 4.0. A lot of the hate on RedCloth was rooted in how buggy it was for a few years. You'll need the redcloth4 extension to make it work in Radiant 0.9.6. Jason On Nov 18, 2008, at 3:08 PM, Chris Parrish wrote: 1. I think the textareas need to come with a toolbar above them (page parts, snippets, layouts). These toolbars would be filter specific. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
Jason Garber said the following on 11/20/2008 08:50 AM: > [...] > > [ANN] radiant-textile_editor-extension makes Radiant really easy to > use for non-technical content editors! > > [...] > > If you're using Textile, make sure you're using version >= 4.0. A > lot of the hate on RedCloth was rooted in how buggy it was for a few > years. You'll need the redcloth4 extension to make it work in > Radiant 0.9.6. > > Jason I'll ignore your comments about people my age since I'm battling trying to get openSUSE to recognise & work with Passenger (thought this isn't reason to give up and go back to Mandriva) and simply ask you to supply details on all of the above, references to github (etc) Some of the younger people at associations & clubs whose sites I have put up on hosting services seem daunted by the idea of editing in a CMS, whereas the old timers just see it as another web interface, no different from gmail or whatever. YMMV. The older people also seem better at coming up with relevant (aka non-gossipy) content and their grammar is better :-) But lowering the threshold of access is always a good thing! -- Results! Why, man, I have gotten a lot of results. I know several thousand things that won't work. Thomas A. Edison ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors? (OT: About "tight" TinyMCE configuration)
Hi! Just a short note about note about how you can make TinyMCE into something pretty close to WymEditor: As I mentioned earlier I've tried a "tightly configured" TinyMCE, by that I mean that I made available only the few things that I felt that my customer needed... and those pieces of functionality were also rather well behaved. That being said, the customer of course managed to make the page look inconsistent, even though the code remained valid. (The same kind of problems are discussed in my thesis.) Up until now I haven't really found a flexible solution that wouldn't require you to go cleaning up a bit after the customer, at least in the beginning. (I also made the bold-button produce instead of and the italic-button instead of , which some would argue is not quite accurate... but in practise I think it more often produces sensible results that way, since in most cases the semantics will be OK then.) Here's the configuration that I used: function mceToggle(id, linkid) { element = document.getElementById(id); link = document.getElementById(linkid); img_assist = document.getElementById('img_assist-link-'+ id); if (tinyMCE.getEditorId(element.id) == null) { tinyMCE.addMCEControl(element, element.id); element.togg = 'on'; link.innerHTML = 'disable rich-text'; link.href = "javascript:mceToggle('" +id+ "', '" +linkid+ "');"; if (img_assist) img_assist.innerHTML = ''; link.blur(); } else { tinyMCE.removeMCEControl(tinyMCE.getEditorId(element.id)); element.togg = 'off'; link.innerHTML = 'enable rich-text'; link.href = "javascript:mceToggle('" +id+ "', '" +linkid+ "');"; if (img_assist) img_assist.innerHTML = img_assist_default_link; link.blur(); } } tinyMCE.init({ mode : "exact", theme : "advanced", relative_urls : false, document_base_url : "/", language : "en", safari_warning : false, entity_encoding : "raw", verify_html : true, preformatted : false, convert_fonts_to_spans : true, remove_linebreaks : true, apply_source_formatting : true, theme_advanced_resize_horizontal : false, theme_advanced_resizing_use_cookie : false, plugins : "advimage,contextmenu,fullscreen", theme_advanced_toolbar_location : "top", theme_advanced_toolbar_align : "center", theme_advanced_path_location : "bottom", theme_advanced_resizing : true, theme_advanced_blockformats : "h2,h3,p",theme_advanced_buttons1 : "undo ,redo ,separator ,formatselect ,bold ,italic ,numlist,bullist,separator,link,unlink,separator,fullscreen,code",theme_advanced_buttons2 : "", theme_advanced_buttons3 : "",extended_valid_elements : "img[class|src|alt|title|hspace|vspace| width|height|align|onmouseover|onmouseout|name],strong/b,em/i",theme_advanced_styles : "", elements : "updatedfile" }); cheers, Simon On Nov 19, 2008, at 20:21 , Casper Fabricius wrote: I am happy my frustrations resulted in some discussion and good ideas. The ideas for extensions for a scratch pad, filter toolbars and som WymEditor + paperclipped would all be highly usable to me, but I don't have the time to build any of them right now. I have used TinyMCE filter for some projects, but it has - amongst other things - resulted in me having to say to the customer: "No, you have to let me edit the frontpage, if you edit it, it will get messed up" (Because TinyMCE has a habit of messing HTML up). But WymEditor might be more clean at that, so I think I'll try and use it. The template extension can do many of the things you mention, such as providing custom forms for different templates, and allowing the user to select the appropriate template when clicking "Add Child". I'll let you know if I make any interesting discoveries along the way. Med venlig hilsen / Best regards, Casper Fabricius http://casperfabricius.com On 19/11/2008, at 10.19, Simon Rönnqvist wrote: Hi! Yes some WymEditor + paperclipped combination could be really cool. I've never really used WymEditor for any of my clients.. but I've tried both Markdown and a tightly configured TinyMCE (which would be pretty close to WymEditor). With Markdown I've seen that the content remains largely unstyled, the client eg. just used UPPERCASE-letters for headings and so on... maybe a Markdown- toolbar would help stimulate the usage of Markdown-code? With the TinyMCE solution again stuff got marked up a bit inconsistently, and often using for some headings, even though it didn't cause quite the mess that a normal 'liberal' WYSIWYG would have. My guess is that using WymEditor would be a good way to give your customer a way to try and express what she's lookin
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
I'm catching up to this interesting thread a couple days late, but I can't believe no one's mentioned my textile_editor extension yet! I'm hurt! (jk!) It would have helped if I'd have announced it to the list when I released it in September, huh? :-) [ANN] radiant-textile_editor-extension makes Radiant really easy to use for non-technical content editors! We have a lot (50-ish?) of technology-impared people working on our university website. We haven't rolled the CMS out to all of them yet but so far in my testing I've found that the Textile editor toolbar helps them a bunch. It seems silly because pushing the H1 button inserts h1. and pressing B adds asterisks, but it works because it overcomes their fear and uncertainty about Textile. They pretty quickly get to the point where it's faster to just type h3. than to click the button, but for getting over the initial hump of staring at a blank textbox, it's a huge psychological boost! The part of the toolbar I find myself using all the time is the link and image buttons. The way I designed it, not only can you add Textile links and images, but also enkoded email links, attached images, and attached files. Speaking of attachments, the concept is genius for file management. Buckets and asset libraries and all that are too confusing for my users (I tried paperclipped for a while), but they're used to attaching files in webmail, so the page_attachments extension works out great. I use the page_attachments_xsendfile extension to make the attached file available at a friendly URL (the page's URL + filename). That seems to match people's expectations better. You just tell them they can use an attachment on that page or any page under it and they get it. I'm a strong believer in the non-technical user being able to see what's going on. Even if they can't write tags, when they encounter them they'll know what's going on and are less likely to mess up Radius or HTML tags than if they're hidden behind a WYSIWYG editor. Training up front is really the key—and preparing their expectations. So you say, "Textile is going to make your life a whole lot easier. Here are a few things it does and here's a toolbar in case you forget. HTML tags [Radius tags in reality] are mostly for the web team. You're not expected to know how to use them, but I'm glad to show you a few so you know what they do." If you're using Textile, make sure you're using version >= 4.0. A lot of the hate on RedCloth was rooted in how buggy it was for a few years. You'll need the redcloth4 extension to make it work in Radiant 0.9.6. Jason On Nov 18, 2008, at 3:08 PM, Chris Parrish wrote: 1. I think the textareas need to come with a toolbar above them (page parts, snippets, layouts). These toolbars would be filter specific. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
I am happy my frustrations resulted in some discussion and good ideas. The ideas for extensions for a scratch pad, filter toolbars and som WymEditor + paperclipped would all be highly usable to me, but I don't have the time to build any of them right now. I have used TinyMCE filter for some projects, but it has - amongst other things - resulted in me having to say to the customer: "No, you have to let me edit the frontpage, if you edit it, it will get messed up" (Because TinyMCE has a habit of messing HTML up). But WymEditor might be more clean at that, so I think I'll try and use it. The template extension can do many of the things you mention, such as providing custom forms for different templates, and allowing the user to select the appropriate template when clicking "Add Child". I'll let you know if I make any interesting discoveries along the way. Med venlig hilsen / Best regards, Casper Fabricius http://casperfabricius.com On 19/11/2008, at 10.19, Simon Rönnqvist wrote: Hi! Yes some WymEditor + paperclipped combination could be really cool. I've never really used WymEditor for any of my clients.. but I've tried both Markdown and a tightly configured TinyMCE (which would be pretty close to WymEditor). With Markdown I've seen that the content remains largely unstyled, the client eg. just used UPPERCASE-letters for headings and so on... maybe a Markdown-toolbar would help stimulate the usage of Markdown-code? With the TinyMCE solution again stuff got marked up a bit inconsistently, and often using for some headings, even though it didn't cause quite the mess that a normal 'liberal' WYSIWYG would have. My guess is that using WymEditor would be a good way to give your customer a way to try and express what she's looking for, but chances are that you'll have to go in and clean up after her a few times... but along with that you could also try to agree with her on certain practices in the future, to retain consistency. I've been searching for the perfect solution for quite some time, but I've begun thinking that this last step of cleaning up and educating can't really be avoided if you want perfect results... we can just try to minimize this last task. Markdown+toolbar could also be something to try out, but I fear it might still be considered a bit too intimidating (and Textile I find even more intimidating). Another thing that I've been thinking that could be suitable for some cases (but I haven't tried out) is in-place editing... but I don't know how well that'd fit into Radiant. And yes forms (using your own plug-in) or splitting content into many page parts could definitely also in some cases be the right solution... but in cases where we want to allow more flexibility, to allow the customer to structure their content more freely... we're probably better off going with some WymEditor-like solution + cleaning up and education. Apart from the actual editing of content, it'd be really cool to find and easy way to hide some stuff in Radiant from the customer. Eg. some things such as the CSS and RSS things, and sometimes some page-parts. And maybe in some cases even the popup menus: layout, page type, status and filter. cheers, Simon PS. I begun the search for the perfect solution to this in my thesis, if anyone's interested: http://simon.fi/en/thesis On Nov 18, 2008, at 20:46 , Mohit Sindhwani wrote: Casper Fabricius wrote: However, I have a client whose content editor is very frustrated with the system. She can only just tolerate using Markup, and she refuses to write any kind of HTML - Radius tags falls into this category from her point of view. According to her, a proper CMS would hide all this "technical stuff" and provide custom forms for all types of content. Casper, my "solution" would be to find a slightly more technical client :P No, I'm joking (of course!) Here's what I would recommend: 1. First, factor out as far as possible so that whatever is not page specific is in snippets. 2. If all she needs is a few styles of pages, I would create different page types or layouts. 3. Then tell her that the different parts that she wants need to go into different page parts. It would be cool if you could modify the "Add Child" behavior to allow you to select the kind of child page you want and then give you a blank page with all the different tabs created (page parts)... or it could be done with a bit of Javascript that detects when you change the Layout/ page and automatically adds in the different page parts? It could even be a special drop down box next to the Page Type that triggers the actions? 4. The problem: she still needs to use textile for some of the things, such as images. I'm not sure if the Textile Helper will help? It's been a while since I looked at it, but there's a hello world guide on my blog: http://notepad.onghu.com/2007/3/28/using-tex
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
Hi! Yes some WymEditor + paperclipped combination could be really cool. I've never really used WymEditor for any of my clients.. but I've tried both Markdown and a tightly configured TinyMCE (which would be pretty close to WymEditor). With Markdown I've seen that the content remains largely unstyled, the client eg. just used UPPERCASE-letters for headings and so on... maybe a Markdown-toolbar would help stimulate the usage of Markdown-code? With the TinyMCE solution again stuff got marked up a bit inconsistently, and often using for some headings, even though it didn't cause quite the mess that a normal 'liberal' WYSIWYG would have. My guess is that using WymEditor would be a good way to give your customer a way to try and express what she's looking for, but chances are that you'll have to go in and clean up after her a few times... but along with that you could also try to agree with her on certain practices in the future, to retain consistency. I've been searching for the perfect solution for quite some time, but I've begun thinking that this last step of cleaning up and educating can't really be avoided if you want perfect results... we can just try to minimize this last task. Markdown+toolbar could also be something to try out, but I fear it might still be considered a bit too intimidating (and Textile I find even more intimidating). Another thing that I've been thinking that could be suitable for some cases (but I haven't tried out) is in-place editing... but I don't know how well that'd fit into Radiant. And yes forms (using your own plug-in) or splitting content into many page parts could definitely also in some cases be the right solution... but in cases where we want to allow more flexibility, to allow the customer to structure their content more freely... we're probably better off going with some WymEditor-like solution + cleaning up and education. Apart from the actual editing of content, it'd be really cool to find and easy way to hide some stuff in Radiant from the customer. Eg. some things such as the CSS and RSS things, and sometimes some page-parts. And maybe in some cases even the popup menus: layout, page type, status and filter. cheers, Simon PS. I begun the search for the perfect solution to this in my thesis, if anyone's interested: http://simon.fi/en/thesis On Nov 18, 2008, at 20:46 , Mohit Sindhwani wrote: Casper Fabricius wrote: However, I have a client whose content editor is very frustrated with the system. She can only just tolerate using Markup, and she refuses to write any kind of HTML - Radius tags falls into this category from her point of view. According to her, a proper CMS would hide all this "technical stuff" and provide custom forms for all types of content. Casper, my "solution" would be to find a slightly more technical client :P No, I'm joking (of course!) Here's what I would recommend: 1. First, factor out as far as possible so that whatever is not page specific is in snippets. 2. If all she needs is a few styles of pages, I would create different page types or layouts. 3. Then tell her that the different parts that she wants need to go into different page parts. It would be cool if you could modify the "Add Child" behavior to allow you to select the kind of child page you want and then give you a blank page with all the different tabs created (page parts)... or it could be done with a bit of Javascript that detects when you change the Layout/ page and automatically adds in the different page parts? It could even be a special drop down box next to the Page Type that triggers the actions? 4. The problem: she still needs to use textile for some of the things, such as images. I'm not sure if the Textile Helper will help? It's been a while since I looked at it, but there's a hello world guide on my blog: http://notepad.onghu.com/2007/3/28/using-textile-editor-plugin-and-acts_as_textiled It could make some things easier for her, I hope... without going down the path of WYSIWIG. If you do go down WYSIWIG, I hear good things about WymEditor - and Benny's on the list! Of course, Casper, you are more experienced than I am. Do let us know what you eventually settle on :) Cheers, Mohit. 11/19/2008 | 2:45 AM. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
Steven Southard said the following on 11/18/2008 01:33 PM: > I think maybe you just need to take another approach with her. Seems > sometimes web development is more psychology then programming. Does > she just put her hand over her ears when you say Markdown or Textile? > I've had a client like that! She just wants to make headers, > paragraphs, and upload pictures right? Keep working with her, tell > here to take a few breaths, and keeping reminding her that the filters > are there to keep the "technical stuff" out of her way. > > My clients don't seem to mess with the snippets, tags, or css classes > that much. They just use the filters and maybe one tag and some > classes that they copy and past from where ever else it was used on > the site. It takes a bit for them to get the hang of it but if they > can see the simple patterns they'll be able to add their content. Perhaps if 'snippets' were called something more familiar like 'macros' Yes, I *know* they aren't, but I'm talking about a psychological comfort zone. -- "Engineers like to solve problems. If there are no problems handily available, they will create their own problems. Normal people don't understand this concept; they believe that if it ain't broke, don't fix it. Engineers believe that if ain't broke, it doesn't have enough features yet." - S. Adams ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
Adam van den Hoven said the following on 11/18/2008 01:42 PM: > You just hit on an interesting idea for an extension. > > Frequently, people are going to reuse the same bits over and over. > Instead of making them go find it, what if we put a "scratchpad" on > the right hand side of the parts (which will consume some space from > the parts but that should be OK the visibility is important). That's interesting. One piece of software I use ha a number of vertical panels that can be tuned on and off. If you use Linux+KDE think of Konqueror+F9. Now imagine things can be dragged from those panels... We already have the things that go in the panel, which is primarily the snippets and the tags. Oh, and images. Paperclipped has some kind of 'bucket', doesn't it, that appears anyway. -- "Everybody comes to Rick's" - Casablanca ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
A couple of thoughts. 1) In general, isn't it the case that the site developer is going to want to deal with content. When you're creating content, you're seldom calling for the the part of some other page (I prefer to do this sort of work in the the layout myself). I'm not sure exposing content in this way is necessarily a good thing. At the very least, provide me a configuration mechanism to restrict access (for example, restricting certain things by user role?). Similarly, some snippets are really only supposed to go into layouts and would do very bad things in content (especially if you're in the bad habit of opening a tag in one snippet and closing it in another). 2)Make it Extensible. On 18-Nov-08, at 12:08 PM, Chris Parrish wrote: Alright, since this post is already heading in this direction, I'll throw out some ideas that I've been working on. These are getting pretty refined in my mind and I'm looking into creating an extension around them (possibly waiting for the new UI, we'll see)... 1. I think the textareas need to come with a toolbar above them (page parts, snippets, layouts). These toolbars would be filter specific. 2. All filters (including "none") would include the filter-selection dropdown (this makes it clear to the user what is controlling the toolbar content) 3. All filters (including "none") would include one or more insert-site-item buttons. The goal here is to prevent the user from having to remember radius tag names and their syntax (that's "coder stuff") and instead make working with radius more like any other gui application. The goal here is also to focus only on the tags used for day-to-day editing (I'm not sure a button to walk you through creating your site's navigation would be wise as it would just be clutter most of the time and that task is more technical in nature). Tag attributes could be handled graphically and automatically inserted into the tag. For example: * A "page properties" button would open up a properties browser (and maybe showing the current page's properties as examples). Items would include, title, slug, breadcrumb, author, etc. Selecting one of these properties would insert the appropriate tag (, etc) into the content at the cursor's position. * A "content" button would open up a browser for page and snippet content. Here the user can look through the existing items and select an existing snippet or page part. Once selected, it would insert the appropriate tag (either or ) at the selected position. * A "link" button would open a pages browser and allow the user to select one of their pages. This would insert the tag appropriately. * Asset extensions should plug in here to allow users to browse assets and choose the one they want, select any options, then insert the corresponding tag. 4. Each filter would have its own button set but they would have a consistent "flavor" across filters. For example: * Markdown would come with: bold, italics, bullet list, numbered list, heading(s), insert link, insert image, blockquote (something like http://livepipe.net/control/textarea). The insert link button should probably work together with the one mentioned above to let the user select from their own pages or insert an external link -- both formated for markdown. * Textile would have something like Markdown (again, the buttons look the same but they insert textile specific elements). I would welcome feedback or any collaborators. -Chris Jim Gay wrote: On Nov 18, 2008, at 1:42 PM, Adam van den Hoven wrote: You just hit on an interesting idea for an extension. Frequently, people are going to reuse the same bits over and over. Instead of making them go find it, what if we put a "scratchpad" on the right hand side of the parts (which will consume some space from the parts but that should be OK the visibility is important). This will give them a place to retrieve commonly used bits and then copy and paste them back into their content. Give it an easy way to save new scratches without leaving the page (key to making it useful). Provide a separate UI to "tweak" the scratch (edit, give it a title and a description) and we can bootstrap a bunch of scratches which will ease their entry into the world of "markup" Adam development has stalled on it, but the start of a browser extension intends to add an area where things like this can be done: http://github.com/saturnflyer/radiant-browser-extension/tree/master there's nothing much there other than the interface, but my intent is to provide a list of draggable snippets and allow extensions to add their own stuff (such as page
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
Alright, since this post is already heading in this direction, I'll throw out some ideas that I've been working on. These are getting pretty refined in my mind and I'm looking into creating an extension around them (possibly waiting for the new UI, we'll see)... 1. I think the textareas need to come with a toolbar above them (page parts, snippets, layouts). These toolbars would be filter specific. 2. All filters (including "none") would include the filter-selection dropdown (this makes it clear to the user what is controlling the toolbar content) 3. All filters (including "none") would include one or more insert-site-item buttons. The goal here is to prevent the user from having to remember radius tag names and their syntax (that's "coder stuff") and instead make working with radius more like any other gui application. The goal here is also to focus only on the tags used for day-to-day editing (I'm not sure a button to walk you through creating your site's navigation would be wise as it would just be clutter most of the time and that task is more technical in nature). Tag attributes could be handled graphically and automatically inserted into the tag. For example: * A "page properties" button would open up a properties browser (and maybe showing the current page's properties as examples). Items would include, title, slug, breadcrumb, author, etc. Selecting one of these properties would insert the appropriate tag (, etc) into the content at the cursor's position. * A "content" button would open up a browser for page and snippet content. Here the user can look through the existing items and select an existing snippet or page part. Once selected, it would insert the appropriate tag (either or ) at the selected position. * A "link" button would open a pages browser and allow the user to select one of their pages. This would insert the tag appropriately. * Asset extensions should plug in here to allow users to browse assets and choose the one they want, select any options, then insert the corresponding tag. 4. Each filter would have its own button set but they would have a consistent "flavor" across filters. For example: * Markdown would come with: bold, italics, bullet list, numbered list, heading(s), insert link, insert image, blockquote (something like http://livepipe.net/control/textarea). The insert link button should probably work together with the one mentioned above to let the user select from their own pages or insert an external link -- both formated for markdown. * Textile would have something like Markdown (again, the buttons look the same but they insert textile specific elements). I would welcome feedback or any collaborators. -Chris Jim Gay wrote: On Nov 18, 2008, at 1:42 PM, Adam van den Hoven wrote: You just hit on an interesting idea for an extension. Frequently, people are going to reuse the same bits over and over. Instead of making them go find it, what if we put a "scratchpad" on the right hand side of the parts (which will consume some space from the parts but that should be OK the visibility is important). This will give them a place to retrieve commonly used bits and then copy and paste them back into their content. Give it an easy way to save new scratches without leaving the page (key to making it useful). Provide a separate UI to "tweak" the scratch (edit, give it a title and a description) and we can bootstrap a bunch of scratches which will ease their entry into the world of "markup" Adam development has stalled on it, but the start of a browser extension intends to add an area where things like this can be done: http://github.com/saturnflyer/radiant-browser-extension/tree/master there's nothing much there other than the interface, but my intent is to provide a list of draggable snippets and allow extensions to add their own stuff (such as page_attachments) On 18-Nov-08, at 10:33 AM, Steven Southard wrote: I think maybe you just need to take another approach with her. Seems sometimes web development is more psychology then programming. Does she just put her hand over her ears when you say Markdown or Textile? I've had a client like that! She just wants to make headers, paragraphs, and upload pictures right? Keep working with her, tell here to take a few breaths, and keeping reminding her that the filters are there to keep the "technical stuff" out of her way. My clients don't seem to mess with the snippets, tags, or css classes that much. They just use the filters and maybe one tag and some classes that they copy and past from where ever else it was use
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
On Nov 18, 2008, at 1:42 PM, Adam van den Hoven wrote: You just hit on an interesting idea for an extension. Frequently, people are going to reuse the same bits over and over. Instead of making them go find it, what if we put a "scratchpad" on the right hand side of the parts (which will consume some space from the parts but that should be OK the visibility is important). This will give them a place to retrieve commonly used bits and then copy and paste them back into their content. Give it an easy way to save new scratches without leaving the page (key to making it useful). Provide a separate UI to "tweak" the scratch (edit, give it a title and a description) and we can bootstrap a bunch of scratches which will ease their entry into the world of "markup" Adam development has stalled on it, but the start of a browser extension intends to add an area where things like this can be done: http://github.com/saturnflyer/radiant-browser-extension/tree/master there's nothing much there other than the interface, but my intent is to provide a list of draggable snippets and allow extensions to add their own stuff (such as page_attachments) On 18-Nov-08, at 10:33 AM, Steven Southard wrote: I think maybe you just need to take another approach with her. Seems sometimes web development is more psychology then programming. Does she just put her hand over her ears when you say Markdown or Textile? I've had a client like that! She just wants to make headers, paragraphs, and upload pictures right? Keep working with her, tell here to take a few breaths, and keeping reminding her that the filters are there to keep the "technical stuff" out of her way. My clients don't seem to mess with the snippets, tags, or css classes that much. They just use the filters and maybe one tag and some classes that they copy and past from where ever else it was used on the site. It takes a bit for them to get the hang of it but if they can see the simple patterns they'll be able to add their content. Steven Indeed. Radiant's success can at least be partly attributed to it's simplicity. On Nov 18, 2008, at 11:44 AM, Casper Fabricius wrote: Hi everyone, I've used Radiant for more than 10 web sites during the past 1,5 years, and I really like it. Definitely the best CMS for Rails. However, I have a client whose content editor is very frustrated with the system. She can only just tolerate using Markup, and she refuses to write any kind of HTML - Radius tags falls into this category from her point of view. According to her, a proper CMS would hide all this "technical stuff" and provide custom forms for all types of content. I know what the core team might answer: Radiant CMS was not built for this woman. It was built for small sites and content editors with a bit of technical insight. But Radiant is still the most user-friendly CMS that exists for Rails, and I don't really feel like coding PHP just get a more "advanced" UI, which will suck anyway. So my question is: How do the rest of you handle this? How do you hide away "technical" stuff such as snippets, tags and css classes? Do you: - Use any of the WYSIWYG filters? (I've done this a few times, it has its own problems) - Build very specific custom layouts for all variants for pages? - Use a generic templating interface such as radiant-templates- extension to wrap everything up? - Write custom extensions to wrap all kinds of "elements" nicely in forms? (such as newsletters, spots, list of various items, etc.) Can Radiant be palatable for content editors such as my client, or is it simply the wrong choice in this case? It's tough to know how to handle it without a better understanding, but I've had clients ask for WYSIWYG and had it only cause more problems once they start using it. I do as much as I can to handle the layout of content with CSS so that entering the text stays simple. When clients want to start moving things around and adding more complex HTML within the content, I try to first find a way to simplify the content. If she wants to pay you to create forms, then create the forms. I think that as one goes down a path to make things simpler you may find that it ends up being more complex. Abstracting out content into forms may or may not do this. I think that its reasonable that she not want to write HTML or radius tags, but she may be adding more hoops for you and herself to jump through when learning to type less expensive solution. I'm interested to see other responses. -Jim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
That's actually something I'd use. I really like that idea. It's kind of there with the filters and available tags but I really like the idea of a customizable scratch pad. I'd use it all the time. Steven On Nov 18, 2008, at 12:42 PM, Adam van den Hoven wrote: You just hit on an interesting idea for an extension. Frequently, people are going to reuse the same bits over and over. Instead of making them go find it, what if we put a "scratchpad" on the right hand side of the parts (which will consume some space from the parts but that should be OK the visibility is important). This will give them a place to retrieve commonly used bits and then copy and paste them back into their content. Give it an easy way to save new scratches without leaving the page (key to making it useful). Provide a separate UI to "tweak" the scratch (edit, give it a title and a description) and we can bootstrap a bunch of scratches which will ease their entry into the world of "markup" Adam On 18-Nov-08, at 10:33 AM, Steven Southard wrote: I think maybe you just need to take another approach with her. Seems sometimes web development is more psychology then programming. Does she just put her hand over her ears when you say Markdown or Textile? I've had a client like that! She just wants to make headers, paragraphs, and upload pictures right? Keep working with her, tell here to take a few breaths, and keeping reminding her that the filters are there to keep the "technical stuff" out of her way. My clients don't seem to mess with the snippets, tags, or css classes that much. They just use the filters and maybe one tag and some classes that they copy and past from where ever else it was used on the site. It takes a bit for them to get the hang of it but if they can see the simple patterns they'll be able to add their content. Steven On Nov 18, 2008, at 11:44 AM, Casper Fabricius wrote: Hi everyone, I've used Radiant for more than 10 web sites during the past 1,5 years, and I really like it. Definitely the best CMS for Rails. However, I have a client whose content editor is very frustrated with the system. She can only just tolerate using Markup, and she refuses to write any kind of HTML - Radius tags falls into this category from her point of view. According to her, a proper CMS would hide all this "technical stuff" and provide custom forms for all types of content. I know what the core team might answer: Radiant CMS was not built for this woman. It was built for small sites and content editors with a bit of technical insight. But Radiant is still the most user-friendly CMS that exists for Rails, and I don't really feel like coding PHP just get a more "advanced" UI, which will suck anyway. So my question is: How do the rest of you handle this? How do you hide away "technical" stuff such as snippets, tags and css classes? Do you: - Use any of the WYSIWYG filters? (I've done this a few times, it has its own problems) - Build very specific custom layouts for all variants for pages? - Use a generic templating interface such as radiant-templates- extension to wrap everything up? - Write custom extensions to wrap all kinds of "elements" nicely in forms? (such as newsletters, spots, list of various items, etc.) Can Radiant be palatable for content editors such as my client, or is it simply the wrong choice in this case? Med venlig hilsen / Best regards, Casper Fabricius http://casperfabricius.com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
Casper Fabricius wrote: However, I have a client whose content editor is very frustrated with the system. She can only just tolerate using Markup, and she refuses to write any kind of HTML - Radius tags falls into this category from her point of view. According to her, a proper CMS would hide all this "technical stuff" and provide custom forms for all types of content. Casper, my "solution" would be to find a slightly more technical client :P No, I'm joking (of course!) Here's what I would recommend: 1. First, factor out as far as possible so that whatever is not page specific is in snippets. 2. If all she needs is a few styles of pages, I would create different page types or layouts. 3. Then tell her that the different parts that she wants need to go into different page parts. It would be cool if you could modify the "Add Child" behavior to allow you to select the kind of child page you want and then give you a blank page with all the different tabs created (page parts)... or it could be done with a bit of Javascript that detects when you change the Layout/ page and automatically adds in the different page parts? It could even be a special drop down box next to the Page Type that triggers the actions? 4. The problem: she still needs to use textile for some of the things, such as images. I'm not sure if the Textile Helper will help? It's been a while since I looked at it, but there's a hello world guide on my blog: http://notepad.onghu.com/2007/3/28/using-textile-editor-plugin-and-acts_as_textiled It could make some things easier for her, I hope... without going down the path of WYSIWIG. If you do go down WYSIWIG, I hear good things about WymEditor - and Benny's on the list! Of course, Casper, you are more experienced than I am. Do let us know what you eventually settle on :) Cheers, Mohit. 11/19/2008 | 2:45 AM. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
You just hit on an interesting idea for an extension. Frequently, people are going to reuse the same bits over and over. Instead of making them go find it, what if we put a "scratchpad" on the right hand side of the parts (which will consume some space from the parts but that should be OK the visibility is important). This will give them a place to retrieve commonly used bits and then copy and paste them back into their content. Give it an easy way to save new scratches without leaving the page (key to making it useful). Provide a separate UI to "tweak" the scratch (edit, give it a title and a description) and we can bootstrap a bunch of scratches which will ease their entry into the world of "markup" Adam On 18-Nov-08, at 10:33 AM, Steven Southard wrote: I think maybe you just need to take another approach with her. Seems sometimes web development is more psychology then programming. Does she just put her hand over her ears when you say Markdown or Textile? I've had a client like that! She just wants to make headers, paragraphs, and upload pictures right? Keep working with her, tell here to take a few breaths, and keeping reminding her that the filters are there to keep the "technical stuff" out of her way. My clients don't seem to mess with the snippets, tags, or css classes that much. They just use the filters and maybe one tag and some classes that they copy and past from where ever else it was used on the site. It takes a bit for them to get the hang of it but if they can see the simple patterns they'll be able to add their content. Steven On Nov 18, 2008, at 11:44 AM, Casper Fabricius wrote: Hi everyone, I've used Radiant for more than 10 web sites during the past 1,5 years, and I really like it. Definitely the best CMS for Rails. However, I have a client whose content editor is very frustrated with the system. She can only just tolerate using Markup, and she refuses to write any kind of HTML - Radius tags falls into this category from her point of view. According to her, a proper CMS would hide all this "technical stuff" and provide custom forms for all types of content. I know what the core team might answer: Radiant CMS was not built for this woman. It was built for small sites and content editors with a bit of technical insight. But Radiant is still the most user- friendly CMS that exists for Rails, and I don't really feel like coding PHP just get a more "advanced" UI, which will suck anyway. So my question is: How do the rest of you handle this? How do you hide away "technical" stuff such as snippets, tags and css classes? Do you: - Use any of the WYSIWYG filters? (I've done this a few times, it has its own problems) - Build very specific custom layouts for all variants for pages? - Use a generic templating interface such as radiant-templates- extension to wrap everything up? - Write custom extensions to wrap all kinds of "elements" nicely in forms? (such as newsletters, spots, list of various items, etc.) Can Radiant be palatable for content editors such as my client, or is it simply the wrong choice in this case? Med venlig hilsen / Best regards, Casper Fabricius http://casperfabricius.com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
I think maybe you just need to take another approach with her. Seems sometimes web development is more psychology then programming. Does she just put her hand over her ears when you say Markdown or Textile? I've had a client like that! She just wants to make headers, paragraphs, and upload pictures right? Keep working with her, tell here to take a few breaths, and keeping reminding her that the filters are there to keep the "technical stuff" out of her way. My clients don't seem to mess with the snippets, tags, or css classes that much. They just use the filters and maybe one tag and some classes that they copy and past from where ever else it was used on the site. It takes a bit for them to get the hang of it but if they can see the simple patterns they'll be able to add their content. Steven On Nov 18, 2008, at 11:44 AM, Casper Fabricius wrote: Hi everyone, I've used Radiant for more than 10 web sites during the past 1,5 years, and I really like it. Definitely the best CMS for Rails. However, I have a client whose content editor is very frustrated with the system. She can only just tolerate using Markup, and she refuses to write any kind of HTML - Radius tags falls into this category from her point of view. According to her, a proper CMS would hide all this "technical stuff" and provide custom forms for all types of content. I know what the core team might answer: Radiant CMS was not built for this woman. It was built for small sites and content editors with a bit of technical insight. But Radiant is still the most user- friendly CMS that exists for Rails, and I don't really feel like coding PHP just get a more "advanced" UI, which will suck anyway. So my question is: How do the rest of you handle this? How do you hide away "technical" stuff such as snippets, tags and css classes? Do you: - Use any of the WYSIWYG filters? (I've done this a few times, it has its own problems) - Build very specific custom layouts for all variants for pages? - Use a generic templating interface such as radiant-templates- extension to wrap everything up? - Write custom extensions to wrap all kinds of "elements" nicely in forms? (such as newsletters, spots, list of various items, etc.) Can Radiant be palatable for content editors such as my client, or is it simply the wrong choice in this case? Med venlig hilsen / Best regards, Casper Fabricius http://casperfabricius.com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
I'd like to see this too. I use it for exactly this purpose, to give non-technical people the ability to manage a simple website using a CMS. To be honest, I think that the mostly technical person doesn't really need an OS CMS, they can either hand code the HTML just as easily (maybe run some scripts to generate naviation) and upload the files via ftp/svn or write their own CMS. Its precisely when we have more complicated needs (of which multiple, non-technical users is a likely one) that Radiant becomes most useful. I have some thoughts on this: 1) What would be awesome would be a WYSIWIG editor plugin that is an EXTENSIBLE HTML/XML editor. This would allow one to create GUI elements for all of the common radius tags (override creating links, for example, putting an asset browser into there, etc) and have it create the necessary markup. Maybe a markup WYSIWYG editor will allow this too but I don't know of any 2) Normally when someone wants a custom template that captures something specific (a news article or a product) really its just a way to more seamlessly (and realiably) enforce content structure (here is you headline, here is your kicker, a product image goes in this box) but really all we want to do is generate structured markup for various parts. It would be wonderful if one could create page "templates" that imposed some sort of structure but behind the scenes simply added a page to the database with a number of parts with predefined markup. (I'm not sure if this is like the templates extension Sean released.. Haven't had a chance to look at it). Making it part of the "pages" structure keeps it clear where it appears. On the other hand, you can tell your client that if they really want all that they're looking at a system like Teamsite from Interwoven which would probably cost them in the range of a half million plus 10% per year (but don't forget to put your 4% markup on that)... Adam On 18-Nov-08, at 9:44 AM, Casper Fabricius wrote: Hi everyone, I've used Radiant for more than 10 web sites during the past 1,5 years, and I really like it. Definitely the best CMS for Rails. However, I have a client whose content editor is very frustrated with the system. She can only just tolerate using Markup, and she refuses to write any kind of HTML - Radius tags falls into this category from her point of view. According to her, a proper CMS would hide all this "technical stuff" and provide custom forms for all types of content. I know what the core team might answer: Radiant CMS was not built for this woman. It was built for small sites and content editors with a bit of technical insight. But Radiant is still the most user- friendly CMS that exists for Rails, and I don't really feel like coding PHP just get a more "advanced" UI, which will suck anyway. So my question is: How do the rest of you handle this? How do you hide away "technical" stuff such as snippets, tags and css classes? Do you: - Use any of the WYSIWYG filters? (I've done this a few times, it has its own problems) - Build very specific custom layouts for all variants for pages? - Use a generic templating interface such as radiant-templates- extension to wrap everything up? - Write custom extensions to wrap all kinds of "elements" nicely in forms? (such as newsletters, spots, list of various items, etc.) Can Radiant be palatable for content editors such as my client, or is it simply the wrong choice in this case? Med venlig hilsen / Best regards, Casper Fabricius http://casperfabricius.com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
