this is not about bashing Radiant. Instead, I’d like to mention a few
things that make it harder to sell Radiant-based solutions to customers
who often answer “Why don’t you use Wordpress for the job?”
(1) Radiant is like a toolbox for websites, but not quite.
From a developer perspective, Radiant doesn’t stand in the way while I’m
building the next great website for a customer. It’s a great tool to
build and develop. From a customer (aka. “end user”) perspective,
Radiant is a bunch of input boxes where you have to enter cryptic stuff
which looks a lot like code. Well, in fact it is. Thats why some of my
customers wouldn’t ever trade in their wordpress UI for a nifty Radiant
site. Which is a shame because they could do so much better. How can I
sell Radiant to users who don’t recognize the simply aesthetics of
Textile {or any other markup}?
(2) Core Radiant isn’t enough to build a real-world website.
HTML, javascript, css and images, that what you’ll typically need.
Radiant (at least edge) handles the first three pretty well, considering
(1). For images, you need the paperclipped extension. Why isn’t this
core functionality? And even it it was: URLs like
/assets/47/some_image.png contain that database id, which changes with
every installation and make them hard to remember.
(3) Upgrading is a pain.
Even if I dont like it: Upgrading Wordpress is a breeze. Upgrading
Radiant usually involves SSH connections, terminal commands, some gem
handling and server restarting. Not a breeze, not at all. I can do that,
but end users typically can’t.
How do you think about this? I’d love to contribute to make stuff
easier, but I’m not sure where to start. Any comment is welcome. Kind
regards,
On Oct 27, 2010, at 4:11 AM, Christian Aust wrote:
tool to build and develop. From a customer (aka. “end user”)
Radiant (at least edge) handles the first three pretty well,
do that, but end users typically can’t.
How do you think about this? I’d love to contribute to make stuff
easier, but I’m not sure where to start. Any comment is welcome.
Kind regards,
Christian
p.s.: Will be at ArrrrCamp tomorrow. Who else?
Upgrading Radiant usually involves SSH connections, terminal
commands, some gem handling and server restarting. Not a breeze,
not at all.
It’s also likely that you’ll have to update a couple extensions before
it’ll restart.
1 - I think the beauty of Radiant is that because it’s so developer
friendly
it’s up to you to make sure it does what your customers want it to do.
The best case study I could possibly come up with is with my least
computer-savvy clients using it daily, and loving it. I sat them down
in
front of Drupal, Wordpress and Radiant and more often then not they’ve
picked Radiant. Wordpress is great if you know where everything is,
but if
not - good luck to you. Same with Drupal.
And for what it’s worth, printing out a textile or markdown cheat sheet
for
a customer will get them a lot farther with a lot more control. I
guess it
all depends on how willing and progressive your clients are? If they’re
stubborn then, yeah, it’s difficult.
2 - I agree. But core radiant alone isn’t what you should be using to
build
a real-world website. If you’re reluctant to find the extensions that
help
flesh out the rest of the requirements then … well, I don’t know what
to
tell you.
3 - Set up a staging environment. Use source control. Develop a
process.
It’s not that hard once you get it down. I push code and an entire
database to a staging environment every day. It works pretty well for
me
and takes, literally, less than a minute. (How? Git + Navicat).
Bonus round : I have yet to be called at 3am for a security problem with
Radiant. Can’t say the same for wordpress, or other PHP-based
applications.
I’m always happy to see comments like this. If we don’t know where
there are problems, we can’t make the project better.
Thanks, Christian.
On Wed, Oct 27, 2010 at 5:11 AM, Christian Aust [email protected] wrote:
Folks,
this is not about bashing Radiant. Instead, I’d like to mention a few things
that make it harder to sell Radiant-based solutions to customers who often answer
“Why don’t you use Wordpress for the job?”
(1) Radiant is like a toolbox for websites, but not quite.
From a developer perspective, Radiant doesn’t stand in the way while I’m
building the next great website for a customer. It’s a great tool to build and
develop. From a customer (aka. “end user”) perspective, Radiant is a bunch of
input boxes where you have to enter cryptic stuff which looks a lot like code.
Well, in fact it is. Thats why some of my customers wouldn’t ever trade in their
wordpress UI for a nifty Radiant site. Which is a shame because they could do so
much better. How can I sell Radiant to users who don’t recognize the simply
aesthetics of Textile {or any other markup}?
If it’s cryptic, you’re doing it wrong.
Sample Radiant sites are also doing it wrong too, so that needs to be
fixed in our templates. But you should do everything you can to hide
Radius from the typical user. For different users that changes, and
overtime in may change with any user.
I used to use Textile, but it requires too much knowledge about what
HTML is and has an expectation that you understand it’s features. It
feels more like HTML shorthand, whereas Markdown feels more like just
marking up my content. So what you use, depends on your users.
Not only that, but there are extensions to add wysiwyg editors. http://ext.radiantcms.org/ and if you can’t find them there, you might
find them at Search · radiant editor · GitHub
(2) Core Radiant isn’t enough to build a real-world website.
HTML, javascript, css and images, that what you’ll typically need. Radiant (at
least edge) handles the first three pretty well, considering (1). For images, you
need the paperclipped extension. Why isn’t this core functionality? And even it it
was: URLs like /assets/47/some_image.png contain that database id, which changes
with every installation and make them hard to remember.
Why would you try to remember an image path? There are radius tags for
that in paperclipped itself.
Core Radiant has been plenty for many “real-world” websites (whatever
that means).
Some sites may not need uploading of images. Others can add an
extension to do it (and there’s more than just paperclipped:
page_attachments, mediamaid, cy_image, upload, and more).
Eventually, we’ll have some image handling capability in the core
application, but Radiant didn’t become popular because it had
everything in it; it became popular because it was so simple and
extensible.
(3) Upgrading is a pain.
Even if I dont like it: Upgrading Wordpress is a breeze. Upgrading Radiant
usually involves SSH connections, terminal commands, some gem handling and server
restarting. Not a breeze, not at all. I can do that, but end users typically
can’t.
PHP and Ruby are fundamentally different languages.
If you want an end user to be able to upgrade Radiant, you’ll need to
write the piece that does that (and it will be complicated). The main
reason you can do that in Wordpress is that someone made it so.
I’m personally working hard to make upgrading Radiant easier (and part
of that is just plain old planning), but there are still a lot of
ideas and code to be hammered out. But you said it best when you began
here “Even if I dont like it…” I’d much rather enjoy my work
everyday and have an occasional upgrade hiccup that not like working
with the tool and have the upgrades go smoothly: “Yay, I can easily
use the next version which I will enjoy just as little as this one.”
How do you think about this? I’d love to contribute to make stuff easier, but
I’m not sure where to start. Any comment is welcome. Kind regards,
Christian
I want good ideas from anywhere. Radiant isn’t built to be just like
project X or to have all the features of project Y. It’s build to be
whatever we decide and it’s getting more powerful and more flexible
with each release.
Where to start? Wherever you care. I started by writing extensions and
then realized that the existing <r:if_content> tags needed serious
work and additional features. That got me into more and more. I found
kindred spirits in the community and bounced ideas off of them. John
Muhl and I would work on fixing bugs before either of us even had
commit rights. I’d write to the previous maintainer, Sean C., and
let him know that fixed some bug or that I pulled in features from
other forks and all tests passed for me.
(1). I think that what Radiant provides in terms of content control to
develop and maintain a website is great. It’s mixture that developers
(like myself) love for its power of customization, and it’s not too
hard for a non-developer to quickly pick up. If a content editor can’t
understand page parts and radius tags and how to use them, perhaps
they should not be meddling with content. I think by dumb-ing things
down too much for your average user will get in the way of Radiant’s
power users and/or developers.
(2). There I can’t agree with you more. From personal experience, the
largest drawback for Radiant is lack of page access controls. Yes,
there are extensions like members and reader, that allowed us to
create our own login system to serve personalized content. But these
extensions (and our system based on them) are ugly hacks (e.g. piggy-
backing on class-methods to make current_user available in tags, etc).
I think page access control (with something like Roles) with
personalized content is something that is a must-have for a serious
CMS.
(3). I have mixed feelings about this. Yes, upgrading should be
easier. But if you use a lot of extensions, some of them may not be
maintained by authors, and may not work with new Radiant versions,
etc. Radiant is a developing CMS, and it’s APIs change all the time,
so there is a lack of stable API, which makes any meaningful attempts
of straight upgrades hard (or even impossible) a lot of the time. At
the same time, I feel uneasy letting end-users conduct upgrades to
software components. Speaking from experience, I see this as a source
of many problems.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.