feedback on structure of new site?

CSL Development
1

So Rintze and I have been playing around with the new site (based on
WordPress). Any feedback on the basic structure of the pages, the
primary and secondary links, and the categories?

I’m not so sure we want a separate page and primary link for “CSL
Schema” but will leave it for now.

Bruce

PS - Neither of us are designers, so we’re going to go with a simple
"thematic" subtheme, and modify as we find designers willing to help
:wink:

2

Oops:

<http://dev.omeka.org/citationstyles/

3

…

I’m not so sure we want a separate page and primary link for “CSL
Schema” but will leave it for now.

To avoid confusion: Joe Wilson would probably accuse me of being a
liar, as I deleted this page, and decided to simply the spec page to
just “Citation Style Language”; we can link the schema from there.

Bruce

4

Bruce D’Arcus wrote:

Oops:

http://dev.omeka.org/citationstyles/

So Rintze and I have been playing around with the new site (based on
WordPress). Any feedback on the basic structure of the pages, the
primary and secondary links, and the categories?

Looks good… once it’s filled with content it will look even better. I
would like a “How can I make use of it” section. Or/and a “apps that
support this thing” part. It might just be part of a FAQ section…

Sebastian

signature.asc (260 Bytes)

5

Bruce D’Arcus wrote:

Oops:

http://dev.omeka.org/citationstyles/

So Rintze and I have been playing around with the new site (based on
WordPress). Any feedback on the basic structure of the pages, the
primary and secondary links, and the categories?

Looks good… once it’s filled with content it will look even better. I
would like a “How can I make use of it” section.

Who is “I” in this context? A developer? A user?

Or/and a “apps that support this thing” part. It might just be part of a FAQ section…

Sure.

Bruce

6

Hi Bruce,

Just to clarify - this site is for both end-users and developers
working with CSL?

PS - Neither of us are designers, so we’re going to go with a simple
“thematic” subtheme, and modify as we find designers willing to help

There is a lot to be said for simple. From a developer’s point of
view the main thing missing on the XBiblio site which
currently turns up at the top of a search engine query for ‘citation
style language’ is a CSL tutorial which provides a gentle
introduction - I think Rintze (or was it Frank) posted one on this
mailing list a while back. In the new site design I’d
ask that this be more prominent.

From a user’s point of view it needs to be easy to search for styles.
The easiest way to do this is probably
to make a simple page per style and then let Google etc. take care of
indexing and search.

Regards,
Robert.2009/9/14 Bruce D’Arcus <@Bruce_D_Arcus1>:

7

Hi Robert,

Hi Bruce,

Just to clarify - this site is for both end-users and developers
working with CSL?

Yes.

PS - Neither of us are designers, so we’re going to go with a simple
“thematic” subtheme, and modify as we find designers willing to help

There is a lot to be said for simple. From a developer’s point of
view the main thing missing on the XBiblio site which
currently turns up at the top of a search engine query for ‘citation
style language’ is a CSL tutorial which provides a gentle
introduction - I think Rintze (or was it Frank) posted one on this
mailing list a while back. In the new site design I’d
ask that this be more prominent.

I agree. The intention is that it host the spec, the schema (or least
link to it), a tutorial for style authors, a bunch of styles, and
ultimately also the style creation wizard we’ve previously discussed
(which would make the tutorial less critical).

From a user’s point of view it needs to be easy to search for styles.
The easiest way to do this is probably
to make a simple page per style and then let Google etc. take care of
indexing and search.

That’s a really good point.

Any specific suggestions on how best to enable that? Is adding
categories from the style to the HTML head enough? If that’s the case,
it’d be easy enough to write a little script that generates the HTML
from the styles.

Bruce

8

I added the start of a “csl2html.xsl” XSLT to do this conversion once
we figure out if this the best approach, and what HTML structure we
actually want.

Right now, it just outputs the title.

Feel free to experiment if you like.

Bruce

9

Bruce D’Arcus wrote:

Looks good… once it’s filled with content it will look even better. I
would like a “How can I make use of it” section.

Who is “I” in this context? A developer? A user?

Good question. We need probably 2 different parts. “I am a user, how can
I make use of the citation styles provided”. and “I am a developer
interested in making use of CSL”.

And I agree a citation style database, together with an easy way to
search, request (and/or) post new styles would be good.

But sorry for blathering, you all know that anyway.
spaetz

signature.asc (260 Bytes)

10

I personally would like to see something like
http://sfx.tudelft.nl:8888/sfx_local/az
The current single page (www.zotero.org/styles) is a bit slow to load. It
would be nice to be able to have the option to search by title, category
(citation-format and field, as set on cs:category) or ISSN, and to
browse the styles via an alphabetical hierarchy.

BTW, we switched to http://citationstyles.org/, which already has some new
content.

RintzeOn Tue, Sep 15, 2009 at 9:21 AM, Sebastian Spaeth <@Sebastian_Spaeth>wrote:

11

IMHO, it would be nice to have a tabbed interface to find styles.

The first tab (“Browse by Title”) would list styles. Rather similar to the
current style repository, the only difference would be that the total list
of styles is subdivided in per-letter lists. See the “Title” tab of
http://sfx.tudelft.nl:8888/sfx_local/az for an example.

The second tab (“Search”) would allow users to search by a number of
relevant style properties (title, citation-format, field, ISSN, ISSN-L), and
would be similar to the “Locate”-tab of
http://sfx.tudelft.nl:8888/sfx_local/az.

I was looking whether I could mash up something myself with jQuery (which
supports XML-parsing:
http://www.webmonkey.com/tutorial/Easy_XML_Consumption_using_jQuery?oldid=20032),
and I was wondering whether it would make sense to have a style commit hook
that applies an XSLT sheet to all the hosted styles to produce a single XML
file that contains all the necessary search data, e.g.:On Fri, Sep 18, 2009 at 2:46 PM, Rintze Zelle <@Rintze_Zelle>wrote:

On Tue, Sep 15, 2009 at 9:21 AM, Sebastian Spaeth <@Sebastian_Spaeth>wrote:

And I agree a citation style database, together with an easy way to
search, request (and/or) post new styles would be good.

I personally would like to see something like
http://sfx.tudelft.nl:8888/sfx_local/az
The current single page (Zotero Style Repository) is a bit slow to load. It
would be nice to be able to have the option to search by title, category
(citation-format and field, as set on cs:category) or ISSN, and to
browse the styles via an alphabetical hierarchy.

BTW, we switched to http://citationstyles.org/, which already has some new
content.

Rintze

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> http://www.zotero.org/styles/apa American Psychological Association author-date generic-base psychology http://www.zotero.org/styles/ama American Medical Association numeric generic-base medicine http://www.zotero.org/styles/biochemistry Biochemistry 0006-2960 numeric biology ---

That would make it easy to perform a client-side search. Does that make
sense? If so, would JSON be preferred to save some bandwidth?

Rintze

12

And I agree a citation style database, together with an easy way to
search, request (and/or) post new styles would be good.

I personally would like to see something like
http://sfx.tudelft.nl:8888/sfx_local/az
The current single page (Zotero Style Repository) is a bit slow to load. It
would be nice to be able to have the option to search by title, category
(citation-format and field, as set on cs:category) or ISSN, and to
browse the styles via an alphabetical hierarchy.

Is this sort of “select letter, type string, press go” interface the
best we can do today?

Why not just have a filter box where the content just narrows the list
dynamically?

In any case, I like the basic idea, and this question is just about details.

…

I was looking whether I could mash up something myself with jQuery (which
supports XML-parsing:
Digital Marketing Guides, Software Reviews & Nearby Agencies | Web Monkey),
and I was wondering whether it would make sense to have a style commit hook
that applies an XSLT sheet to all the hosted styles to produce a single XML
file that contains all the necessary search data, e.g.:

I’m not sure that it’s that easy to input multiple files in XSLT, but
whether we use that, or a simple Python script, it’s pretty easy to
create these sorts of indices.

For example, here’s a little one that uses citeproc-py to list a
directory of csl files:

from citeproc import *
import glob
import os

styles = glob.glob(‘/home/darcusb/Code/z-csl/*.csl’)

for style in styles:
csl = Style(style)
print csl.title

Would be easy to extend for this purpose.

That would make it easy to perform a client-side search. Does that make
sense? If so, would JSON be preferred to save some bandwidth?

Not sure, but guess it doesn’t make a huge difference.

Bruce

13

And I agree a citation style database, together with an easy way to
search, request (and/or) post new styles would be good.

I personally would like to see something like
http://sfx.tudelft.nl:8888/sfx_local/az
The current single page (Zotero Style Repository) is a bit slow to load.
It
would be nice to be able to have the option to search by title, category
(citation-format and field, as set on cs:category) or ISSN, and to
browse the styles via an alphabetical hierarchy.

Is this sort of “select letter, type string, press go” interface the
best we can do today?

Why not just have a filter box where the content just narrows the list
dynamically?

We would need the ability to distribute results over multiple pages (e.g.
10-20 styles per page), and to apply multiple filters. Maybe this solution
would fit the bill:

tablesorter with the pager plugin:
http://tablesorter.com/docs/example-pager.html

and the tablesorterFilter plugin:
http://www.compulsivoco.com/2008/08/tablesorter-filter-results-based-on-search-string/

For example, here’s a little one that uses citeproc-py to list a
directory of csl files:

from citeproc import *
import glob
import os

styles = glob.glob(‘/home/darcusb/Code/z-csl/*.csl’)

for style in styles:
csl = Style(style)
print csl.title

Does Python have XML support by default? Or do you need a library for that?

Rintze

14

We would need the ability to distribute results over multiple pages (e.g.
10-20 styles per page), and to apply multiple filters. Maybe this solution
would fit the bill:

tablesorter with the pager plugin:
http://tablesorter.com/docs/example-pager.html

and the tablesorterFilter plugin:
http://www.compulsivoco.com/2008/08/tablesorter-filter-results-based-on-search-string/

Right.

For example, here’s a little one that uses citeproc-py to list a
directory of csl files:

from citeproc import *
import glob
import os

styles = glob.glob(‘/home/darcusb/Code/z-csl/*.csl’)

for style in styles:
csl = Style(style)
print csl.title

Does Python have XML support by default? Or do you need a library for that?

Citeproc uses the standard library (element tree) for XML. By parsing
as Style objects, you get easy access to the metadata and such.

Bruce

15

We don’t really have to pull the entire style list down and do this
client-side. Our SVN post-commit hook already parses the CSL XML and
adds the relevant info to the database (along with updating the title
(displaying “(dev)” as necessary) and the timestamp (so authors don’t
have to fiddle with it on every edit)). So we could provide a simple
DB-backed search API that could be called from JS (or used externally as
a style query service). If someone wanted to take a crack at that (in
the style of the web-based citation processor API document on Google
Docs that Bruce, Rintze, and Frank have access to—and we’re happy to
give others access as requested), it would be fairly trivial to
implement. It probably would make sense for it to speak Atom.

Alternatively, the post-commit hook could just generate a static
JSON/XML file containing the full repo data that could be pulled down
from JS. That would admittedly be easier for everyone, but initial loads
of the style section would be slower. Even served with gzip compression,
the full list would be pretty big.

  • Dan
16

We don’t really have to pull the entire style list down and do this
client-side. Our SVN post-commit hook already parses the CSL XML and
adds the relevant info to the database (along with updating the title
(displaying “(dev)” as necessary) and the timestamp (so authors don’t
have to fiddle with it on every edit)). So we could provide a simple
DB-backed search API that could be called from JS (or used externally as
a style query service). If someone wanted to take a crack at that (in
the style of the web-based citation processor API document on Google
Docs that Bruce, Rintze, and Frank have access to—and we’re happy to
give others access as requested), it would be fairly trivial to
implement.

Here’s an empty Trac page if someone takes this up:

https://sourceforge.net/apps/trac/xbiblio/wiki/StyleSearchApi

It probably would make sense for it to speak Atom.

What do you mean; the Atom API (some subset?)?

Alternatively, the post-commit hook could just generate a static
JSON/XML file containing the full repo data that could be pulled down
from JS. That would admittedly be easier for everyone, but initial loads
of the style section would be slower. Even served with gzip compression,
the full list would be pretty big.

I suppose it makes some sense to plan for success.

Bruce

17

No, I just meant the Atom Syndication Format. This isn’t particularly
necessary. The main advantage (other than that the style metadata would,
by design, fit pretty well) would be that you could get regular Atom
feeds for new/updated styles. I’m not sure what the practical advantage
of that would be, though, so if JSON would be easier for site
integration, we could just use that.

18

We would need the ability to distribute results over multiple pages
(e.g.
10-20 styles per page), and to apply multiple filters. Maybe this
solution
would fit the bill:

tablesorter with the pager plugin:
http://tablesorter.com/docs/example-pager.html

and the tablesorterFilter plugin:

http://www.compulsivoco.com/2008/08/tablesorter-filter-results-based-on-search-string/

Right.

We don’t really have to pull the entire style list down and do this
client-side. Our SVN post-commit hook already parses the CSL XML and
adds the relevant info to the database (along with updating the title
(displaying “(dev)” as necessary) and the timestamp (so authors don’t
have to fiddle with it on every edit)). So we could provide a simple
DB-backed search API that could be called from JS (or used externally as
a style query service). If someone wanted to take a crack at that (in
the style of the web-based citation processor API document on Google
Docs that Bruce, Rintze, and Frank have access to—and we’re happy to
give others access as requested), it would be fairly trivial to
implement. It probably would make sense for it to speak Atom.

But in that case real-time filtering would be off the table, right?

Alternatively, the post-commit hook could just generate a static

JSON/XML file containing the full repo data that could be pulled down
from JS. That would admittedly be easier for everyone, but initial loads
of the style section would be slower. Even served with gzip compression,
the full list would be pretty big.

Just zipping/rarring the dependent styles folder with WinRar already results
in a 0.8-1.0 MB file (that said, the current Style Repository page is also
quite big at 1.3 MB). But maybe we can slim that down a bit. E.g. a JSON
file would only need to contain:

title, style-id/URI, categories (citation-format, field), issn, issn-l and
the timestamp
plus perhaps a preview of the style (but you could load that separately per
selected style to save some bandwidth)

Rintze

19 
We don't really have to pull the entire style list down and do this
client-side. Our SVN post-commit hook already parses the CSL XML and
adds the relevant info to the database (along with updating the title
(displaying "(dev)" as necessary) and the timestamp (so authors don't
have to fiddle with it on every edit)). So we could provide a simple
DB-backed search API that could be called from JS (or used
externally as
a style query service). If someone wanted to take a crack at that (in
the style of the web-based citation processor API document on Google
Docs that Bruce, Rintze, and Frank have access to�and we're happy to
give others access as requested), it would be fairly trivial to
implement. It probably would make sense for it to speak Atom.

But in that case real-time filtering would be off the table, right?

No. You’d just call the search API from JS with the specified search
string, start/limit, sort field, and order, and you’d get the set of
results to display. So you’re always just populating the table with the
returned results�it’s just a question of building the right query URI.

Alternatively, the post-commit hook could just generate a static
JSON/XML file containing the full repo data that could be pulled down
from JS. That would admittedly be easier for everyone, but initial
loads
of the style section would be slower. Even served with gzip
compression,
the full list would be pretty big.

Just zipping/rarring the dependent styles folder with WinRar already
results in a 0.8-1.0 MB file (that said, the current Style Repository
page is also quite big at 1.3 MB). But maybe we can slim that down a
bit. E.g. a JSON file would only need to contain:

title, style-id/URI, categories (citation-format, field), issn, issn-l
and the timestamp
plus perhaps a preview of the style (but you could load that
separately per selected style to save some bandwidth)

Well, you certainly don’t need to include the styles themselves. But
even the list itself may get too big. A table dump that’s fairly close
to JSON puts the uncompressed data (not counting categories, which
aren’t currently stored in the database, or previews, which I discuss
below) at 261KB, and it gzips down to 30KB. That’s doable, but 1) that
will get bigger, and potentially a lot bigger if we add more dependent
styles, and 2) it would require not-insignificant processing time
(unzipping, sorting, formatting) on the client. Of course, that becomes
less of an issue as time goes on. But for now it might be a bit laggy.

For style previews, on the current page I decided against asynchronous
fetching, since waiting for each preview was getting annoying. Instead I
bundle unique previews indexed by hash and preview hashes indexed by
style. This totals 767KB and gzips to 50KB. We’ll probably want more
examples in each preview, however.

20

A short note for posterity: by default, all the tabs in the navigation menu
of the thematic WordPress theme are clickable (clicking the tab will open
the corresponding page). I recently used the Page Lists Plus plugin to
unlink the “Citation Style Language”-tab, as this parent tab probably
shouldn’t be a destination (unlike its children). Instructions can be found
at disabling parent menu links « ThemeShaper Forums, but are
copied verbatim here for convenience:On Sun, Sep 13, 2009 at 6:07 PM, Bruce D’Arcus <@Bruce_D_Arcus1> wrote:

So Rintze and I have been playing around with the new site (based on
WordPress). … so we’re going to go with a simple
“thematic” subtheme

To unlink a menu item using Page Lists Plus, install the plugin, then go to

Page Lists Plus and check these boxes:

Under “Global Options”, check “Unlink using javascript” (this should
preserve your menu styling).

Under Page-Specific Options", check “Link”.

When editing a page, you should now see a “Page Lists Plus” section near the
bottom. In that section uncheck “If this box is checked, then this Page will
be linked in lists generated using wp_list_pages().” The menu item
associated with this page should now be nonclickable.

Rintze