But I woke up this morning with a bee in my bonnet, and have spent essentially the entire day writing. It's all over on the Querki Project Development Journal, and you can go there to read it, but here's the gist.
First, there's a short entry on Blogs. A blogging system is going to be one of the early use cases, and I just came up with the first feature that is, I believe, a genuine improvement over the platforms that are out there. The main point of implementing a blog in Querki is to demonstrate the system's flexibility, so this should do that nicely.
Then there's a *long* discussion about Conversations. All of my long-time friends know that this is a passion of mine, and I haven't done much on it since the CommYou days, but it's going to come back with a vengeance in Querki. The topic got broken into four posts:
- Conversations and CommYou lays out my history with the subject.
- Querki, Comments and Conversation discusses what "conversation" means in the context of Querki.
- Conversation Threading Models recaps my long-ago discussion about how threaded conversations work, and describes the light-threaded model used by CommYou and Wave.
- System and Method for Presenting Complex Threaded Conversations on Small-Screen Devices is the anti-patent that started this all off, laying out how to manage serious conversation on a smartphone.
I suspect that her problem with LJ is mainly due to their recent switch to a Javascript-heavy comment interface, which doesn't play well with outside tools. That *is* an entirely valid concern for Querki -- while I'm trying to avoid being *dependent* on Javascript, there are a lot of fancy things I'm only going to be able to do with it, and comments are one of the biggest danger spots there. So this mostly serves as a salutary reminder that it should be possible to use all the crucial functions of Querki without Javascript enabled. (Which I already knew, but it's always good to be reminded.)
I'm not at all sure how heavy-threading is going to play in an accessible environment. My instinct is that it should be okay -- indeed, my instinct is that, done right, it should work better for accessibility than LJ's light-threading -- but that'll need testing and maybe tweaking.
One long-term advantage for Querki is that I'm already planning an API-friendly environment. There are any number of reasons to provide ways to get into Querki without the "official" web interface, at least for paid users. That in turn implies that, even if the primary interface doesn't work well for accessibility, we ought to be able to come up with a side-interface that does. (Indeed, I could easily imagine us winding up with an alternate, completely Javascript-free Web UI. The long-term architecture should support that if we want it.)
But in the medium term: yes, I'd love to have an accessibility tester or two when the time is right, and I count myself lucky to have a few appropriate folks among my friends. I suspect that we'll be ready to start playing with that around the middle of the year -- after the core functionality is ready, and around when I start really making things fancy at the UI level. I suspect that the biggest danger is going to be that making things easier to use for sighted folks will break accessibility in various ways, so that's when we should start really paying attention to accessibility as well.
(Caveat, though: remember that this is a one-man show for the moment. I can't promise that I'm going to have the cycles to really make accessibility hum until I can hire another programmer or three. My highest priority is going to make sure I don't do anything egregiously dumb enough to make good accessibility hard to implement...)