Log in

No account? Create an account
Previous Entry Share Next Entry
The project starts to get a little more real
I decided to spend the past week working on something relatively mellow and easy for Querki, while I catch my breath from the party. So I decided to add one major new feature (Tags, which I've been talking about in more detail over on the querki_project development journal), and then what arguably counts as The First True Querki Space: my Poker Encyclopedia. The first draft of that is now done (as expected, it only took a few hours, mostly on cut-and-paste), so it's time for a burble.

It occurred to me a little while ago that my Poker Variations are the perfect App for Querki: a small amount of mostly textual stuff, heavily cross-linked, with a good deal of somewhat squishy structure. Like so many ideal Querki applications, I've been keeping it as simply one big text file (well, one big wiki page), which kinda-sorta works but not very well.

So here it is. Folks who have been using this wiki page should note that this list is much more complete, with dozens of variants that I hadn't gotten around to recording there yet.

Yes, the look and feel is almost ridiculously spartan. That's intentional, although that's partly because the link above is the "chromeless" version, which removes all the Querki frou-frou and lets you just make the Space look however you like. (This will probably be a paid-user feature in the long run.) To see the menus and stuff, use this link instead. Of course, that's still very simple compared to most sites, moreso because I'm only using a tiny bit of CSS for this Space. In the long run, I'm sure it will get a *bit* more complex, but I'm hoping to keep the pages pretty clean, in contrast to the modern tendency to fill the screen with as much as possible.

When you look at the thing, there's a temptation to shrug and say, "So? It's just a wiki, right?" But the thing is, it's a wiki *plus* a database. Most of what you see here is a single Model valled "Variant"; for each game, I've made an instance of Variant. Variants have useful Properties like Name, Rules, Analysis, Category, Derived From, and so on. Setting up Variant took a couple of minutes of point-and-click.

And the displays are simply generated from that. For instance the page for Seven Card Stud knows that it is itself a Variant (so it shows Rules), but it also has other games that have it as a Category, so it lists them as well. It doesn't need to know anything about them -- the fact that they declare the relationship is good enough. It isn't a page, it's a *Thing*, and it knows how to relate to other Things.

Moreover, I don't even need to define the category at all -- for example, the Stupid Poker Games page doesn't really exist, but defaults to showing all of the games that are tagged as "Stupid". (Yes, we play Mexican Sweat almost every month. It's still stupid.)

That's the key, and it's why Querki was created in the first place. It's for all those trivial little applications that people mostly do in documents or spreadsheets, but which are *really* databases. The goal is to make it easy enough to build them *as* tiny databases, with no more difficulty to create than a document. (And usually with better ease of maintenance in the long run.)

But that's only half the story. What's *really* exciting is what comes next:
  • Pretty soon, I'll be adding the invite system so I can invite people to join in, and it'll become trivial for the other folks at the poker table to edit, update, add new variants and so on.

  • In the near future, we'll develop the ability to have conversations hanging off of any Thing, so we can discuss the variants, make suggestions, and generally collaborate in the Space.

  • A bit after that, we'll add the What's New module, making it easy to track new Variants as they get added. (Right in Querki, as an RSS feed, or in FB/G+.)

  • Then will come the ability to "lift" Apps out of Spaces. That'll be a lot of work to implement, but once it's done, it'll take me maybe five minutes to turn my Poker Space into a general-purpose App that anybody can reuse to record their own tables' ideas.
And so on. The key is that *none* of these features are Poker-specific. The beauty of this project is that there are *so* many useful things we can build here, and all of them will become instantly available to all Spaces.

It's terrifying, but incredibly exciting -- after a solid year on this project, I'm still generating new ideas all the time, and still marveling that nobody seems to be doing anything like it yet. I am really looking forward to opening this up and beginning to bring some of you into it...

  • 1
Neat! A few random comments:

* GoTS2 has what looks like a bug at the end of it: "Created by [_](_)"

* No search function yet?

* No entry based on Assumption? :-)

GoTS2 has what looks like a bug at the end of it: "Created by [_](_)"

Good catch -- yeah, noticed that one this morning. I only added linking through Names yesterday, and it looks like something is subtly wrong there. Not sure exactly what -- structurally, it is very similar to the link to Category near the top -- but clearly something is wrong with the Created By field. The bug is already in my ToDo list.

No search function yet?

Not quite, mostly for efficiency reasons. A brief architectural digression:

Querki is essentially an in-memory database. This has a lot of beautiful implications, not least that a lot of functions like Search can be done pretty brute-force, without all the overhead of a truly serious search architecture. I expect to be evolving Search for years, but I suspect we'll get not-half-bad results from a pretty crude implementation.

*But* there is a very important question of *where* that happens. Querki's scaling is based around the notion that each Space is a little Actor, which is internally single-threaded (and therefore relatively safe and easy to program). All changes are handled through there, but it is very important that heavy processing *not* happen there, lest the Space's thread get blocked.

The right place for Search to occur is in the UserSession Actor, which is planned but not implemented quite yet. This is an Actor that represents this User's connection to this Space. It will contain the session state (which shouldn't be too heavy, but some is planned), and a cached copy (technically, usually a cached pointer, but it's immutable so doesn't matter) to the state of the Space. This is also single-threaded, but it's particular to this user, so blocking isn't a serious problem.

(Well, except for the Anonymous Reader, who doesn't get an individual UserSession -- there could potentially be a lot of Anonymous pointing to a single UserSession. Haven't decided how much I care there, but that *may* demand some refinements to the system, and may wind up with me spawning off Futures to handle Search, in which case the UserSession isn't quite as crucial. But it's still conceptually the right place for the operation -- Search isn't about changes to the data, it's about *examining* the data, and that's what the UserSession is for.)

All of which is a long-winded way of saying: it's designed, and I expect it'll prove extremely important, but I'm not quite ready to build it yet. Given the priority list, I'm guessing about two months, but we'll see.

No entry based on Assumption? :-)

a) We didn't invent the game. b) Not stupid, and trying to keep Querki away from evil elemental forces such as elder gods and Google for a while yet...

GoTS2 has what looks like a bug at the end of it: "Created by [_](_)"

... and that turns out to be a "D'oh"-grade error. Wasn't a bug in Querki at all, just a stupid syntax error on my part while building Variant. That line in Variant was:
[[Source -> ""Created by [[____]]""]]
That is, of course, wrong -- "____" is (sort of) a wikitext-level operator, not a QL operator, and belongs outside the brackets. (I'm slightly surprised it didn't display an error message.) So this should have been:
[[Source -> ""Created by ____""]]
Now fixed.

Of course, that is in and of itself a *very* serious bug, in the sense that a missing feature can be a design bug. It illustrates how important Querki Explorer (which is essentially the interactive query/page designer) is going to be, if even I can make stupid and "obvious" errors like that while I'm typing. While the syntax of QL is as simple and consistent as I can make it, it's still syntax, and you can still easily make errors.

There is so much to do that I'd really *like* to put Querki Explorer off for another 4-5 months. We'll see if that's realistic, though: it won't surprise me if at least a rudimentary version of it proves necessary for folks to start seriously using the system.

(And really, now I have to think about whether the above should be considered a bug at all. It is actually logical, since ____ is really shorthand for a QL expression -- it is essentially a synonym for "[[_self]]", just rendering whatever got passed in. Which may imply that we should be forgiving of "[[____]]" on DWIM grounds. Hmm. I think I need to add that to the ToDo list as a design job...)

"It's for all those trivial little applications that people mostly do in documents or spreadsheets, but which are *really* databases."

As I understand it, this is actually a way that many people used to use MS Access many moons ago. With UI widgets and whatnot, and a built in database behind them, people would design all kinds of applications in exactly this way -- some of whom didn't even know what a database was. (I think the mental intuition behind that was "For things that look like an application, but which are *really* just spreadsheets with multiple sheets and column names" :))

I never had a working copy of MS Access that I could use to see those things, but when I worked with government stuff, it turned out that sometimes people would try to hand me their data, and be surprised when I didn't see their nice, MS Access UI on top of it.

(I think most of those things have been replaced by other things, and poorly, so I do think there is room in this space.)

Yep -- indeed, my father was originally a bit skeptical about the project on the grounds that Access was already in this space. He's used Access a lot over the years, for some reasonably serious projects.

But my contention is that Access, frankly, kinda sucks. It says a lot that I have owned several copies of Access over the years (as part of various MS Office bundles), and I don't think I've ever done anything real with it. That is for a lot of reasons, but the main one is that it still thinks too much like a "database", and as a result it's still too heavyweight for quick-and-dirty uses like this.

Also, client-installed software just looks primitive nowadays. I want always-available access to my data, and it has to play with mobile. I want the UI to Just Work, without me having to build one explicitly -- ever since Rails took over, that's been a reasonable demand. And I want my Spaces to be collaborative -- I've found that, in 2 out of 3 cases, there is at least one other person who I want to be working with on the project.

Now that you mention it, I suspect that MS' newer cloud-hosted version deals with some of this, and I should probably consider them a non-trivial part of the competitive landscape. But I've heard nothing to indicate that they've done a serious rethink, and my contention is that a serious rethink is exactly what's needed. It's time to stop taking the existing tools and trying to make them look somewhat usable; instead, we need to start from how end users *want* to work with their data, and figure out how to make that work...

Yeah, and it's also clear that for the average app that might be able to take advantage of an access-like thing, Querki is going to have more of the bits and bobs that make it not just a Page, but a place to go -- social, etc. -- that aren't even a little bit competitive from the traditional database side. I just found it an interesting point. (This is, for the record, the first post that I've ever actually understood where you're going with Querki.)

Yeah, *explaining* Querki has been challenging. I kind of feel like I'm at the early days of social networking -- it's really hard to convey my belief of why this is likely to be really useful. That's part of why I'm trying to get things up and running as quickly as I can: I suspect it's easier to show than explain...

Access, indeed, sucketh mightily. FileMaker Pro is about two orders of magnitude better at many tasks. But I don't see either one as truly being competitive with Querki, because they may be good at the database that looks like an app perspective, they fall far short of the tools the wiki approach brings to the table.

Yaas, and not just tools but interaction models. Another of Querki's marketing catchphrases is "The First Social Database", and I think that's at least semi-true...

  • 1