Click

Update

2012-01-05T07:42:00.000-08:00

Somebody is now bugging me and wants to use the software. That Is Good. Also, a new release is scheduled for the end of the month, and will include a bunch of updates that make the community oriented version much nicer. Even Better.

Oh, and our own primary installations are running on Lighttpd and PHP 5.3. Still some old Apache in there, and it will always be supported, but the Lighttpd is great for Click. PHP 5.3 will likely become a requirement if it isn't already (it is in the dev version). Upgrade your PHP, it's good for everybody.

I also had a high level request about a project later this year that's doing some neat work that is ideal for Click: quasi-wiki related, but not text. The ability to add custom relational databases (as in "storing relations between entries", not "SQL-ish relational"¹) will be perfect for them.

Honestly, as I'm the only real user of Click, having other people use it will make it much more robust for all other use cases. I'm quite happy where things are going.

___
1 - Okay, technically, they are stored *in* a relational database, so they are relational both ways.

Is it soup yet?

2011-09-06T23:37:00.000-07:00

Kind of a freeform mental dump:

Apps are finished. I now need to update some of the API, mostly UI. Notably gizmos are about half done, after a long evening at Dennys. They would be nearly done, but I need to make them aware of context changes for when AJAX loading is turned on. AJAX is the "thread safe" of the web -- you need to be aware that things can change on you while your one bit of HTML or JS trigger sits there. That, please note, is not why I compare it to "thread safe", but rather the fact that you need to take that into account from the beginning or you'll wind up having to kludge or rewrite your code later.

Right now there's a useless and taunting frame that floats around gizmos on -unstable, but that should be working shortly. I tossed it up to get some UI feedback and see if it was an obvious interface. Sarah poked without any hints and instantly figured it out. Her precise words: "Oooo... it's very pretty. It reminds me of the iGoogle page, only it's not branded".

Secret sauce apps are disabled in the code, as I don't yet trust them, but they are theoretically sound and should work fine. I'd like to convert most of the PHP ones over, as that enables the wiki-way for new features. (Secret sauce is that thing I've discussed with some people, and what I'm forfeiting backwards PHP compatibility for.)

Gizmos, Features and Filters => Gizmos 50%, Features done, but 0% in the editor and no secret sauce, Filters 100% done. I have a paid contract to work on the editor, so that'll happen this week, along with a new server. The new server will be running Lighttpd, so we'll have production sites on both Apache and Lighttpd. Right now I'm running Apache on my office dev machine and Lighttpd on my laptop anyway. I know a local PHP dev who likes Cherokee; I'll have to bribe him with beer to provide docs on getting it running under that.

Speaking of docs, those who have offered to help write end user documentation will be called upon as soon as the editor is done. Luckily I know a couple of you are danged prolific when handed a documentation project.

Oh, and Tango was officially moved into the source tree tonight as the default icon set.

Sign by the side of the road

2011-08-16T16:46:00.000-07:00

It was pointed out that it's been awhile since I've posted, partially because I went to a wedding and came back with a persistent flu. Here's the current rundown: Planning to merge -experimental and -production within the next week. At that point I'll update the (now fairly outdated) test wikis. This means there will only be one codebase from now on. And this time it should stay that way.

Critically, this will make user, site and server admin uploaded apps live. That will mean that the core engine and features can progress independently. And people can write new features without having to bother with PHP or the build system. Apparently that means "quick search feature for tentacle hentai", according to one person. Luckily, while you can share apps, you can't force them on anybody (unless you're the site or server admin).

Possibly included, depending on ThePaidWorkLoad:

Rejiggering the build system so that XDebug works again.
Basic documentation for the various exposed data you can call out (see also JS apps).
Basic documentation, period
Drop 5.2 compatibility. (If not now, very soon)
A new slick signup and login system.

Like a fortune cookie

2011-06-30T14:06:00.000-07:00

Click now works under Lighttpd. ^{(in bed)}

When it hits the fan.

2011-06-29T16:22:00.000-07:00

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.

Interlude

2011-06-21T22:42:00.000-07:00

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.

Think about direction

2011-06-20T23:50:00.000-07:00

"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:

First, it's setting up a habit of public communication. If a community does develop around this little project, I will be used to public rumination and proclamation so that I am never in a situation where I surprise anybody. Second, somebody tripping across this project now has a bit of background to where it came from and a feel for the overall momentum. And finally, third: I write to form my own philosophy about what this project is.

Back in 1994 or so, I started writing interactive websites. In 1997, I had a nice one that caught the eye of a fellow who became my business partner. We started helping newspapers in small towns. Today we're basically doing the same thing, only instead of print with the added bonus of on-line, we're offering primarily on-line services with the bonus of print. Seven years later, I got involved in Davis Wiki, and then Wiki Spot, which has a similar focus. The Local Wiki project aims for that space (and it's a great project I support), so what does Click aim for?

I'm not sure. It's a cool platform, even stripped of the commercial filters I've written for it. I think it is a good fit for very specialized communities who have unique needs. If a wiki is a chisel... a single, simple tool... then Click is a Dremel. It's a little more complicated, but not so much that you need a manual (hopefully!), and ideally it'll come with a full set of specialized tools to fit your specific need. The hurdle will be making that easy for people to comprehend and also to share custom tools. Kilt patterns, RPG character sheets, heraldry... there are a slew of specialized needs out there for small groups. And hundreds of each of those specific types of those small groups over the world.

I think that's a different enough goal (or at least my approach is different from the other wiki-model solutions out there) that it's worth pursuing.

To add to that, I'm going to try to get somewhat idealistic about the decentralized model. Not because it's important that I do it with Click, but just the conviction that somebody should be working on that. If we're serious about localizing the information on the web and empowering local groups of people, what good it is if a Facebook or Google login is required for full access to our knitting or kilt group's information? And why can't local communities form networks a la the big players? We are as technically savvy. And, like the hats on Doctor Who... we're cool.

Stand in the Place where you Live

2011-06-17T12:29:00.000-07:00

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")

Glinda, the Good Bug

2011-06-02T12:43:00.000-07:00

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.

Okay, now the code

2011-06-01T12:43:00.000-07:00

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.

First Production Site

2011-02-18T07:16:00.000-08:00

The first production site under the new code is going to be demoed in an hour. It's a commercial site, but the theme is based on one of the new community themes. The community sites will be opened up in the next day or so. I still need to get a repository (show me the code!) set up, but that is somewhat secondary at this point.

Woo! Sites are being created. It's coming together right now.