Kate and I are getting married in about a year. (Still working out details, but sometime next October.) She has agreed that we can manage the wedding using Querki, *provided* that it doesn't interfere with the schedule, which is fairly tight -- she has overseas relatives, so we need to make sure everyone gets enough time to plan. This makes for a really great use case, because I am *very* motivated to not slip the deadlines.
This actually breaks down into two separate Use Cases, with two deadlines. The full Wedding Management system needs to be running by April 1 -- that's going to be kind of eVite on steroids, but we don't really need it until it's time for RSVPs. I'll talk about that one next time. But the immediate deadline is that the basic Wedding Invitation webpage needs to be up and running by January 1. That is today's topic, and brings us to The First Slice of Cake.
Modern "Agile" software engineering has a lot of core principles, one of which is Release Early and Often -- basically, every couple of weeks you should make sure that you have a system that is *completely* working, well enough that you could theoretically release it. That presents some interesting challenges, since of course it takes some time before your program is going to do anything useful. So we sometimes talk about the first of these releases as "the first slice of cake". It's a very *narrow* slice, but it cuts all the way from top to bottom.
In other words, in a perfect world, your first release does essentially *nothing* -- but does it completely and well.
The Wedding Invitation is going to be our first slice of cake. It takes a ridiculously easy problem -- display an HTML page or three, with some nice styling, which could be whipped out in a few hours if we did it manually -- but does it Querki-style. This means that I'm going to spend a couple of months building the infrastructure that will in the end take about 20 minutes to actually use. But it means that future pieces can make use of that.
And *that* brings us to the point, which is that Querki is, deep down, kind of a wiki. Indeed, that's where it all started: I *had* a wiki for my LARP development, but decided that I needed more power, so I enhanced it about ten years ago to come up with ProWiki. (The name Querki, which I coined seven years ago, is short for "Queryable Wiki".)
There is much, much more after that, but the basic wiki-ish system is the table stakes -- any Space in Querki can include plain old wiki pages, which work pretty much like you expect, with a simple markup language (adapted from Markdown, I think), easy page-to-page linking, and stuff like that.
Of course, the Wedding Invitation means that it *also* needs to be able to use CSS, right from the start -- something that very few wikis allow. You can make your Space look the way you want it. Eventually, we'll no doubt have a community-driven Gallery of styles to use, of course, but the first step is giving you control of your own look-and-feel.
So the Stories for ths Use Case are roughly:
- I can create a Space in Querki, so that I have somewhere to put the Wedding Invitation.
- I can display a simple HTML page in Querki. (A Thing with probably only a single Property, PageText.)
- I can write my HTML page more easily, using MarQ. (MarQ is a planned dialect of Markdown.)
- I can apply a CSS Style Sheet to my Space.
- I can specify CSS classes to use for particular parts of my text, so that I can make them look just like I want.
- I can link from one Page to another. (Using simple QL expressions.)
- I can upload an image into my Space.
- I can embed an image in my Page (using MarQ), so that we can display an engagement picture.