Bryce Harrington wrote:
On Tue, Mar 15, 2005 at 04:54:14PM +0000, Jonathan Leighton wrote:
PS. Bryce, out of interest (+ I might be able to do something about it too), what is it you don't like about WordPress, or prefer about the current system?
I think mainly my reluctance stems from past problems with other content management systems. WordPress looks like a great tool, and it looks like it's got some people excited about using it, and that's good. It's nice that it has RSS.
There's a number of issues I've seen when converting to a CMS in the past. Some of these were specific to the particlar CMS's we used at the time, others are probably more inherent issues with CMS in general.
Traditionally, the CMS's are always touted as "making it easier for non-techies to add content to the site, so more people will work on it". This is out of a feeling that web applications are easier to use than commandline tools, and that "everyone" is comfortable using web tools but not everyone is comfortable using commandline tools. Unfortunately, oftentimes CMS's end up just as complex; the more features the CMS has, the more complex. As well, it often turns out that there are people who prefer doing things through commandline over web tools, who end up ceasing contributing to the site. Thus, in the end, the _number_ of contributors doesn't change, just their identity.
This is very important. You probably know even better than I do that a crappy UI can make an otherwise great piece of software (be that a web application or a desktop one) into something that is extremely difficult to use. From what I've seen (and I've spent quite a few hours researching this in the past), Open Source CMSes are seriously lacking on the UI side of things (although not just that -- I have plenty of other gripes with most of them). However WordPress (and Textpattern, come to think of it) really stands out at me as an app where a lot of thought has been put into the interface -- obviously everyone has their own opinion (*especially* when it comes to interfaces), but I don't think anyone would deny that the interface has been designed as opposed to being the outworking of adding new features.
One thing that I haven't mentioned before is that the "Write" page for the prototype I made is currently set to "Advanced". Feel free to change it to "Simple" in Options>Writing and observe the difference -- I don't think there's anything there that anyone would have difficulty with.
At the end of the day there's no definite answer about whether WordPress or the current way is easier; it all comes down to opinion. I'm not out to make anyone's life more difficult, and I do happen to hold the opinion that it's easier with WP -- both because there are less steps involved, and it takes less effort just type something out in an admin panel.
I'd be interested to hear whether *you* think it's more difficult in WordPress or the current way, as you are the person who currently posts news. If you don't find it any harder in WordPress then the command line argument doesn't really apply to our situation here. Again, I'm not trying to make anyone's life harder, so I'm open to opinions.
One cost of most CMS's is that they're more computationally intensive. Oftentimes they're implemented as "dynamic pages", meaning that things get generated on the fly. There are some advantages to this, but also some disadvantages. For example, the two times I've gone through conversion to Zope, performance was dismissed as an issue to consider, yet once the system was implemented, it would break whenever we got Slashdotted. One ends up implementing Squid proxies, etc. in order to overcome this. With static pages sitting in a file system with nothing but Apache (and maybe PHP) needed, the number of things that can go wrong is much smaller, and performance is essentially a non-issue.
I'm afraid I can't really say anything about this one. My site doesn't get anywhere near the hits that would be needed to gauge whether WordPress can withstand a Slashdotting, and I've never done any benchmarking (although maybe that would be a fun thing to try when I have some time). I have seen articles/comments in the past that WordPress scales well although I couldn't find them when doing a Google search. There are also a number of popular sites that run it like molly.com, and -- of course -- photomatt.net.
At the end of the day there is a risk in everything. I don't think that inkscape.org gets enough traffic for performance to be a significant issue -- but then I can't promise it won't be either. All I'll say is that this[1], IMO, answers the performance argument extremely well.
[1] http://www.amber.org/~petrilli/archive/2005/03/08/the_redherring_of_performa...
CMS can also be somewhat inflexible in certain ways, compared with plain file system based approaches. For instance, if you need to make a global modification to a site, if everything's in a plain file system it's pretty straightforward to write a sed or perl script to make the change. With a CMS, you're limited to the tools that come bundled with it; often you could create an add on or hack into the CMS code itself, but it can turn out less time consuming to just make all the changes manually.
Maintenance can also be an issue. In the current system our news is implemented in nothing more than two php files (the front page plus a second page for archived news items). With a CMS, in order to "simplify" things, it often requires adding a database, some libraries, templates, extra code, config files, etc. and from an administration point of view you've actually complicated things a good deal. Is the extra administrative complexity worth the user simplicity? In a big company, perhaps, but in a modestly sized OSS project like ours, the person using the system may end up being one and the same as the guy mainaining it.
I think the two points above go hand-in-hand.
My opinion is that databases actually *add* flexibility to the data because they add meaning to it. It's far easier to change between one CMS to another than to change between text files and a CMS. The current news is an example of this -- while writing my database-importing script, I found one post without a date entirely, and that at one point the date format had changed from "January, February, ..." to "Jan, Feb, ...". With databased data these changes would be performed on a timestamp before rendering the page, rather than being "hardcoded" to a text file.
I understand your concerns about modifying a database, however, I think perhaps the flexibility of editing relies more on the person *doing* the editing than the medium which is used to store the information. Personally I'd feel perfectly comfortable writing a script to make some global change in a database, but you, or somebody else, or Mr. Joe Average inkscape-develee may not be able to do that so easily because that might not be where their expertise and experience lies.
Upgrading is the same -- I'm pretty familiar with WordPress and its codebase, so if something went wrong (which has never happened in my experience), I'd be in a comfortable position to sort it out. But not everyone is.
These are valid concerns so to give something to fall back on, I'm perfectly happy to be the maintainer of the WordPress part of the website for the foreseeable future. If we did go ahead with it, and it was decided that perhaps WordPress *isn't* as good a system as the current one, I'd also be happy to write a script to transfer from the database back to the text file.
Education is another area of concern. In a company with marketing people who don't know CVS, education may come out favoring the CMS since they're more WYSIWYG. However, in an open source project, the random contributor is more likely to have had familiarity with CVS and/or PHP than with a given CMS. A random contribution is more likely to come in as a raw HTML or PHP page.
In this situation (writing posts) I think it comes down to interface again. With a good interface the user shouldn't *need* education; it should be clear what to do. Obviously that doesn't apply to all apps, but I think in CMS/blog ones it should.
Finally, change always seems simpler before you've started doing it. In each case where a CMS was employed, it seemed like a straightforward thing to implement. As with anything, the devil's in the details. By the time you're done, the impact could net more problems than benefits.
Yes, I agree with this one. I can't say for definite whether it will work or not -- I think it will, but will only know by trying it out. I'd echo my above offer though.
Now, I wouldn't say all of the above would happen with WordPress. I've never used it for anything non-trivial, and besides, the present proposal is to use it only for managing the news.
I also wouldn't say the present system is without flaws, or that it couldn't be improved on. I'd love to not have to log into the website in order to deploy a change. It'd be sweet if the news items could also get generated into an RSS feed. But it works, I understand it, and it doesn't require much administration.
Would adopting WordPress make it easier for some users to post news? Well, almost certainly. Would those people actually post news? Given that they're not posting news now with the current system, this doesn't seem to be quite so clear.
I think people tend to mis-estimate the "work" involved in adding news items to a website. Looking at most websites you notice that the news items are short blurbs, maybe with a few links. Seems simple. One would assume most of the effort is taken up by operating the levers to get the item into the site. The first time you post news, that's probably true - you have to learn what script to run, what file to edit, etc. But after you've done it a few times, the mechanics are trivial. You can rely on finger muscle memory to do it.
The real work is in actually _writing_ the news item. First, you have to notice that something is newsworthy. For most people, they simply aren't thinking about that; they probably just jot a note to the mailing list and leave it at that. Second you have to understand it. Often our news items are highly technical (i.e., involve new features with new jargon). Next comes the writing. If you're really lucky, you can cut and paste the item, but most of the time you have to rewrite it; it could be too long, or written in first person, or assume knowledge from the reader that may not be there. Then some other formatting work (adding links, imgs, etc.) Writing two or three news items can easily take up half an hour. Committing the change and pulling it up on the website is the easy part, and only takes a minute or so.
Thus, if I had to guess, I'd bet that changing the technology for managing the news will not necessarily result in more news getting posted (at least, not over the long term). I definitely could be wrong, though, which is why I had been keeping my opinions to myself. Sometimes technology actually does have a big impact - wiki is a good example. So despite my skepticism I'm keeping an open mind. I definitely don't want to be the stubborn old man sitting in the way of progress! (8^[=~
(OT, but wow is that a cool smiley ;)
Anyway, that's the long dissertaion explanation of where my mind is. Basically, if WordPress will ensure we get more people frequently contributing news, then that's good thing, but otherwise, I'm comfortable with the current system and happy to continue playing journalist. If we go forward with WordPress, and it enables people to take over doing news directly, then great, I can devote that time to coding instead. ;-)
You've explained some very real and valid issues. I agree with some, and disagree with others, but when it comes down to it, I think we'd all agree that the only way we're actually going to know whether WordPress works for Inkscape is to try it out.
Therefore, on the basis of my offer above, I propose that we implement it and evaluate the usefulness of the system after a few months. If it's considered useful then we can stick with it, if not then I'll put us back to the current system. Ultimately it's up to you, Bryce, but I think that would give us a "win-win" situation where no-one should be any worse off if we *do* implement it.
Let me know what you think.
Regards, Jon