Graphical CSL editor

[simon]

Mockups and ideas:

• Bruce's MakeCSL ​mockup and ​proposal (and the associated ​discussion on the xbiblio list)
• Dan Stillman's ​GUI idea
• My GUI idea (​thread here, but my post looks like it got truncated in the archives, so I'll repost here)

Existing implementations:

• Peter Hedlund's ​prototype editor (QT)
• Maxime's ​style generator (web-based)
• Johan's ​CSL editor (Cocoa; now obsolete)

[simon]

From: Simon Kornblith <simon@…>
Date: January 4, 2008 5:17:42 AM PST
To: development discussion for xbiblio <xbiblio-devel@…>
Subject: [xbiblio-devel] Graphical CSL Editor
Reply-To: development discussion for xbiblio <xbiblio-devel@…>

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.

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:

This requires that what's inside <layout> 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.

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.

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.

Simon

[bdarcus]

Just to clarify the "didn't like" issue, it is generally this:

I don't think it makes a lot of sense to force users into dealing with low-level details (variable calls and conditionals) if it's not necessary. Doing the type-based configuration a la Endnote is doing that, and it is likely to make styles more difficult to create and edit, and the resulting styles less robust (b/c you're then forced to go through the trouble of configuring every type).

We have one thing that Endnote's style language does not have, and that is macros. A UI should exploit that.

Max's interface has come a lot way, and it no doubt needs further work, but I think the basic approach of a single list of macro calls that gets tweaked as needed is worth exploring more. It might turn out to be much simpler.

[dstillman]

​http://editor.citationstyles.org