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
https://github.com/search?type=Everything&language=&q=radiant+editor&repo=&langOverride=&x=0&y=0&start_value=1
(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.
Where should you start? How about here
http://github.com/radiant/radiant/issues
Or here http://github.com/radiant/radiant-prototype
Or contribute to http://github.com/saturnflyer/radiant-help-extension
Even if you don’t understand some piece of code, you eventually will
by trying to figure it out or someone will help you out with it.
p.s.: Will be at ArrrrCamp tomorrow. Who else?
I really wish I could be there.
–
Jim G.
Saturn Flyer LLC
http://www.saturnflyer.com
571-403-0338
