Thursday, June 30, 2011

Wednesday, June 29, 2011

When it hits the fan.

So software should be really easy to use. That makes sense.

But what happens when things go horribly, terribly wrong?

I have a nice fatal error system that dumps a pretty error message to the screen (or, if possible, your own "site is down" message and sends the error to you via email, but I'm guessing most people won't bother). The problem is that fatal error messages have two entirely different audiences: the people who don't care and just want their site up, and the people who can fix the site. The former outnumber the latter by a extremely large margin (hopefully), so is it really useful to have something like the following?

"Either you need to reconfigure your site.ini, or contact your system administrator and tell them that you need to install PHP support for SQLite." [1]

Grant you, this particular error is only likely to occur when you're first installing the software[2]. Balancing those "helpful to sysadmins only" messages with the fear and distrust engendered in users when they see something they don't understand but "feel is bad" is a very real quality of experience issue. It's something we need to design for: what the user experience is like when it breaks down. Alas, super friendly is seldom helpful to an admin trying to get things working again.

Sycamore either does a Python dump or a fairly unhelpful (but friendly!) "Hang tight, we're restarting something!" message. Wikipedia has a nice help page that points you at a website where people can detail the problem. But there's no great solution. When things break, you're looking at either a generic cheer up message (the Fail Whale!), or a really hairy guru meditation (a stack dump).

In the end, I'm going with happy, unique phrases and using them for support. A search for any should get you a useful help page (whenever somebody writes them... this is in theory right now!) On the other hand, if you are confident and know what you're doing, make a fail whale and have a happy, soothing error message... after you've configured your software to mail you when things go pear shaped.

Of course, working with what I have, I've made the error as visually calm as I could, in a soothing presentation on a sea of pastel green:



Of course, it's going to be dubbed the "green screen of death", and be the focus of anger. But at least it will be pastel anger.


____________________
[1] - No, Click doesn't preferentially use SQLite; this specific error is from the SQLite data module, for those who might want a "desktop wiki" without running a real database. I tend to use MySQL, but any relational database should work.

[2] - obWorry: There's a third possibility, if you've keeping your site configs in a database, but that situation should scream and die before this error.

Tuesday, June 21, 2011

Interlude

Quick note today, even if it was a bunch of stuff done. Cleaned up CSS tonight. All themes were made by me to date, and there were some snarly issues that would have tripped up anybody else trying to make a theme. Now it's all nice and clean.

Also, this allowed a couple key changes that consolidated CSS. It's not minimizing or caching, but that'll be a quick and easy thing to add. Plus I can revise the JS combiner/minimizer at the same time. I'm not really worried.

Work toward a default theme is nearly done, with Jason working toward HTML5 compliance (I just sent him the file and he had no problem with the custom tags, which probably points to things being as simple as I had hoped). Good timing, with the HTML5 video function in place.

Pivotal's list is shrinking quite quickly.

Monday, June 20, 2011

Think about direction

"Wonder why you haven't before"

Okay, so to continue with the REM lyrics, tonight was setup and direction night.  Things are still a little broken - there's a reason the current version is unstable, and there is no stable  - but I set up clickwiki.org with the bleeding edge version.  The decomposer is an unholy Frankenstein of DOM and parse, the composer is parse (they will eventually both be DOM), but that's just half the fun.

Pardon me as I dump the state of my brain: it is nearly 2:00am my time, so I'm a bit fried.

As I said in my last post, at least one person whom I was careful to keep up to date was blindsided, which sucks.  So now I'm sending emails to a nearly empty list, blogging here to nobody in particular and setting up a wiki documenting... okay, I do actually have a few people using Click for some small communities.  And perhaps the documentation will eventually be good enough to point commercial clients at (although, as I've said before, most aren't using any of the features that wikis would be).

Why am I speaking into the void?  I will explain to you, my non-existent reader, as the answer is three-fold:


Friday, June 17, 2011

Stand in the Place where you Live

Hammered with work -- both the kind that pays the bills and unexpected social commitments.  Some (non-business related) people are using the new Click and I got some good, positive feedback and some UI complaints that are exactly what I was looking for.  I also got some interesting and very unexpected communication that indicates I'll have to clearly define the project goals a bit more.  Which is generally a Good Thing.

By the way -- always assume that people will never look behind the first tab in a given interface.  And I'm looking up at the blogger interface and noticing the same problem.

(re: title: "Now face North")

Thursday, June 2, 2011

Glinda, the Good Bug

I'm going to try and finish cicada, the Click installer to install clickwiki.org (which, as of this post, just has a static html placeholder). To date, I've set them up with mkwiki, which is a bash script that sets up a site on my servers. cicada is a PHP installer that allows you to set up a site from scratch, setting the fundimental aspects (title of site, first siteadmin account, load a skeleton for the type of site, check directory permissions, etc). The benefit is that anybody who sets up a local copy will have a tool that provides a known good install. This also means that installation errors can be fixed on our end by updating the installer.

Worst case, if Friday evening rolls around and I don't finish, I'll just install using mkwiki.

Oh, and cicada was documented and speced out quite awhile ago, but amusingly is being finished as my office in Tennessee is surrounded by the noisy little things.

Wednesday, June 1, 2011

Okay, now the code

Community sites have been up for a whole cycle of development — plus the commercial sites which have been using the codebase for years and the open source fork for the last three months — and now the code is being released.  I had to meet with my business partner and explain things to him.  He's enthusiastic.  We had a partner many years ago who hated open source, not understanding the benefits, but he's moved on.

I moved a ton of stuff out of the 000 directories, which were used as my "notes and garbage" points, similar to ATTIC.  I probably moved too much out, but that's fine... I can always move it back in.  I then backed up the old codebase (which was handled with Bazaar) and initialized the open source code under Mercurial, creating a new starting point.  Meanwhile the commercial code (coupon and proprietary syndication stuff) is in a distinct codebase.  I'm 98% sure I split the two with no dependencies.  But then, that's what testing is for.  And we've had a few commercial sites using it for three months with no problems.

Now the support site (clickwiki.org) and such need to be set up, configured and filled with content.  Lots of work to go... a healthy open source project does not consist merely of code.