In the past few weeks, I’ve ramped up development of ReportingOn.
Of course, for me, that means I’m spending time early in the morning and late at night exploring different options, creating mockups, ditching everything I’ve done and starting over again.
Here’s a few paths of exploration I’ve been down lately:
- Drupal: Drupal 6 isn’t ready for what I need it to do. The Views and CCK modules aren’t up to speed yet, or maybe I just haven’t found the right set of instructions yet. That brings me to my biggest complaint about Drupal: Although there’s a huge open source community gelling around it, no one seems to be writing documentation that makes anything terribly clear, from installation to creating content types in CCK.
- Django: This is certainly the most challenging track of development I’ve taken, starting to learn Django from online tutorials and the Django Book (the free online version at the moment). One of my problems with Drupal is that it’s over-featured by default. I find myself trying to undo a lot of default Drupal behavior. Hence, the Django path. I figure I can write the views and models myself, only including the puzzle pieces I need to get the job done.
- WordPress: Speaking of getting the job done, the WordPress Prologue theme combined with a few other elements (maybe bbPress?) could do it. But at a cost, and I think the cost is both in extensibility and repeatability of the application. Either way, doing the small amount of work necessary in WordPress to get a prototype running might be worth it to put up a proof of concept and let one group of reporters or bloggers have at it to beat on the theory behind ReportingOn, if not necessarily the final branch of code.
- HTML mockups: This is something I highly recommend. If you have the skill to write a simple, flat HTML page with a stylesheet, you have a working template for your project that any developer can understand. If your skills are sharp enough, the mockups you build can serve as the templates of your final design, wrapping the database-driven code that’s doing the heavy lifting. The crucial purpose of these mockups for me is to get a better idea of which features belong in the core of the site at the first public launch, and which should roll out later if necessary or logical.
Which leads to a word on iterative development:
At the birds-of-a-feather group at the MIT meeting of Knight News Challenge winners in June, the conversation covered iterative development, choosing a platform, and hiring developers, among other sidebars.
While the conversation was going on, I was crossing features off the back-of-a-napkin sketches I had been working on. That Digg-esque scoreboard of topics in various mockups I’ve put together over the last year? Probably not in play. A list of featured reporters on the homepage? Doesn’t seem necessary.
So now I’m working on fresh HTML mockups to try and finalize which features I’ll bake into the first release of ReportingOn. That way, I can make a decision about a development platform with a solid specification in my hands. Normally, that’s the sort of thing I’d need to create to pass on to a developer.
In my case, I’m planning to do the majority of the coding myself, but that doesn’t mean I can skip any steps in the process.
Not including Rails as a consideration? I’m a django guy, and that’s what I vote for, but Rails can do a lot of the same stuff and might be worth a look. Django’s auto admin usually make it an auto winner in projects where there is a staff working behind the scenes, but in a community only site with few inward facing parts, Rails might bring some advantages.
I vote against wordpress. It’s an amazing way to get started in under an hour, and it’s freaking awesome as a blog tool. As this thing grows, you’ll surely accumulate some ducktape and scar tissue holding parts together. It can be be bad in the long run to start with a solution that involves cobbling pieces onto a blog engine.
Great move on starting with the HTML, very 37Signals.
Hi Ryan,
Drupal 5 is still what most Drupal shops are using to develop production sites. Just now, as in this week, Views and CCK are getting to the point that I’d look at them for production on Drupal 6.
Drupal core being too featurefull is not a complaint I hear often! What parts are you trying to undo? You can get to just about zero features just by disabling modules, heh.
It is hard to find good documentation, but it doesn’t always mean it’s not there. Full internet searches can be more useful than searches on Drupal.org.
For instance, here’s a whole hour on CCK and Views! (From a talk by Jennifer Hodgdon of Poplar ProductivityWare, see also her overview article of making Drupal a site).
benjamin, Agaric Design Collective (disclosure: yes, we build Drupal web sites)
@Hassan – I’m interested in Rails, but haven’t touched it, don’t know what it can do that Django or Drupal can’t, and – perhaps most important for me as a bit of a lone wolf – I don’t have many friends working in it.
Oh, and yes to the duct tape and scar tissue holding WP together. I love it, but building things larger than a blog can involve lots of bubble gum and scotch tape.
@Benjamin – Totally tracking CCK and Views dev for D6. I’ll probably spend two more weeks with Django and then check back into Drupal. Thanks for the tutorial link!
Ryan, discussions like this are great to have here. I like reading posts where the author doesn’t think that he or she has the answer, yet. It makes the discussion all the more interesting.
Ryan, I think your recommendation of creating flat HTML pages with a stylesheet to show a developer what you need is a great idea. I think your advice is very useful. At least for me. Thanks!
Hi Ryan,
We’re rolling out the new Ourmedia in Drupal 6 in a few weeks. Haven’t heard the developers discuss shortfalls with Views and CCK modules yet. :~)
I just interviewed Leah Culver, who developed Pownce.com on top of Django starting a year ago.
Completely agree about the lack of documentation (and thus usability) of Drupal, esp. for non-geeks. Alas, Knight passed on my proposal to address that (and building out a set of rich social media functionalities and capabilities) a year back. Maybe next year. :~)
We are using Drupal. One reason we love about it that there is tons of documentation [as Benjamin suggests]. Same question here – what do you want to undo in Drupal? If there is a real reason which makes it necessary just deactivate the respective modules and you won´t be bothered by there functionality anymore.
You may look at silverstripe.com – its easy to use and very intuitive and has an excellent framework.
@Benjamin & @Drupal-ista:
Good questions about the core functionality I want to undo in Drupal. You’re right, it’s generally as simple as turning off a module (for example, ‘Blog’) and adding a new content type (‘Update’).
And that’s probably the best approach, since I might want to turn ‘Blog’ back on later, but then I need to rebuild quite a bit of ‘Blog’ functionality (tags, archives, etc.) for the ‘Update’ type, which makes me want to just hack the ‘Blog’ type to be limited to 200 characters or so.
I’ll keep digging away at it.