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...
It's going to be really important that we be able to have photographs (possibly multiple photographs) associated with each item.
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!
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?
Re: Did somebody say meta?
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...)
"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.
Closely related would be a dependency relationship, and a priority list. Combining the three together you get most of project management.
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...)
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...
* 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".
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...
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.)