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
>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
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, IMO, answers the performance argument extremely well.
>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
>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
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
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
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
(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.
Jonathan Leighton aka. Turnip
http://turnipspatch.com/ | http://digital-proof.org/