csledit license, roadmap (was macros vs. types)

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:

  1. 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?

  2. 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).