So was thinking yesterday about an idea, which I explain in a comment
on this ticket:
http://bitbucket.org/csledit/csl-wysiwyg-editor/issue/1/provide-beginner-expert-interface
In particular, could we agree on some metrics (and related
requirements) for how we might actually test whether an approach is
more or less “user-friendly”? I think this is important to avoid
biases intruding on the design process (put bluntly, each of us has a
different idea of what will be more intuitive; best not to rely on
vague criteria to determine who is right).
What I suggest in the above link is how many clicks and how much time
it takes for a user to do two overall operations:
- create a dependent style
- create a standalone style
For this to work, we’d need to standardize the styles in each case,
and probably make sure the users understand what they need upfront.
On requirements, do we agree it’s important that this interface not
only be used to create new styles, but also to edit existing ones?
E.g. Jane Doe creates a new journal style that is a dependent style.
John Smith comes along and notes (say in a comment for the style) that
it omits one key detail. It should be possible for an editor to
quickly identify the problem and fix it (which may mean in this case
converting a dependent style into a non-dependent style). Right?
Thoughts?
Bruce
Oh, and, for sake of argument …
It should be possible for an editor to quickly identify the problem and fix it …
Maybe the repository and editing app recognizes a few different roles,
with an editor defined in flexible ways as people who either:
a) create a style (if you create a style, you get automatic editor rights)
b) have super editor status, meaning they can edit any style
c) people who are granted editing rights by either a or b
In turn, it should be possible to revoke editing rights.
Don’t know; something like that.
Bruce
So I played with the mockup file that Tom (?) has been working on.
It’s not done, but should be suggestive of the subtle, but important,
change I’m suggesting. See attached.
So in panel 1 …
Basic idea is that:
-
the top panel allows you to add the rendering chunks. Each chunk
has a pop-up selector that has a previewed option. In the vast
majority of cases, the style editor chooses one of those. If those
options didn’t work, they then choose “other”, which brings up …
-
… the bottom pane, which configures the rendering in 1. E.g. you
are effectively creating a new macro. You’d need a few different types
of configuration UIs here: names (what’s represented nicely in the
mockup; though missing “substitution”), dates, and for lack of a
better phrase ATM “simple text.”
The current mockup has a distinction between “alias” (dependent)
styles and base styles (new ones). The UIs are different and the “new”
styles can “use template”, where you copy over behavior.
My suggestion is removing this distinction and instead just assume the
info panel drives the style’s pre-population. E.g. a user should
never, ever, have to start from scratch (they should have a choice to
“use existing style”). They should modify existing styles. By
definition, then, the only difference between an alias/dependent style
and a new/base style is that the latter has simply been edited.
I’ve been wondering, too, about how to handle the positional stuff
critical in particular for footnote styles, and I think you take the
same basic approach, but simply add some sub-panels within the top
panel.
Thoughts?
BTW, I used http://balsamiq.com/ to edit the styles.
Bruce
Layout+Grouping8.xml (78 KB)
Oops …On Wed, Jun 2, 2010 at 12:09 PM, Bruce D’Arcus <@Bruce_D_Arcus1> wrote:
E.g. a user should never, ever, have to start from scratch (they should have a choice to
“use existing style”).
That’d be “should NOT have a choice …”
Bruce
Or come to think of it, to translate this into the language of Tom’s
mockup, I guess the ultimate question is what constitutes a "field"
and a “template”?
Is the former simply directly analogous to a CSL “variable”? Or could
it be a collection of variables? E.g. what does the user see when they
have some selection options for these, and what do they see once
they’ve made their selection? Am looking for more detail on mockup #2.
Ditto with “templates.”
Bruce
"On requirements, do we agree it’s important that this interface not
only be used to create new styles, but also to edit existing ones?
E.g. Jane Doe creates a new journal style that is a dependent style.
John Smith comes along and notes (say in a comment for the style) that
it omits one key detail. It should be possible for an editor to
quickly identify the problem and fix it (which may mean in this case
converting a dependent style into a non-dependent style). Right? "
Yes, this is critical.
I believe that the current editor is very close to being usable. It may not
be optimal, however I would like to see it put into the hands of users as
soon as possible, and then iterate based on user feedback.
I like your idea of minimizing the keystrokes to complete a task, however I
think that more important than this would be to provide good clear examples
of use of the editor.
With regards to the wireframe that you attached, I’ve had a look. I don’t
understand why it is a good idea to prevent a user from beginning with an
empty template. I am just getting up to speed on this, so please bear with
me. I’m very much keen to understand your point, so it would be very helpful
is you could explain this in a little more detail.
Thanks you,
Sure.
I don’t mean to be rude, but I’ve explained this many times over the
past few years, without much to show for it. You weren’t here for
those conversations (though they are archived here), so this isn’t
your fault. But I would like to insist that we settle on some concrete
use cases and requirements language, so that we avoid further
confusion. This is a far more difficult problem than I think you or
other people that have considered this realize.
First point to note is that most of the now more than 1100 CSL styles
in existence are the collective work of the people on this list. That
work gives us insight not only into the specifics of how CSL works (or
doesn’t) but also into how citation styles themselves tend to work. I
think it’s reasonable to conclude that:
- Despite the thousands of “styles” in existence, most (I don’t know,
95% or more?) of those are house-named versions of more generic styles
(like APA, Chicago, Harvard). It follows that the vast majority of
future styles that people will create in this new application will be
either exact copies of existing styles (e.g. in CSL language, they are
"dependent styles") or very trivial modifications. E.g. the most
common use case will be “I need a style that looks like X.” In most
cases, that style will already exist. in those that it doesn’t, the
changes will be very minor.
Requirement: it must be easy to choose a style on which to base a new
style, and very quick and easy to a) determine if there needs to be
any changes, b) figure out what those changes are, and c) apply them.
Aside: to your question, giving them a blank style means forcing users
to do a whole lot of wasted work. To get back to my metrics, it will
take them longer.
Another aside: Dan Stillman has more than once floated an interesting
idea that users should be able to create a style that modifying some
example output in place with a rich text editor.
- Within each style, there’s isn’t a huge amount of variation. Put
simply, generic rules tend to go very far. As I’ve said more than
once, for example, there are only four (maybe five) ways to format a
title, there are two ways to format a publisher/place pairing, etc.
Conversely, to work successfully in the wild, styles typically need to
accommodate a wider range of sources than either the style guide or
the style author has explicitly accounted for*. So a system which
requires specification for every single possible type will take longer
to create, and will fail in many cases (e.g. stuff won’t print).
Requirement: styles need to more-or-less correctly format items even
without explicit type definitions.
I think there are more requirements to add (like on integration with
the repository), but I’ll start there.
You might want to start out with asking experienced CSL style authors to
test-drive the editor. Most of them can be reached via the Zotero forums.
RintzeOn Tue, Jul 13, 2010 at 8:16 PM, Ian Mulvany <@Ian_Mulvany>wrote:
