Graphical CSL Editor

CSL Development
1

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.

2

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.

Cool!

The most difficult issue involved IMHO is representing the conditional.

Yes.

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
EndNote’s:

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="author"/>
   <text macro="title" prefix=", "/>
   <text variable="volume" prefix=", "/>
   <text variable="container-title" prefix=" "/>
   <text variable="page" prefix=", "/>
   <text variable="locator" prefix=": "/>
   <text macro="issuance"/>
   <text macro="access" prefix=", "/>
 </layout>

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).

Right.

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
release.

Cool!

Bruce

3

This looks interesting - I tried a few options, and initially I tried to go
with a simpler layout that followed the XML a little more. I didn’t get very
far as the XUL tree control defeated me, but what I had in mind was
something like this

Julian.

4

I’ve got an idea that builds a bit on what I said yesterday re: macros.

What if as a first (or next) step for a CSL creation utility we
considered a makebst-like wizard. I’ve suggested this before, but the
new macro support would make this more powerful and flexible.

The core of the layout logic would consist of putting together
pre-assembled macros. We create that gallery of macros by extracting
the macros from 10 or so normalized core styles: APA, Chicago, etc.

So consider that perhaps the user gets a question like:

“The bibliographic entries look most like:”

… and then get a list of, say, four choices. When they choose one,
the UI assembles the list of appropriate macros.

So this idea relies on the fact that most styles build off of existing
style. And it should be simple enough that any user can use it. If
there are minor tweaks that need to be made, they can be done by hand.

I’m not exactly sure of the interaction details (might be good to look
again at how makebst does it), but does this sound like a good idea?

Bruce

PS - See http://www.ctex.org/documents/packages/bibref/makebst.pdf
for more on makebst.