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"1) 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.
Thursday, January 5, 2012
Tuesday, September 6, 2011
Is it soup yet?
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.
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.
Tuesday, August 16, 2011
Sign by the side of the road
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:
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.
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?
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.
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.
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:
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:
Subscribe to:
Posts (Atom)