Previous Entry Share Next Entry
Release 0.10.5 -- Keeping Dad happy
jducoeur wrote in querki_project
Unsurprisingly, my father (who I essentially apprenticed to for my first 5-7 years of programming) is one of the early Querki users -- he's keeping track of his wine cellar in it. He was visiting last week, and mentioned that he thought the edit process was still pretty sucktastic; that confused me for a minute or two, until I realized that I'm not actually using the default edit tools in any of my major Spaces any more, so I hadn't been paying them much mind. I've been mainly using the new Thing Editor, via the [[_edit]] function on customized pages; while I won't claim that's perfect, it is *much* better than the old Editor. He's been using the latter, and yeah -- it kinda sucks.

So the focus for the past few days has been on bringing those capabilities into the default workflow. Specifically, the old Editor is now called the "Advanced Editor", and isn't normally used for Instances any more -- instead, in all of the places where you had been getting the Advanced Editor to work on an ordinary Thing, you now get the new Thing Editor. The following are mostly in service to that.

You can now get to the Advanced Editor from the Thing Editor: while the Advanced Editor is mostly deprecated, it *is* still much more powerful and flexible than the Thing Editor, and if you want to do Deep Magic you still need it. So I added another button to the Thing Editor, which shows up when you mouse over -- this shows in the upper-right, next to the Trash button, and takes you to the Advanced Editor for this Thing. I don't expect you to need it often, but there will likely be occasions when it is still critical, at least for the time being.

While I was at it, I changed the "x" to delete this Thing from the Thing Editor into a proper Trash icon. We may as well be consistent in our visual language.

Editing a Thing now shows the Thing Editor: now that you can get to the Advanced Editor when you need it, it's time to stop using it most of the time. So the Edit button on each Thing's page, next to the page title, now opens up a Thing Editor in-page. It's not fancy or anything -- it just inserts the Thing Editor at the top of the page -- but it means that you can use the easier-to-use Thing Editor by default.

Along with this, I formalized the "Done" button at the bottom of the Thing Editor. This now says "Done", with an arrow to signify that pressing this button takes you to the current view of that Thing. Mind, this is *not* "Save" -- the Thing Editor live-saves as you edit -- but folks have convinced me that a "Done" button is both comforting and useful.

IMPORTANT: there is an outstanding bug that, if you are in the middle of editing a text field when you press the "Done" button, the edits to that text may be lost. I will be fixing that problem soonish; in the meantime, be careful to tab or click away from the text field before pressing "Done".

To support the "Done" button, I introduced the [[_mixedButton()]] function, which shows a button with both an icon and a label. This is, frankly, a temporary hack -- once Querki functions have named parameters, I plan to merge _iconButton() and _mixedButton() into _linkButton(). But for now, it gives a way to display a button like this, and that seems to be useful for usability.

Creating an Instance now uses the Thing Editor: this was actually the biggest change, because it's a major shift in the data flow. Previously, you pressed a button, and that took you to the Create a Thing page, which was basically the Advanced Editor, and nothing actually happened until you pressed Done. Now, it's been brought in line with the Thing Editor: when you create an Instance (in any of about eight ways), it creates the Thing *first*, then shows you a page which simply shows the Thing Editor so you can edit it as you see fit.

This isn't the final word on this subject yet -- I expect to gradually make pages more or less live-updating, so that as you make your edits, the page content updates to reflect that. (Basically, a sort of "live Preview" function.) But the result is that the Thing Editor is now pretty ubiquitous for Instances, and the workflows should be a lot more pleasant as a result.

Separate Design a Model from Create a Thing: the last step is technically small but conceptually huge. Internally, there is very little difference between Models and Instances, intentionally -- Querki is prototype-based rather than class-based. But I've slowly come to understand that, from the user POV they *have* to be different: the original design, which largely conflated them, proved confusing.

So there is a new pick on the Actions menu, Design a Model. For now, this just takes you to the old Advanced Editor, but that will be replaced in the nearish future by a new Model Designer, which will be *very* different, and much more customized to this problem.

Finally, made Querki pages decently printable: this one had nothing to do with the edit workflow, but is another problem that's been bothering Dad for a while, and I've come to agree that it's critical. Plain and simply, Querki pages print really, really badly. It's actually even worse than you might think, because all of the contents of the navbar at the top turns into a big list of links when you print -- that is, the printed version not only includes all the cruft you don't want on a printout, it includes all of the cruft in really ugly form.

Fortunately, CSS to the rescue -- I had begun to realize that you can have a completely separate stylesheet for printing, and used that to implement a quick first draft. It's not at all fancy yet -- in the long run, I plan to have capabilities to be able to define your own print templates, control details like whether to print Conversations, be able to print multi-page reports of all the Instances of the Model, and stuff like that. But it's a surprisingly decent quick pass, and takes the printouts from "horrible" to "usable". The printout omits the top navbar and the nav links at the bottom, and various other links and buttons that aren't very relevant in a printout. The result is a bit spartan, but functional and clean.

Note that you can use the same trick in your own Space in order to fine-tune the way your printouts look, by defining a print Stylesheet. If anybody cares to do so, ask and I'll be happy to provide guidance. In the meantime, though, Querki pages should print well enough to be basically usable.

So -- the benefit of having people doing real stuff in Querki is that I'm getting a better sense of what *needs* to be changed, and that's what today has been all about. I look forward to getting more of you involved...


Log in

No account? Create an account