Previous Entry Share Next Entry
Release 2.2: Apps
querki
jducoeur wrote in querki_project
Meta-note: given the recent exodus of a lot of Querki's early adopters from LiveJournal, these release notes will probably move somewhere else in the not-too-distant future. I might move them to DreamWidth, but unfortunately, I gather that communities don't have the same DW-LJ crossposting capability as personal journals, so that's not an obvious win. Alternatively, I might finally implement RSS for Querki -- a feature that has been planned for at least 3 years -- and begin to maintain this log *in* Querki proper, with feeds in other systems. Opinions welcomed.

It's been fully two months since 2.1.3 -- that's partly because of the holidays (I was away for the bulk of December), and partly because I've been heads-down focused on the big new feature. It's not perfect, but I think it's good enough to start trying it out on real Spaces, so here we go...

New Feature: Apps

Apps are the last of the Big Central Features that have been in Querki's design from the very beginning. Querki has always made it (relatively) easy for you to build a custom Space to manage your data for a particular problem; Apps are how you let your community (and maybe others) create their own versions of that Space.

I'm not going to go into full documentation here: the feature is new enough that I don't recommend everyone go lifting Apps out of their Spaces until I've done it for a bunch of mine. But here are the broad strokes.

What is an App?

An "App" in Querki isn't quite the same thing as on a smartphone, but the concept is close enough that we decided to use that term here. You generally don't write an App from scratch; instead, you build a Space that works, and then you extract an App from that Space. This "extraction" shouldn't visibly change your Space much, but it actually makes some pretty radical changes -- it creates a new "App" Space, takes the Models and Pages from your Space, pulls them out into the App, and then converts them into "shadows" in your Space. Basically, the Things in the App are the "real" versions; the ones in your Space now inherit from those. The App is a new Space, owned by you, containing the *structure* of your Space; meanwhile, your *content* remains in your Space.

That being the case, you can then share the App with other people: they can easily create their own Spaces from the App. Their Spaces will have the same structure as yours, but they can populate them with their own data.

Of course, Querki is all about customization, building Spaces to suit *your* needs. This is what makes Querki Apps *really* different from the usual concept: everyone who uses an App is free to customize their own version as they like. They can add their own Properties, Models, Pages and so on. And while it's not yet implemented, they will eventually be able to take their own changes and suggest them as enhancements to the shared App.

(The programmers who work in the open source world are now going, "wait -- you've reinvented GitHub". Yeah, kind of, albeit with a lot more structure and a lot less incomprehensible jargon. I've intentionally adopted a lot of git's better ideas in the design of Querki Apps.)

Creating an App

Like I said, I don't recommend trying this *quite* yet. But for the brave, here's how you create an App.

To begin with, all Spaces now have an Info Page. You'll find a little "i" icon on the root page of your Spaces. This takes you to the Info Page for this Space. (There isn't yet a good way to actually *write* this Info Page, but that's coming shortly.)

On the Info Page, you'll find an "Apps" section; under that is a button labeled "Extract an App from this Space". Clicking on that takes you to the Extract an App page.

The Extract an App page asks for:
  • The name of the App

  • A one-line summary of the App

  • A more detailed description of the App
All of these are required.

In addition, it displays a list of the Models and Pages, as a tree-structured checklist: if you open one of the Model nodes, you'll see the Instances of that Model, usually unchecked. This allows you to customize exactly what will be extracted to the App. In theory, you shouldn't usually need to customize this -- I'm trying to set the default up so that it's usually what you want to do. But you can check and uncheck items from this list, to build the App you want.

Once you've filled all that out, click "Extract App from this Space", and it will create the new App.

That's it! The whole point is that, once you've built the Space, pulling out an App should be quick and painless -- literally a one-minute operation.

(There's also a new App Gallery; your App currently gets automatically enrolled there, but I'm rethinking that decision. It's likely to become something you do more deliberately.)

Instantiating the App

Once you've created an App, how do other people use it? Well, after creating the App, you're taken back to the Info Page of your original Space, which now lists the App. (Eventually, it will be possible for a single Space to inherit from many Apps, so you can have "mixin" functionality.) If you click on the App, it will take you to the Info Page of the App, which will show the Summary and Details that you entered when you created it, along with a button to "Create a Space". Press that, and it will ask you for the name of the Space you want to create. Fill that in, hit the "Create" button, and *poof*, you have a new Space based on this App.

You can share the Info Page's URL with friends as you see fit -- this is really the point, and I encourage sharing. You can also create multiple Spaces yourself, based on the same App; that doesn't make sense for all Apps, but sometimes it is really useful. (Imagine, for example, specialized Inventory Spaces for different collections.)


I'm going to be playing with this stuff extensively in the next few weeks; you'll probably see me announcing Apps for people to use on various appropriate forums. I may well ask some of you if we can extract Apps from stuff that you have built. It's exciting times -- this is the feature that is going to allow people to use Querki with absolutely no building required on their own part, just leveraging the work of other members of their communities. It's been one of the goals for Querki from the start; I'm looking forward to seeing what we can collectively do with it.

Revert Space

One of the major concerns about Apps has always been that they do *dramatic* surgery on your Space. In theory, the changes should be invisible, but until we've done it a lot we won't know if there are bugs. And one of Querki's increasingly-central tenets is that you should never lose data.

So along with Apps, I've released another key feature: Revert Space. This was one of the main reasons why History was the feature right before Apps -- Revert allows you to recover if something goes horribly wrong.

For now, you get to the History of your Space by clicking on Actions -> Advanced... -> View History. That's been around since 2.1. What's new is that, if you click on an event, you'll find a "Revert to Here" button. This requires confirmation, because it's dramatic and powerful: if you confirm, it will undo all changes since that event. So if your Space has become broken (due to a bug, or vandalism, or whatever), you can roll it back to before the damage.

Note that Revert doesn't actually *remove* the changes -- instead, it adds a new event, setting the state of the Space back to the specified point. You can later change it to some other point, rolling forward to where you started or somewhere else. I don't recommend going crazy with this, but it's very flexible.

(The open-source programmers in the audience are nodding and going, "still sounds like git". Yep, basically.)

Note that Revert rolls back the *entire* Space at this point. We'll eventually add finer-grained versions, that allow you to reset the state of a single Thing, or even a single Property value. But one thing at a time.

Other Significant Changes

Apps consumed most of this release, but there are a couple of other changes:

Sharing to Facebook now displays the Summary: we're gradually figuring out how Sharing *should* work; historically, Querki pages shared on Facebook resulted in a pretty terrible preview. Now, if you specify a Summary on the Thing, that will be used as the text -- that's often what you want.

Lots and Lots of Unit Tests: it's not obvious to the user, but goes a long ways to making *me* more comfortable with the system. Suffice it to say, I've rewritten some of the core code, that wasn't previously unit-testable (because it was wildly asynchronous) to be friendlier to the test environment. (This uses some of Scala's crazy power, to build things in such a way that code can be synchronous or not, depending on how it's called. It's very cool: buttonhole me about it sometime if you're into neat programming techniques.) The result is that, for example, there is now a proper unit test for Extracting an App, which exercises the real workflow so we can catch bugs quickly.

Started extracting the Gadgets library: mostly interesting to the programmers, I've begun to lift Querki's homebrew UI framework into a proper library, so that others can potentially use it. (We got talking at the Scala eXchange conference last month, and it looks like a fair number of people are looking for a library like this.) This is mainly relevant here in that I've been rewriting some of the details of the UI as I go. Those changes *should* be invisible, but bugs are definitely possible. As always, if you see something that isn't working, please yell.
Tags:

?

Log in

No account? Create an account