*God*, I love this project

[jducoeur]

I'm rapidly fleshing out the Querki Use Cases and Features. The Feature list is growing terrifyingly fast, but that's what the Use Cases are for: they are going to help drive which features get implemented when. (And more importantly, which features to *not* implement yet. I'm going to have to pick my battles carefully. Nothing gets implemented until we have a concrete use for it.) I'm starting to sincerely believe that this will be useful enough that people will buy memberships.

I think I'm going to start talking about Use Cases, something like one a day, over on the development blog (querki_project). Please come join in over there, kibitz and comment, point potentially interested friends at it, and keep the ideas coming! The "what we're going to try to accomplish" train is rapidly gaining steam, and the project is looking ever-cooler and more useful...

Comments

[mermaidlady]

Yesterday new_man and I were talking about how Querki might be the right tool for cataloging our theatre stuff: costumes, props, raw materials, set pieces, lighting gear, &c. Right now it's all chaos.

It's going to be really important that we be able to have photographs (possibly multiple photographs) associated with each item.

[jducoeur]

Yeah, that's actually been on the Feature list from the very start -- actually, because of the Cooks Guild Use Case. I want to be able to do everything that the existing Cooks' DB can do, and that means easy uploading of photos. My current plan is that Photo is actually going to be one of the primitive data types before long.

And in fact, at least a crude photograph capability is going to be needed from the outset, since we'll need it for our wedding invitations. (Which will be the very first App I build.) It'll need a little evolution before it's where you need it, but I hope we'll be ready for what you describe by April.

But good point. I'll add this as a Use Case -- this sort of ad-hoc "where *is* everything?" App is very broadly useful, and you're right that photos will often be needed. Thanks!

[jducoeur]

Okay, that's now recorded as a Use Case: https://github.com/jducoeur/Querki/wiki/Use-Case-Inventory. Thanks for the suggestion -- should be broadly useful to folks. When we get to that point, I'd love to work with y'all to make sure I build it usefully...

[mermaidlady]

Yes, I'd love to. I'm quite excited about all the potential of this project.

[dervishspin.livejournal.com]

SO I thought you had captured one of the Use Cases I would ask for. It's inherent in the name. Then after reading it I realized I had made an assumption which was not true, so I'll ask a different way.

How about a Requirements Inventory?
Managing requirements for IT projects is... OMG awful. The DBs that are out there are hideous, limited in functionality and expensive. As a result, most companies are effectively tracking their requirements through email and excel spreadsheets. There must be a better, more intuitive way. Someplace that allows multiple people to work on it at the same time. Some way to track which business area came up with what requirement for what system which matches what High Level Requirement or Scope Statement.

I think as you manage your requirements for Querki, you will see what I mean.

Managing Requirements for a Managing Requirements Use Case will probably feel pretty "meta" and strange, actually.

Did somebody say meta?

[etherial.livejournal.com]

It sounds to me like jducoeur has a use case for tracking use cases. I'd start the requirements list with a field for Requirements Lists.

Re: Did somebody say meta?

[jducoeur]

See below -- very nearly the first thing in the plan...

[jducoeur]

One of the very first things I'm planning on building, and have been almost from the start -- that's the Project Management Use Case. I plan on having Querki dogfooding its own project-management system as soon as I possibly can. (Probably early next year.) I'm very sensitive to all of this, having spent fully six months at Memento doing to deep review of all the project-management software I could find. And I have *passionate* opinions about usability for this stuff.

The current vision there is somewhat focused on this project: it is built around the usual Agile concepts (Use Cases, Features and Stories), and is aimed at letting end users vote on which things they consider most important. I don't precisely think in terms of "requirements" per se: instead, the structure is a many-to-many-to-many map of those three concepts. The Use Cases drive which Features to build, and the Stories describe the fine-grained specs and the effort required.

But a more conventional Requirements database would be dead-easy -- indeed, taking out the need for voting means that this becomes a completely orthodox Querki app, requiring few or no special features at all. Once things are basically up and running, let's talk specs -- odds are that I could whip out much of it super-fast. (The only hard part of a more-traditional system is the workflow and signoff side, and I'm already pondering how that engine will work...)

[dervishspin.livejournal.com]

Oh good! Keep me posted. I am probably slightly less passionate than you about the usability of it, but possibly not by much. It is a bloody thorn in the side around here.

"Conventional" would be useful. We use Agile while we can, but we are not an Agile shop across the board so some of the voting stuff is interesting, but not required for most stuff we are doing, plain old prioritization functionality would be good enough.

[dsrtao]

It looks like several of these use cases could be improved by a Feature: Timeline. A Timeline is a list of things that have a time/date attribute, and is by default sorted on them.

Closely related would be a dependency relationship, and a priority list. Combining the three together you get most of project management.

[jducoeur]

Hmm. I don't think of it as "timeline" per se, but the underlying machinery is likely to be somewhere between easy and trivial. That is, Date and Time are planned as very early Types to implement, and showing a sorted list of some sort of Thing is pretty much the most common thing one does in the system. The Blog Use Case is going to depend on this.

Similarly, dependencies are essentially trivial to build in the data model, and Lists are ordered by definition. And the plan is for the UI to make drag-and-drop ordering of Lists as easy as I can.

As mentioned upthread, Project Management is something like the second or third App planned. I want to be managing Querki *in* Querki as quickly as I possibly can, because I am very picky about my project-management tools. I suspect we'll get into some spirited discussion after that about the various *kinds* of Project Management tools folks would like to see, and I'm likely to crank out several variations.

(Really, the data side is going to be dead-easy in Querki. The only tricky part is enabling powerful customized UIs for things like Task Boards -- that will have to come somewhat later...)

[kihou.livejournal.com]

It's cool to see you running with something that's conceptually a lot like my Bazki personal project (http://bazki.mit.edu/, but there's not much there), but sufficiently ambitious and aimed at the real world instead of Assassins' Guild LARPers. You certainly have some nifty ideas.

[jducoeur]

Parallel evolution, and it's neat to see someone else who came to the same conclusions. Querki evolved from ProWiki, the system that I built about ten years ago *specifically* for LARP-writing. I needed something flexible and powerful there, and have been using it for a decade -- it was just too hard for anybody else to use.

When I sat down to write something that would be *easy* to use, I started realizing just how broadly useful it would be. But I still expect LARP design to be one of the major early use cases, at least for my friends...

[kihou.livejournal.com]

Sure, but "LARP-writing in general" and "for the Assassins' Guild" are not quite the same thing. You probably don't have mandatory features like:

* Subversion text file interface, or similar
* LaTeX-ish markup support
* LaTeX=>pdf rendering support

Presumably Querki will at some point give me enough rope that I could consider migrating to it, and it's presumably going to be much slicker than something I'm going to put together myself. And the multiple-app nature of it probably would be a cleaner way of handling the separation of "Game Content", "Player Apps", "Per-run State", and "Runtime Interface".

[jducoeur]

Heh. True, although it'll have native versioning, so the Subversion aspect isn't entirely relevant. The LaTex support is a more interesting question, though. Fancy printing is still an open question, and that's an interesting way to support it. I may well decide to open that widely for plugins.

Anyway, once it gets mature enough, we should talk features in more detail, and see what else is needed to make it feasible for your use case...

[kihou.livejournal.com]

The Subversion support isn't just for versioning; it's also to satisfy people who don't want to use a browser or learn a new workflow. (The Guild has both large "hates anything non-commandline" and "hates the commandline" contingents.)

LaTeX for the PDF export is mainly because then I can use our existing code for rendering pretty item cards, etc and be at prettyness-pariety with standard (i.e., GameTeX) games. I don't know what other options there are for pretty PDF, but it seems likely that you'll want some option there. (If I'm keeping my recipes there, I also want to be able to get the same recipes in a pretty book.)

[jducoeur]

Yeah, the requirement is clear -- many use cases will require nice printing. But it's a big, complicated problem, so I'm being careful not to jump to any conclusions too quickly. Coming up with something that is flexible, powerful and easy enough for normal users is going to be somewhat tricky. (Similar to the page-layout problem, but much more persnickety.)