# alternative GUI idea

**URL:** <https://discourse.citationstyles.org/t/alternative-gui-idea/443>\
**Category:** CSL Development\
**Created:** [February 29, 2008, 6:26pm UTC](https://discourse.citationstyles.org/t/alternative-gui-idea/443 "2008-02-29T18:26:59Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dan\_Stillman](https://avatars.discourse-cdn.com/v4/letter/d/ecb155/32.png) [@Dan\_Stillman](https://discourse.citationstyles.org/u/Dan_Stillman)\
**Post date:** [February 29, 2008, 6:26pm UTC](https://discourse.citationstyles.org/t/alternative-gui-idea/443/1 "2008-02-29T18:26:59Z")

</div>

(Something like this might have been proposed before. My apologies if I  
missed it.)

If I understand Bruce’s plans for MakeCSL, for the various parts of a  
style, users will pick and choose the macros to use based on previews of  
existing styles, and MakeCSL will consolidate these into a single new style.

That should work well for styles based on the core styles, but it  
wouldn’t let the tool take advantage of the potentially hundreds of  
unique styles that might eventually be in the repository. Bruce has been  
recommending to users on the Zotero forums that they post styles to the  
Zotero style repo rather than post them on their own websites, and it  
seems quite possible that in the not-too-distant future there could be  
too many styles to easily go through and find one close (or identical)  
to the custom style needed.

Either as a feature of MakeCSL or as a separate search function of the  
style repository, perhaps there could be a GUI tool that let you upload  
one or more sample records and type or paste in what the bibliographic  
output should be. The tool could generate previews for all existing  
styles using the sample data and then run an edit distance function  
(Levenshtein or similar) on those previews and the user’s input to  
determine what style came closest to the desired formatting. With some  
more complicated logic the tool might be able to pick and choose the  
macros from those styles necessary to form a new correct style, but that  
wouldn’t be necessary for a first step.

- Dan

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [February 29, 2008, 6:52pm UTC](https://discourse.citationstyles.org/t/alternative-gui-idea/443/2 "2008-02-29T18:52:06Z")

</div>

> If I understand Bruce’s plans for MakeCSL, for the various parts of a  
> style, users will pick and choose the macros to use based on previews of  
> existing styles, and MakeCSL will consolidate these into a single new style.

Yes.

> That should work well for styles based on the core styles, but it  
> wouldn’t let the tool take advantage of the potentially hundreds of  
> unique styles that might eventually be in the repository.

My argument (which is in part based on the practical demonstration of  
MakeBST) is that the variations among those styles come down to  
trivial differences, and that if you break apart those styles into the  
right pieces, it’s easy to then put them back together in infinite  
variation.

Consider some of the macros I just checked in for publishers.

Some styles do “New York:ABC Books” others do “ABC Books;New York” and  
still others wrap them in some grouping punctuation. But beyond that,  
what other variations are there really?

So define those two or three or four different variations as macros,  
and be done with it.

> Bruce has been  
> recommending to users on the Zotero forums that they post styles to the  
> Zotero style repo rather than post them on their own websites, and it  
> seems quite possible that in the not-too-distant future there could be  
> too many styles to easily go through and find one close (or identical)  
> to the custom style needed.

I’m not so sure. Consider that each style gets tagged with one-or-more  
categories. So it’s quite easy to then filter on those categories.  
When you couple that with previews (of styles, and also macros), I’m  
not concerned. Even if there were, say, 100 styles with the “history”  
category, you could still narrow that further by saying certain styles  
are “base” styles.

> Either as a feature of MakeCSL or as a separate search function of the  
> style repository, perhaps there could be a GUI tool that let you upload  
> one or more sample records and type or paste in what the bibliographic  
> output should be. The tool could generate previews for all existing  
> styles using the sample data and then run an edit distance function  
> (Levenshtein or similar) on those previews and the user’s input to  
> determine what style came closest to the desired formatting. With some  
> more complicated logic the tool might be able to pick and choose the  
> macros from those styles necessary to form a new correct style, but that  
> wouldn’t be necessary for a first step.

Thar could be cool. In essence, you’d be automating the wizard process.

But, of course, one still needs the basic model and process before one  
would build that automation; right?

Also, there’s the question of how you’d have those samples. If you had  
to create them or otherwise intervene in getting them into the system,  
that might take more work than a good wizard interface.

Also, I’m not convinced users need their own data for previewing. I  
find it more of a hassle to have to find suitable preview data for  
creating new styles (in, say, csledit.xul) than if we just had some  
good sample data upfront (perhaps adapted for different fields).

BTW, if you’re curious, here’s the current SQL generated by Django:

$ python manage.py sql styles  
BEGIN;  
CREATE TABLE “styles\_category” (  
“id” serial NOT NULL PRIMARY KEY,  
“name” varchar(25) NOT NULL UNIQUE  
)  
;  
CREATE TABLE “styles\_optiontype” (  
“id” serial NOT NULL PRIMARY KEY,  
“name” varchar(30) NOT NULL UNIQUE  
)  
;  
CREATE TABLE “styles\_style” (  
“id” serial NOT NULL PRIMARY KEY,  
“title” varchar(100) NOT NULL,  
“slug” varchar(50) NOT NULL UNIQUE,  
“type” varchar(1) NOT NULL,  
“author\_id” integer NOT NULL REFERENCES “auth\_user” (“id”)  
DEFERRABLE INITIALLY DEFERRED,  
“created” timestamp with time zone NOT NULL,  
“updated” timestamp with time zone NOT NULL,  
“citation\_id” integer NOT NULL,  
“bibliography\_id” integer NOT NULL  
)  
;  
CREATE TABLE “styles\_option” (  
“id” serial NOT NULL PRIMARY KEY,  
“type\_id” integer NOT NULL REFERENCES “styles\_optiontype” (“id”)  
DEFERRABLE INITIALLY DEFERRED,  
“value” varchar(15) NOT NULL  
)  
;  
CREATE TABLE “styles\_macro” (  
“id” serial NOT NULL PRIMARY KEY,  
“type\_id” integer NOT NULL,  
“slug” varchar(50) NOT NULL UNIQUE,  
“xml” text NOT NULL  
)  
;  
CREATE TABLE “styles\_macrotype” (  
“id” serial NOT NULL PRIMARY KEY,  
“name” varchar(40) NOT NULL UNIQUE  
)  
;  
ALTER TABLE “styles\_macro” ADD CONSTRAINT type\_id\_refs\_id\_7952bca7  
FOREIGN KEY (“type\_id”) REFERENCES “styles\_macrotype” (“id”)  
DEFERRABLE INITIALLY DEFERRED;  
CREATE TABLE “styles\_layoutlistitem” (  
“id” serial NOT NULL PRIMARY KEY,  
“macro\_id” integer NOT NULL REFERENCES “styles\_macro” (“id”)  
DEFERRABLE INITIALLY DEFERRED,  
“context\_id” integer NOT NULL,  
“position” integer CHECK (“position” \>= 0) NOT NULL,  
“prefix” varchar(10) NOT NULL,  
“suffix” varchar(10) NOT NULL  
)  
;  
CREATE TABLE “styles\_context” (  
“id” serial NOT NULL PRIMARY KEY,  
“name” varchar(100) NOT NULL UNIQUE,  
“type” varchar(1) NOT NULL,  
“sort\_id” integer NOT NULL REFERENCES “styles\_macro” (“id”)  
DEFERRABLE INITIALLY DEFERRED,  
“layout\_prefix” varchar(5) NOT NULL,  
“layout\_suffix” varchar(5) NOT NULL  
)  
;  
ALTER TABLE “styles\_style” ADD CONSTRAINT citation\_id\_refs\_id\_1bf2bf95  
FOREIGN KEY (“citation\_id”) REFERENCES “styles\_context” (“id”)  
DEFERRABLE INITIALLY DEFERRED;  
ALTER TABLE “styles\_style” ADD CONSTRAINT  
bibliography\_id\_refs\_id\_1bf2bf95 FOREIGN KEY (“bibliography\_id”)  
REFERENCES “styles\_context” (“id”) DEFERRABLE INITIALLY DEFERRED;  
ALTER TABLE “styles\_layoutlistitem” ADD CONSTRAINT  
context\_id\_refs\_id\_54305e8c FOREIGN KEY (“context\_id”) REFERENCES  
“styles\_context” (“id”) DEFERRABLE INITIALLY DEFERRED;  
CREATE TABLE “styles\_style\_categories” (  
“id” serial NOT NULL PRIMARY KEY,  
“style\_id” integer NOT NULL REFERENCES “styles\_style” (“id”)  
DEFERRABLE INITIALLY DEFERRED,  
“category\_id” integer NOT NULL REFERENCES “styles\_category” (“id”)  
DEFERRABLE INITIALLY DEFERRED,  
UNIQUE (“style\_id”, “category\_id”)  
)  
;  
CREATE TABLE “styles\_context\_options” (  
“id” serial NOT NULL PRIMARY KEY,  
“context\_id” integer NOT NULL REFERENCES “styles\_context” (“id”)  
DEFERRABLE INITIALLY DEFERRED,  
“option\_id” integer NOT NULL REFERENCES “styles\_option” (“id”)  
DEFERRABLE INITIALLY DEFERRED,  
UNIQUE (“context\_id”, “option\_id”)  
)  
;  
COMMIT;

Bruce

---

<div class="post-metadata">

**Author:** ![Dan\_Stillman](https://avatars.discourse-cdn.com/v4/letter/d/ecb155/32.png) [@Dan\_Stillman](https://discourse.citationstyles.org/u/Dan_Stillman)\
**Post date:** [February 29, 2008, 7:38pm UTC](https://discourse.citationstyles.org/t/alternative-gui-idea/443/3 "2008-02-29T19:38:57Z")

</div>

> Thar could be cool. In essence, you’d be automating the wizard process.
> 
> But, of course, one still needs the basic model and process before one  
> would build that automation; right?

To use macros, sure. As just a search tool to find the closest existing  
styles, no, though I’ll grant that this probably wouldn’t be very  
helpful until we had a large number of styles.

> Also, there’s the question of how you’d have those samples. If you had  
> to create them or otherwise intervene in getting them into the system,  
> that might take more work than a good wizard interface.
> 
> Also, I’m not convinced users need their own data for previewing.

I agree. You’d definitely want a default set of data. I was thinking  
that allowing uploading of sample data would be one way of getting  
around the potential legal issues of directly converting the thousands  
of citation styles available from a certain popular commercial  
bibliographic tool, but you actually wouldn’t need to allow uploading of  
sample data for that. You could just have the default set of data  
available in a few formats (e.g., RIS, BibTeX), and a user with an  
existing style in another format could download the sample data,  
generate a bibliography, and paste it in.

Something like this might also help deal with the requests we get on the  
Zotero forums for random styles that users get from their instructors  
without knowing much of anything about the styles.

But you’re right that MakeCSL alone might be sufficient/easier for the  
large majority of cases.