Dear Bruce, dear list,
sorry that I didn’t manage to reply any earlier.
As for the license: We’ve decided to go with the ECL for this project.
I think that should work. Thanks.
If there are any issue with this, people, speak up now.
Well, what is the general roadmap?
Here’s a quick overview of the milestones and dates.
M1: Drag&drop prototype (Feb 05)
M2: Live-Preview (Mar 12)
M3: Additional formatting features (Mar 26)
M4: Back-End, CSL output generator (Apr 02)
M5: Back-End, CSL input reader (own files) (Apr 16)
M6: Back-End, CSL input reader (all files) (Apr 23)
I personally think M6 should be a non-goal, or at least substantially
down the priority list. So long as the rest of the thing is designed
with that in, there shouldn’t be a problem.
I’m still worried about the plan that you guys have here. Questions I have:
-
have you articulated somewhere the basic use case of newbie user
who wants to see if the styles repository has their style, finds it
doesn’t, but wants to create a new one closely modeled on one that it
does? We could imagine a “create new style based on” link, but then
what? What style UI do they see upon clicking that link? -
If you start with the lower-level basic variables, how do you move
up to higher-level stuff? Is that just a separate UI?
I’m not sure we can defer discussions about macros until some later
date; the question goes to the core of CSL and a CSL editing UI. As an
example, I could imagine that the primary drag-and-drop UI only
deals with macros. I could also imagine those “fields” being a pop-up
list that allows users to choose their preferred rendering, and at
some point an “other” or similar option that brings up a dialog that
allows creating or editing a macro (e.g. moving around lower-level
formatting variables and such).
Bruce