Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?

2008-11-20 Thread Chris Parrish
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?

2008-11-20 Thread Anton J Aylward
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?

2008-11-20 Thread Simon Rönnqvist
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?

2008-11-20 Thread Anton J Aylward
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?

2008-11-20 Thread Jason Garber

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?

2008-11-20 Thread Jason Garber
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?

2008-11-20 Thread Simon Rönnqvist

  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?

2008-11-20 Thread Jason Garber

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?

2008-11-20 Thread Simon Rönnqvist

  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?

2008-11-20 Thread Anton J Aylward
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)

2008-11-20 Thread Simon Rönnqvist

  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?

2008-11-20 Thread Jason Garber
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?

2008-11-19 Thread Casper Fabricius
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?

2008-11-19 Thread Simon Rönnqvist

  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?

2008-11-18 Thread Anton J Aylward
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?

2008-11-18 Thread Anton J Aylward
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?

2008-11-18 Thread Adam van den Hoven

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?

2008-11-18 Thread Chris Parrish
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?

2008-11-18 Thread Jim Gay

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?

2008-11-18 Thread Steven Southard
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?

2008-11-18 Thread Mohit Sindhwani

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?

2008-11-18 Thread Adam van den Hoven

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?

2008-11-18 Thread Steven Southard
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?

2008-11-18 Thread Adam van den Hoven
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