Dear list,
coming fresh from the Easter break, here’s an update on the development of
our WYSIWYG CSL Editor.
The project milestones were set as follows:
M1: Drag&drop prototype
M2: Live-Preview
M3: Additional formatting features
M4: Back-End, CSL output generator
M5: UI improvements
M6: Back-End, CSL input reader (own files)
At the moment we’re around milestone 4, so we’re working on the CSL output
generation.
You can see and try out the most recent state at http://csleditor.quist.de/
This is what should be working already:
• Drag&drop creation of new styles (or two demo styles) with various
document types
• use other document types from the same style as a template
• apply various formatting options to the tokens
• add free text tokens
• check your results with a live preview (currently located below drag&drop
area)
• format fields as detailed and as close to the CSL spec as possible
using a second drag&drop area
• Create the CSL code for the current style (click the “Convert to CSL” link
at the bottom)
A few notes:
• There will be major improvements to the UI soon. You can see the direction
we’re heading in the attached UI mock-ups. We think this goes in line with
the idea of interfaces for both novice and experienced users as was
previously discussed.
• At the moment we’re still using CSL 0.8, but will update to 1.0 as soon as
we make this transition in our desktop software as well.
• A few issues regarding the UI and the CSL import code depend on the
"repository" that will incorporate the WYSIWYG editor. So far, the back-end
has not been part of our development efforts; our last understanding was
that both the editor and a canonical repository of styles will be hosted at
citationstyles.org. Is this still planned/desired?
• Currently every token is transformed into a CSL macro and duplicate macros
are merged so that the generated CSL file isn’t that bloated and should
still be readable. This should also ease the creation of more complex tokens
later on, as Bruce suggested in the last discussion (regarding canonical
macros etc).
• We’d like to start public beta-testing as soon as the UI improvements are
in place, starting by contacting interested users.
We’d happy to hear your feedback.
And FYI: Regrettably, my time with Mendeley ends, so I’m handing over to
Sebastian Arcq, who will be your contact for this project from now on.
Best regards from London & All the best,
Philipp Krieger–
Philipp Krieger | Community Relations
www.mendeley.com/profiles/philipp-k
Mendeley Limited | London, UK | www.mendeley.com
Registered in England and Wales | Company Number 6419015
Jeez, as if it was Friday already… Sorry, I forgot to attach the UI
mock-ups. Here we go.
We’ve used a tool called Balsamiq Mockups (www.balsamiq.com) to create them,
and I’ve attached the XML code, in case you want to tinker around with it.
Cheers,
Philipp
docTypeSelection.balsamiq.xml (20.7 KB)
metadataDialogue.balsamiq.xml (16.7 KB)
[… snip…]
Thanks for this Philipp. Please, everyone that has any time, please
take a close look at this, and provide comments. It’s important we get
the foundations of this right.
I’ll try to get comments ASAP, but it may not be until the week after
next. Just don’t want you to think I’m not paying attention …
Bruce
Hi,On 8 April 2010 19:34, Bruce D’Arcus <@Bruce_D_Arcus1> wrote:
Thanks for this Philipp. Please, everyone that has any time, please
take a close look at this, and provide comments. It’s important we get
the foundations of this right.
I’ll try to get comments ASAP, but it may not be until the week after
next. Just don’t want you to think I’m not paying attention …
thanks, Bruce, we’re looking forward to hear from you (and the others, of
course) 
Best regards,
Philipp
So I’ll find time for ths sometime this week. No comments from anyone else??
Bruce
coming fresh from the Easter break, here’s an update on the development of
our WYSIWYG CSL Editor.
[… snip…]
Thanks for this Philipp. Please, everyone that has any time, please
take a close look at this, and provide comments. It’s important we get
the foundations of this right.
I’ll try to get comments ASAP, but it may not be until the week after
next. Just don’t want you to think I’m not paying attention …
So I’ll find time for ths sometime this week. No comments from anyone else??
I’ve been meaning to write. My main comment is that I don’t see a
means in the interface of handling conditions and groups, both of
which are used heavily in all styles. Fred Gibbs’ prototype included
a grouping mechanism, with implicit conditional branching on the item
type, but (IIRC) no general mechanism for implementing conditions. If
I read the current mockup correctly, this takes the same approach,
minus support for grouping.
Grouping is essential, because group delimiters will not break when
arbitrary elements of the input data are absent. It really needs to
be in there.
Conditionals are harder to express in a GUI, but a general mechanism
for expressing and editing them is needed. A lot of previous
discussion has focused on the fact that implicit branching on item
type is stiff and verbose. It is, but the bigger stumbling block is
that by limiting the branching mechanism to item type values alone, it
drops some very common cases. Backreferencing styles need a
conditonal branch on the position variable, for example, and the
placement of titles is very often governed by the presence or absence
of other content.
Both of these facilities (cs:group and cs:choose) are heavily used at
the top level in cs:bibliography and cs:citation. To bring up a
functional WYSIWYG-ish interface with a minimum of effort, one option
would be to concentrate hard on getting those two facilities alone to
work, and push all of the detail handled by the current interface
example into library macros, to be brought forward into the GUI (i.e.
by providing a mechanism for cloning and editing library macros)
according to user demand and available time.
So even setting the macro-vs-item-type thing aside, I think you do
need to support cs:group and cs:choose in this top-level editing view.
As a couple of smaller points:
-
the current interface example assumes variables will be used just
once, but some variables (like “issued”) are fairly often used more
than once in a cite; and
-
I don’t see support for cs:substitute, which is a hard one, I know,
but extremely common.
Frank
I’ll take a look at this more later in the week, but just want to
concur with Frank’s points. The most powerful features of CSL are
exactly the ones currently unimplemented: cs:choose, cs:substitute,
cs:group. Indeed, many styles can’t be reasonably represented without
these.
And in some sense, the macro vs. type discussion may well confuse this
more essential point; when I was focusing on macros, it’s just a way
to encapsulate some of this more complex logic and to defer
representing it in the GUI (as well as to make it easy to reuse rather
than forcing people to constantly recreate the logic).
Bruce
Thanks for the feedback, Frank and Bruce. We’ll take it into consideration
for the further development.
The current CSL editor UI assumes a totally flat model, but CSL is a very
hierarchical language. I wonder if there is any way to show that in the UI.
Maybe the different hierarchical levels could be represented vertically,
with the possibility to expand higher-level elements to show their lower
level elements. A very crude mockup, which I hope conveys the idea:
http://pastie.org/931154. Such a hierarchical model would allow all existing
styles to be represented.
Some other small remarks:
- in existing styles, the cs:citation element typically comes before
cs:bibliography. The CSL editor UI and generated styles use a reversed
order. It might makes sense to switch that around.
- the styles that are currently generated are not valid CSL. It might help
to connect the CSL editor to an XML validator to make sure no invalid CSL
styles are served.
Rintze
So I’ll find time for ths sometime this week. No comments from anyone
else??
The current CSL editor UI assumes a totally flat model, but CSL is a very
hierarchical language. I wonder if there is any way to show that in the UI.
Maybe the different hierarchical levels could be represented vertically,
with the possibility to expand higher-level elements to show their lower
level elements. A very crude mockup, which I hope conveys the idea:
http://pastie.org/931154. Such a hierarchical model would allow all existing
styles to be represented.
Yeah, that’s why I adopted that approach in my mockup. I’m in favor of
this. So long as you have the live preview, that will give the style
author/editor a clear visualization of how it will impact output,
without having to artificially constrain the UI to the horizontal
style of the actual output.
Also, really important to keep in mind that evidence suggests the vast
majority of styles are trivial modifications of a small number of core
styles. The UI has to be based on this recognition.
Some other small remarks:
- in existing styles, the cs:citation element typically comes before
cs:bibliography. The CSL editor UI and generated styles use a reversed
order. It might makes sense to switch that around.
- the styles that are currently generated are not valid CSL. It might help
to connect the CSL editor to an XML validator to make sure no invalid CSL
styles are served.
Yeah, critical. Even more, it shouldn’t be possible for the UI to
create invalid output.
Bruce
Just a quick update: Based on your input, we think we have found a UI
solution that allows for both (hierarchical) grouping and using fields
multiple times. Details to follow soon!
Best,
Victor
