No subject
Sun Feb 13 00:30:12 CET 2011
The bottom line is: try to factor (i.e. avoid repetitions) as much as possible, while keeping enough information to avoid any ambiguity.
A few important points I'd like to make to begin with, and the conclusions I draw from them:
1) a label without legend is pretty much useless as soon as you have more than one curve in a plot => reserve top labels for titles or context information, use legends otherwise (even over left labels)
2) legends tend to appear on the curves too often (as per Murphy's law) and you need to move them manually, which is a pain => if there is only one curve use a left label, if there are more use a legend as mentioned in 1) but allow the legend to be placed above the plot (as sort of top label if you wish, still inside the plot object but above the top X axis)
3) as legends are important and should take up as little space as possible, and since plots are usually wider than tall as Barth noticed, we should lay them out horizontally by default, while I think "Display vertically" is the default right now
4) units are very very important, they have to be shown if they exist, and be as close as possible to the corresponding axis => either put it in parentheses or brackets after the name of the variable, or on the axis if it's the same for all plotted curves
5) try to keep legends short => if all curves have the same X vector, put its name in the bottom label and use only the Y vector name in the legend (right now the x vector is repeated uselessly). The same applies for units: if all curves have the same unit (which should very often be the case, at least until we support multiple axes), then put the unit on the axis and don't repeat it in the legend
6) I presume we can make the assumption that identical units imply identical quantities
A small, slightly unrelated point while I'm thinking of it: let's not forget that at some point it would be nice to support dual/multiple axes. I think we should do something like Origin: http://www.originlab.com/www/products/image/graph_multipleXYaxes_tchgrph_486px.png (btw, coloring the axes like the corresponding curve is a pretty cool option). This shows again that the top label is not very well suited to put unit information, or even variable names.
So, now let's try to do it in pseudo-code. Barth, this is just so that you forgive me for the numerous requirements and get motivated to do it for 2.0.3 :-) Of for Peter, if he beats you to it.
I think it requires the following properties in plot objects (maybe they are already there, I haven't checked):
- legend position enum: above plot (default), in plot fixed position, in plot auto position (for the future, when we use collision detection to automatically put it somewhere it minimally covers curves!)
- legend layout: horizontal (default), vertical
- legend wrap: reduce font size, carriage return (I'm writing this since I'm thinking of it, but that's probably for post-2.0.3). That is what "legends should be wrapped to always fit inside their plot" hints at in the roadmap
- legend show: always, auto (default - means yes if there is more than one curve, no otherwise), never (maybe the user has put it manually, or in only one plot)
- legend item contents: Y vector name (default), Y vector name + [unit], quantity: Y vector name + [unit], Y vector name vs X vector name, etc... (there is probably a smarter way to handle all combinations, maybe another property to remember whether x, y, both or none need units...)
- show labels: (enum with bit masks, I suppose) left/top/right/bottom with right and top only appearing when explicitly requested, the others automatically based on the algorithm below
Now the algorithm (it is not 100% complete and some "details" are omitted, but I believe it gives a good idea of the approach and should be implementable in a reasonable time):
- For each plot:
- Initialize the X and Y axis labels with "quantity: vectorName [unit]" of the 1st curve - we'll remove what's not common as we process the contents
- If only one curve: deactivate legend if needed, according to legend show option
- Else: activate legend if not explicitly deactivated, and for each additional curve:
- X-vector check:
- If the X vector is the same: good, move on
- Else: legend items should indicate Y vs X (and possibly X unit / quantity as well if they differ)
- Y-vector check: are quantity/units the same?
- If yes: good (maybe check that vector names are not the same, or we need the long, unique names?)
- Else: keep the common part, and add [unit] or quantity + [unit] to the legend item for all curves to make sure that each has the correct info. Remove from the axis label what's added to each item, e.g. if each item shows the unit then don't show it on the axis.
- Now that we know what to put in it, just paint the legend and labels, honoring the above properties!
So, I hope this is somewhat understandable and makes sense. Otherwise don't hesitate to ask/discuss.
I'd really like to get this right, because labels and auto-layout are right now the two points that get on people's nerves while they really shouldn't. I think we should keep auto-layout for 2.0.4, but we should handle at least that for 2.0.3. Hopefully it can happen quickly, as I believe it's the last "feature" point on the agenda for the new release (excepting some quality assurance and "minor" issues like the labels which don't all shrink, as reported by Peter and which we will decide to fix or postpone on a case-by-case basis).
Cheers,
Nicolas
------=_Part_76754_748957484.1297554891392
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Arial; font-size: 10pt; color: #000000'>> Hmm.=
.. after thinking about it, I chose the latter, since plots are
usually wider than tall, and P, Q, and R can very easily fill<div>> up =
the Y label space. </div>
<div>> P, Q, and R disappear from the top if the legend is enabled. <br>=
</div>So, sorry to have taken so long to answer, but here is what I'd do fo=
r that top label / margin / legend stuff. When you see the length of the ma=
il, you'll know why I needed some time to prepare it :-)<br>From what I've =
seen (see quote just above) it goes in the same direction as Barth thought,=
maybe just a bit further...<div class=3D"gmail_quote"><div><br>The bottom =
line is: try to factor (i.e. avoid repetitions) as much as possible, while =
keeping enough information to avoid any ambiguity. <br>A few important poin=
ts I'd like to make to begin with, and the conclusions I draw from them:<br=
>1) a label without legend is pretty much useless as soon as you have more =
than one curve in a plot =3D> reserve top labels for titles or context i=
nformation, use legends otherwise (even over left labels)<br>2) legends ten=
d to appear on the curves too often (as per Murphy's law) and you need to m=
ove them manually, which is a pain =3D> if there is only one curve use a=
left label, if there are more use a legend as mentioned in 1) but allow th=
e legend to be placed above the plot (as sort of top label if you wish, sti=
ll inside the plot object but above the top X axis)<br>3) as legends are im=
portant and should take up as little space as possible, and since plots are=
usually wider than tall as Barth noticed, we should lay them out horizonta=
lly by default, while I think "Display vertically" is the default right now=
<br>4) units are very very important, they have to be shown if they exist, =
and be as close as possible to the corresponding axis =3D> either put it=
in parentheses or brackets after the name of the variable, or on the axis =
if it's the same for all plotted curves<br>5) try to keep legends short =3D=
> if all curves have the same X vector, put its name in the bottom label=
and use only the Y vector name in the legend (right now the x vector is re=
peated uselessly). The same applies for units: if all curves have the same =
unit (which should very often be the case, at least until we support multip=
le axes), then put the unit on the axis and don't repeat it in the legend<b=
r>6) I presume we can make the assumption that identical units imply identi=
cal quantities<br><br>A small, slightly unrelated point while I'm thinking =
of it: let's not forget that at some point it would be nice to support dual=
/multiple axes. I think we should do something like Origin: http://www.ori=
ginlab.com/www/products/image/graph_multipleXYaxes_tchgrph_486px.png (btw, =
coloring the axes like the corresponding curve is a pretty cool option). Th=
is shows again that the top label is not very well suited to put unit infor=
mation, or even variable names.<br><br>So, now let's try to do it in pseudo=
-code. Barth, this is just so that you forgive me for the numerous requirem=
ents and get motivated to do it for 2.0.3 :-) Of for Peter, if he beats you=
to it.<br><br>I think it requires the following properties in plot objects=
(maybe they are already there, I haven't checked):<br>- legend position en=
um: above plot (default), in plot fixed position, in plot auto position (fo=
r the future, when we use collision detection to automatically put it somew=
here it minimally covers curves!)<br>- legend layout: horizontal (default),=
vertical<br>- legend wrap: reduce font size, carriage return (I'm writing =
this since I'm thinking of it, but that's probably for post-2.0.3). That i=
s what "legends should be wrapped to always fit inside their plot" hints at=
in the roadmap<br>- legend show: always, auto (default - means yes if ther=
e is more than one curve, no otherwise), never (maybe the user has put it m=
anually, or in only one plot)<br>- legend item contents: Y vector name (def=
ault), Y vector name + [unit], quantity: Y vector name + [unit], Y vector n=
ame vs X vector name, etc... (there is probably a smarter way to handle all=
combinations, maybe another property to remember whether x, y, both or non=
e need units...)<br>- show labels: (enum with bit masks, I suppose) left/to=
p/right/bottom with right and top only appearing when explicitly requested,=
the others automatically based on the algorithm below<br><br>Now the algor=
ithm (it is not 100% complete and some "details" are omitted, but I believe=
it gives a good idea of the approach and should be implementable in a reas=
onable time):<br>- For each plot:<br> - Initialize the X and Y axis l=
abels with "quantity: vectorName [unit]" of the 1st curve - we'll remove wh=
at's not common as we process the contents<br> - If only one curve: d=
eactivate legend if needed, according to legend show option<br> - Els=
e: activate legend if not explicitly deactivated, and for each additional c=
urve:<br> - X-vector check: <br> &=
nbsp; - If the X vector is the same: good, move on<br> &nb=
sp; - Else: legend items should indicate Y vs X (and possibly X unit =
/ quantity as well if they differ)<br> - Y-vector check: =
are quantity/units the same? <br> - If yes: g=
ood (maybe check that vector names are not the same, or we need the long, u=
nique names?)<br> - Else: keep the common par=
t, and add [unit] or quantity + [unit] to the legend item for all curves to=
make sure that each has the correct info. Remove from the axis label what'=
s added to each item, e.g. if each item shows the unit then don't show it o=
n the axis.<br> - Now that we know what to put in it, jus=
t paint the legend and labels, honoring the above properties!<br><br>So, I =
hope this is somewhat understandable and makes sense. Otherwise don't hesit=
ate to ask/discuss. <br>I'd really like to get this right, because labels a=
nd auto-layout are right now the two points that get on people's nerves whi=
le they really shouldn't. I think we should keep auto-layout for 2.0.4, but=
we should handle at least that for 2.0.3. Hopefully it can happen quickly,=
as I believe it's the last "feature" point on the agenda for the new relea=
se (excepting some quality assurance and "minor" issues like the labels whi=
ch don't all shrink, as reported by Peter and which we will decide to fix o=
r postpone on a case-by-case basis).<br><br>Cheers,<br><br>Nicolas<br><br><=
br></div></div></div></body></html>
------=_Part_76754_748957484.1297554891392--
More information about the Kst
mailing list