Any interest in a GUI editor?

CSL Development
1

Hello,

I have a longtime interest in bibliographic software and have tried to think
of ways to contribute. With the development of CSL and most recently Zotero I
thought a GUI editor to generate and maintain csl files could be useful.

Is there any interest in such a project? I have started a small project mainly
as a proof of concept, that I think it should be possible to build on. With
the advanced features of CSL such as macros, substitute, and conditionals
it’s not entirely straightforward to make a traditional linear interface for
citation and bibliography layout.

Have a look at http://www.scripps.edu/mb/hedlund/csledit.html and tell me what
you think.

Thanks,
Peter

2

Hi Peter,

Peter Hedlund wrote:

I have a longtime interest in bibliographic software and have tried to think
of ways to contribute. With the development of CSL and most recently Zotero I
thought a GUI editor to generate and maintain csl files could be useful.

Is there any interest in such a project?

Yes, absolutely! Johan Kool had worked on a Cocoa version awhile back
(before recent changes) as well. The more the merrier.

I have started a small project mainly
as a proof of concept, that I think it should be possible to build on. With
the advanced features of CSL such as macros, substitute, and conditionals
it’s not entirely straightforward to make a traditional linear interface for
citation and bibliography layout.

Yes, this indeed may be a challenge.

Have a look at http://www.scripps.edu/mb/hedlund/csledit.html and tell me what
you think.

Looks like a nice start!

The only question I have is about the programming choice. It’s obviously
totally up to you what you want to do, but it seems to me you might
consider an option like extending the csledit.xul interface the Zotero
guys started.

Alternately, I’ve been playing with the new Buzzword Flex/AIR
application the past couple of days, and am so impressed with the UI I’m
forgetting the runtime isn’t free :wink:

Bruce

3

Hi Peter,

Peter Hedlund wrote:

I have a longtime interest in bibliographic software and have tried to
think of ways to contribute. With the development of CSL and most
recently Zotero I thought a GUI editor to generate and maintain csl files
could be useful.

Is there any interest in such a project?

Yes, absolutely! Johan Kool had worked on a Cocoa version awhile back
(before recent changes) as well. The more the merrier.

Yes, I saw that in your repository, but it uses the old schema, right? and I
don’t know a thing about Mac development.

I have started a small project mainly
as a proof of concept, that I think it should be possible to build on.
With the advanced features of CSL such as macros, substitute, and
conditionals it’s not entirely straightforward to make a traditional
linear interface for citation and bibliography layout.

Yes, this indeed may be a challenge.

I’m glad we agree :slight_smile:

Have a look at http://www.scripps.edu/mb/hedlund/csledit.html and tell me
what you think.

Looks like a nice start!

The only question I have is about the programming choice. It’s obviously
totally up to you what you want to do, but it seems to me you might
consider an option like extending the csledit.xul interface the Zotero
guys started.

The number one reason is of course that I’m somewhat familiar with Qt. But, to
me it’s also a logical choice since it should be possible to compile
applications that run natively on Linux/Unix, Windows, and Mac.

The csledit.xul is only a text edit window where you work directly on the xml,
or did I miss something?

Besides, isn’t the plan to use csl not only in Zotero?

Alternately, I’ve been playing with the new Buzzword Flex/AIR
application the past couple of days, and am so impressed with the UI I’m
forgetting the runtime isn’t free :wink:

This is something I’m not at all familiar with. But I’m very unlikely to adopt
a non-FLOSS approach.

Thanks,
Peter

4

Peter Hedlund wrote:

I have a longtime interest in bibliographic software and have tried to
think of ways to contribute. With the development of CSL and most
recently Zotero I thought a GUI editor to generate and maintain csl files
could be useful.

Is there any interest in such a project?

Yes, absolutely! Johan Kool had worked on a Cocoa version awhile back
(before recent changes) as well. The more the merrier.

Ditto from us at Zotero.

The only question I have is about the programming choice. It’s obviously
totally up to you what you want to do, but it seems to me you might
consider an option like extending the csledit.xul interface the Zotero
guys started.

The number one reason is of course that I’m somewhat familiar with Qt. But, to
me it’s also a logical choice since it should be possible to compile
applications that run natively on Linux/Unix, Windows, and Mac.

The csledit.xul is only a text edit window where you work directly on the xml,
or did I miss something?

Besides, isn’t the plan to use csl not only in Zotero?

I’d echo what Bruce said here as well. It’d certainly make sense for you
to code in whatever you were comfortable in, but implementing this as a
Firefox plugin would carry certain benefits, such as being able to pull
data from the user’s Zotero library and leverage Zotero’s citation
processor for as-you-type previewing of selected items. That’s the main
point of csledit.xul. The idea here isn’t that CSL is Zotero-specific in
any way, but merely that Zotero already offers a data model, an easy way
to grab sample references, and a CSL processor. I don’t see any preview
functionality in your mockups, but I think that would be an important
part of such a tool.

csledit.xul is a very quick hack that runs within the content window,
but it could easily be transformed into a windowed UI that looked just
like your mockups. We were planning to integrate its functionality into
Scaffold (our mini-IDE for translators), but the CSL editor could easily
be a separate plugin, and we’d be happy to contribute Zotero integration
code. The Zotero integration could be purely optional.

As an external app, seamless Zotero integration could really only happen
via some sort of IPC API, which probably won’t exist in Zotero for some
time.

5

Peter Hedlund wrote:

…

The only question I have is about the programming choice. It’s obviously
totally up to you what you want to do, but it seems to me you might
consider an option like extending the csledit.xul interface the Zotero
guys started.

The number one reason is of course that I’m somewhat familiar with Qt. But, to
me it’s also a logical choice since it should be possible to compile
applications that run natively on Linux/Unix, Windows, and Mac.

Sure, and that’s fine.

The csledit.xul is only a text edit window where you work directly on the xml,
or did I miss something?

Besides, isn’t the plan to use csl not only in Zotero?

Yes, definitely. See if Dan offers some compelling reasons why it might
make sense.

When I first was working on CSL, I had the idea of a central repository
and web interface. I suppose it doesn’t much matter, so long as in the
end we enable the distributed repository model I envision. With a client
side app, one could still do that presumably.

Really the goal is to make it easy for lots of users to (relatively)
quickly create these styles, and for different projects to be able to
benefit from that infrastructure. Zotero is simply the one out in front
on deploying CSL.

Alternately, I’ve been playing with the new Buzzword Flex/AIR
application the past couple of days, and am so impressed with the UI I’m
forgetting the runtime isn’t free :wink:

This is something I’m not at all familiar with. But I’m very unlikely to adopt
a non-FLOSS approach.

Yes, totally understand.

Bruce

6

Oh, and …

Peter Hedlund wrote:

Yes, absolutely! Johan Kool had worked on a Cocoa version awhile back
(before recent changes) as well. The more the merrier.

Yes, I saw that in your repository, but it uses the old schema, right? and I
don’t know a thing about Mac development.

Yes, old schema. And I wasn’t suggesting you hack on it; just that
you’re not alone in trying it :wink:

Bruce

7

Dan Stillman wrote:

I don’t see any preview functionality in your mockups, but I think
that would be an important part of such a tool.

Yes, previewing, and also validation.

Bruce

8

BTW, I just tried to build it on OS X, using the latest pre-compiled Qt
binaries available at Trolltech.

This is what happens:

$ qmake csledit.pro
$ make
make: *** No targets specified and no makefile found. Stop.

I have no experience with Qt.

Bruce

9

I don’t really have any Mac experience. The only Mac I have access to still
runs 10.3.9 and doesn’t have the most recent Xcode tools.

If qmake doesn’t give any error I assume a makefile must be generated. Do you
see one in the csledit folder?

Are the tips at http://trolltech.com/developer/notes/platforms/osx regarding
compiler version and Intel hardware of any help?

Thanks,
Peter

10

Hello all,

Sorry, I have been quite dormant about this stuff lately. And I am
afraid I won’t have much time in the near future for this project
either.

My code for the CSL editor isn’t very useful, and more of an exercise
in what a GUI might look like. It is certainly quite hard to catch all
of CSL’s possibilities in a GUI that also remains usable and doesn’t
overload the user with a plethora of buttons, popups and textfields.

Qt does work on the Mac. But the interface it provides is far from
pretty, and for that reason I don’t find it the ideal platform for
developing native software for the Mac.

I think it would lean currently to suggesting implementing a CSL
editor through a web interface. That would than be ideal in
combination with a central repository for CSL styles. Editing CSL
styles should be a relative rare task for the end user, as he will
likely first try to find a predefined style for his needs, that I feel
that the advantages of a web interface outweigh those of native
software.

There are currently many excellent frameworks available for web
development. We need to find out which one has the best support for
XML editing and custom forms (we are likely going to need lots of
those). Other considerations would be the ease of writing and the ease
of hosting. Something with Python or Ruby would have my preference,
but I’ll gladly hear others suggestions.

Cheers,

Johan—
http://www.johankool.nl/

11

This does not answer your question, but I have nevertheless updated
http://www.scripps.edu/mb/hedlund/csledit.html to give information for the
Windows platform. The trick there was to specify a release build instead of a
debug build. I will continue to investigate Mac, but my access and experience
is limited.

In what way are Qt apps ugly on the Mac? From looking at screenshots and
documentation everything seems native to me.

Web applications are good, but they also have limitations. Especially in
keyboard navigation and editing commands. In e.g. Zotero it’s impossible to
navigate with the keyboard between all edit fields, dropdowns, pluses and
minuses. It works because most data is imported, but serious editing is
cumbersome.

A central repository is of course good. Qt in itself is AFAIK not network
transparent [1] making a pure Qt app limited in accessing remote files.

[1] In contrast to e.g. KDE where you can open files using almost any protocol
in any application, or OpenOffice.org which supports at least ftp and webdav
in its file dialog.

Thanks,
Peter

12

Here are the instructions to compile on Mac OS X:

Install Apple’s Developer Tools

Download and install:
qt-mac-opensource-4.3.2.dmghttp://www.trolltech.com/download?target=ftp://ftp.trolltech.com/qt/source/qt-mac-opensource-4.3.2.dmg

Extract csledit-0.1.tar.gzhttp://www.scripps.edu/mb/hedlund/download/csledit-0.1.tar.gz

$ cd csledit

$ qmake csledit.pro

$ open csledit.xcodeproj

Click on ‘Build and Run’ in Xcode.

(I needed to edit the 2 scripts in the target to escape a space in my path.
This is done by selecting the script under the target and showing the
inspector for it.)

13

Thank you for the instructions. I added them to the web page together with an
alternative approach described in the qmake documentation.

Thanks,
Peter

14

Well, remember, Zotero isn’t a web app–the interface is done with XUL,
which makes it more closely resemble a desktop app but requires more
manual implementation of keyboard support for certain actions. Full
keyboard accessibility is still quite possible, though–the only reason
Zotero doesn’t have it is because we haven’t finished adding it.

An actual web app would likely have a different interface from a XUL
app, so they’re not really comparable, but there’s no reason a web app
couldn’t be perfectly usable via the keyboard, either–you’d get
accessibility for standard HTML elements via the browser and implement
anything else via JS. Advantages of a web app include 1) no
download/installation, 2) ability to accept reference data from apps
like Zotero via GET/POST (like, say, the W3C validators), 3) ability to
save edited styles via a simple download link (which, if served with the
proper MIME type, Zotero or another CSL-powered app could auto-install),
and 4) possible integration with a browsable repository of styles, so
you could find a template style, click Edit, make a few changes, and
download into your CSL-powered app.

The advantage of a Firefox extension over a web app, along with Zotero
integration, is that it’d let you create a tool that felt more like a
desktop app, with custom context menus, etc., and you could leverage a
lot of special functionality in the Mozilla framework (for XML handling,
file I/O, etc.). But that may not be necessary.

The most important thing may be to figure out how you’d be providing
previewing of styles, since that may affect other design decisions. If
you weren’t going to leverage Zotero for that, you’d need a CSL
processor and some way of inputting data. I guess maybe CiteProc could
help here, though I don’t know much about it or how up-to-date it is.
But before relying on CiteProc, you (and we, if we were going to
recommend that people use this rather than a Zotero-integrated tool that
we develop) would want to know that CiteProc was going to be kept
up-to-date with the spec.

Another option would be a web app that did previewing using an
abstracted version of Zotero’s JS-based CSL processor…

15

Yes, I realize this but I haven’t really gotten that far yet (partly because
it’s challenging). We’ll see…

Peter

16

Johan Kool wrote:

$ open csledit.xcodeproj

Click on ‘Build and Run’ in Xcode.

Ah! That works.

So, yeah, it builds and runs on Mac OS X.

I’ve got a few thoughts, which are in part general design thoughts
prompted by your work Peter.

  • I find the “contributors” panel a little funky.

  • the categories list may well get pretty long. Is this the right UI
    choice? Am not sure; just asking.

  • perhaps because of the above, there’s a need for three panels for the
    metadata. But I wonder if it’d be possible to have it all on one, more
    compact, panel?

  • it might be useful to provide some help for users on the id and link
    values. The id, for example, is required.

  • that raises the validation issue; ultimately, an editor ought to
    ensure a valid file.

  • I like the way you’ve done the “option” settings.

  • macros: I wonder if it would make sense to provide a list of macro
    names? We’ve actually reserved an “author” one.

Anyway, that’s all for now. Looking good.

Do you have any ideas about whether it’s possible to GUIify the rest of
it? I realize it’s hard.

Bruce

17

Dan Stillman wrote:

I guess maybe CiteProc could help here, though I don’t know much
about it or how up-to-date it is. But before relying on CiteProc, you
(and we, if we were going to recommend that people use this rather
than a Zotero-integrated tool that we develop) would want to know
that CiteProc was going to be kept up-to-date with the spec.

I can’t commit to that unfortunately.

Another option would be a web app that did previewing using an
abstracted version of Zotero’s JS-based CSL processor…

Yes. If you look in the SVN, CiteProc is now citeproc-xsl, and there are
citeproc-py and citeproc-rb placeholders as well. Essentially what
you’re mentioning here is a kind of citeproc-js. I kind of liked the
idea of thinking in terms of a standard API for citation processing.

For the creation or editing of styles, one doesn’t really need one’s own
data from Zotero (or whatever); one just needs say 10 rich examples that
can show the full expressiveness of a given style. I’d imagine one could
just load some standardized JSON data for previewing.

Bruce

18

Johan Kool wrote:

$ open csledit.xcodeproj

Click on ‘Build and Run’ in Xcode.

Ah! That works.

So, yeah, it builds and runs on Mac OS X.

See the web page for a second way to build on Mac OS X.

I’ve got a few thoughts, which are in part general design thoughts
prompted by your work Peter.

Thank you. This is exactly the type of feedback I was hoping for. Lots of
stuff are not done yet, and nothing is carved in stone.

  • I find the “contributors” panel a little funky.

Yes… but are there better alternatives?

A question about the schema. The definition for the info element contains
info-author* and info-contributor*. Further down the element info-translator
is introduced, but it’s never used in the info element. Is this an omission
or do I miss something?

  • the categories list may well get pretty long. Is this the right UI
    choice? Am not sure; just asking.

Should it be split for info-fields and info-classes? How many should it be
possible to select? What does “You can override” vs. “notAllowed” mean?

  • perhaps because of the above, there’s a need for three panels for the
    metadata. But I wonder if it’d be possible to have it all on one, more
    compact, panel?

  • it might be useful to provide some help for users on the id and link
    values. The id, for example, is required.

Yes, I was thinking of having the labels for required fields in bold. Tooltips
etc. are very easy to add to the ui file using Qt Designer if someone wants
to help.

  • that raises the validation issue; ultimately, an editor ought to
    ensure a valid file.

I will most likely introduce a validation menu command. I think validation on
each save would be too intrusive.

  • I like the way you’ve done the “option” settings.

OK, good.

  • macros: I wonder if it would make sense to provide a list of macro
    names? We’ve actually reserved an “author” one.

Ah, I thought these were completely user-defined. Where does it say
that “author” is reserved? Because of cs-names?

Anyway, that’s all for now. Looking good.

Thanks.

Do you have any ideas about whether it’s possible to GUIify the rest of
it? I realize it’s hard.

Sorting should be pretty straightforward, but after that it gets more
tricky…

Peter

19

In the latest version of the schema, it’s not. In older versions, it
was, but when we changed the way sorting works, we got rid of it.

Simon

20

Peter Hedlund wrote:

…

  • I find the “contributors” panel a little funky.

Yes… but are there better alternatives?

What about something like:

author: [name] [email] +

A question about the schema. The definition for the info element contains
info-author* and info-contributor*. Further down the element info-translator
is introduced, but it’s never used in the info element. Is this an omission
or do I miss something?

Hmm … not sure. I don’t recall adding that.

One thing to keep in mind is the content model for the metadata is
borrowed from Atom.

  • the categories list may well get pretty long. Is this the right UI
    choice? Am not sure; just asking.

Should it be split for info-fields and info-classes? How many should it be
possible to select? What does “You can override” vs. “notAllowed” mean?

Well, let’s keep in mind the idea behind this. It goes back to the Atom
basis.

The idea is that ultimately we will have distributed CSL repositories.
So Zotero might have some, we might host some here, and if we’re really
successful there may evolve to be hundreds of them.

The categories here will allow people to find styles in and subscribe to
only those styles in their area.

I’d expect typically a style will have one (and only one) class, and
between one and three or so field categories.

  • perhaps because of the above, there’s a need for three panels for the
    metadata. But I wonder if it’d be possible to have it all on one, more
    compact, panel?

  • it might be useful to provide some help for users on the id and link
    values. The id, for example, is required.

Yes, I was thinking of having the labels for required fields in bold. Tooltips
etc. are very easy to add to the ui file using Qt Designer if someone wants
to help.

With respect to “help” I was wondering if it could automatically
generate an id URI? So say when they start a new style the app does
this, and the field is not editable. To edit it (say they want to add
their own URI) they have to click some button.

In that (auto) case, the URI could just be a GUUID URN.

  • that raises the validation issue; ultimately, an editor ought to
    ensure a valid file.

I will most likely introduce a validation menu command. I think validation on
each save would be too intrusive.

The only way you’d want to do continuous validation is if you did it the
way an XML editor does it: flagging the errors with red inline. Probably
too much work.

Bruce