It’s at a stage where I’d encourage brave technically minded users to do real work with it, with the caveat that it’s still an early alpha version, no guarantees, back up your style regularly, etc…
Please let me know if you have any suggestions or bug reports.
I’m not really remembering, or don’t know, how the current design
relates to the ultimate goal; what real, average, users will see in
the end. But I’ll just say it:
I don’t think the current UI is any easier to use than using a good
XML editor (though the live previewing is definitely awesome).
The cross-reference between visual form and style code is invaluable.
This will save anyone charged with maintaining production styles of
any degree of complexity a huge amount of time.
Fair enough. But it won’t work if the editor itself is too complex.
It’s very well done work, but it still represents quite directly a
complex and abstract model that will be hard for people (even me) to
grok.
Of course, if this is just to the first stage towards something
simpler, then nothing to worry about.
For example, the “search by example” tab is evolving nicely.
First, a little thing: I think we want a link like “create new style
based on” link.
Second, I’ll just remind of the most overwhelmingly common use case:
User searches by example, and finds something very, very close to what
they need, but not quite there. Let’s say everything is correct,
except that issue numbers need the parentheses removed.
So I’m trying to do this right now: edit a style (APA) that has issue
numbers with parenthesis affixes. It should take me two seconds to do.
But I can’t find where the parentheses are.
Really?
Citation 1 → select article-journal.
Click on issue number in cite sample.
Delete parenthesis.
Done.
Yes, really. That didn’t even occur to me. Why should it? If I click
a journal article on the output example, why do I have to find some
hidden other place to select, well, a journal article?
When the time is right, ideally we’d do usability testing to assess.
Is there any possibility that Mendeley and/or CNMH could hire or
corral some students to do this? Sit them in front of a monitor and
ask them to do one task: the edit an existing one I laid out here.
Record their interactions with the UI, and time how long it takes
them.
If I could edit punctuation directly in the output example, that would
solve that problem.
But then consider changes that don’t involve punctuation.
The UI provides access to every attribute of the node, and illustrates
the effect as changes are made.
Or is your point that style examples should be editable directly,
without revealing the nodes at all? If so, I think that would be bad
design; surely users need to be encouraged to understand and work
through the abstract model. It’s the most concise language we have
available for describing citation requirements with any degree of
precision.
I guess I go back to the argument I’ve been making for the past few years:
Users won’t be bothered with these details. They just want the stuff
to work, which in this case means to match the output they expect.
Consider the use case again: a not-terribly-technically savvy, and
very busy, junior faculty member who has to submit her article
manuscript to Journal X. There’s no such style, and she’s really
stressed. She just needs the damned thing to work, ASAP. She won’t
spent three hours (if she’s lucky) learning the CSL model, and how to
use it in a very complicated UI.
I don’t think a direct representation of the model is consistent with
making this user happy, which should be our goal.
I think allowing users to select different macros–or even better to
have the software do it for them as la Simon’s proof-of-concept–is.
To be clear, these aren’t mutually-exclusive. The current UI could
simply be an “advanced” editor to create new macros, and edit existing
ones.
Bruce
