Simon Kornblith wrote:
I probably won’t have time to implement this for a while, but, as I
stated in the thread on the is-plural attribute, it might be nice to try
to brainstorm some ideas for a graphical CSL editor. I’ve included some
crappy mockups I tossed together very quickly in Interface Builder to
give an idea of what this could look like, although obviously, the final
interface will need a bit more polish.
The most difficult issue involved IMHO is representing the conditional.
My best shot at a solution is to use a UI like what’s used to configure
mail rules, but with else ifs and elses.
Yeah. Might there be a way for a collapsible UI for this?
Unfortunately, this is a bit clunky for the main conditional. If we have
no objections to structuring the styles with a main conditional on types
(which I believe Bruce disliked earlier, but seems to be the easiest way
to create an intuitive interface), we could use an interface similar to
I’m not sure that’s the right approach; or at least, we’d want to kick
around some alternatives.
Take a look at Peter’s start of an editor. He did a smart thing: created
a separate macros panel. The smarter one’s macros are, the simpler main
layout becomes. For example, here’s the citation layout for the Bluebook
style I’m working on:
<layout suffix="." delimiter="; ">
<text macro="title" prefix=", "/>
<text variable="volume" prefix=", "/>
<text variable="container-title" prefix=" "/>
<text variable="page" prefix=", "/>
<text variable="locator" prefix=": "/>
<text macro="access" prefix=", "/>
Also, macros ought to be able to be shared between styles (think a
gallery of macros).
So imagine instead moving more of the logic into macros, and then just
drag-and-dropping them into the layout field. Of course, you’re still
stuck with the same hairy details of conditionals and groups.
As with your mockup, these are just ideas. I’m curious if Peter or Johan
have any thoughts on this based on his work.
This requires that what’s inside is immediately a conditional,
but I don’t think that’s too big of an issue, as long as we have a UI
for defining macros (which is not hard once we get a main UI down).
It’s easy to convert get CSLs to this format, either by replicating the
fields or defining a macro. The output wouldn’t necessarily be identical
to the input even if no changes were made, but this way, any CSL could
be edited with the editor.
As for actually representing field data, we have many options. One is
simply to use EndNote’s rules, where the fields are just plain text and
a space acts as a field separator (unless it’s a nonbreaking space),
with any punctuation attached to the field becoming the prefix or suffix
(unless there’s a | character to force separation). These aren’t too
intuitive, but they’re well-known conventions at this point (there’s
even a Perl module that formats using them) and they’re easy to implement.
They’re not at all intuitive for non-programmer users though. I remember
as a user being thoroughly frustrated by this.
Another option is to do something like:
Tokens would be dragged to the box, and the areas to the left and right
of the token are the prefix and suffix respectively. To create a group,
the user could add a group token (which could be a different color from
the variable tokens), and then drag variable tokens into it. The space
between the fields would be the delimiter, and all delimiters would
change as one is edited.
I realize the former is easier to implement, but I have to say this one
sounds more user-friendly.
Any comments or further ideas? This proposal fairly ambitious, and I
can’t make any promises to get it done soon, but I think it’s possible
to do in XUL and could potentially be included in some future Zotero