Wrong calculation for values and output code

[ChrisGitIt]

Hi all,

i just noticed that the calculation for the converter/test tool is a little off the limits.

To reproduce (on http://www.figs-lab.com/content/datalegreya/convert.html):
1: abcde (as Text)
2: 1,2,3,1,2 (as Data)
=> Result: §0a|0b|2c|3d|0e|2

Expected Result: §0a|1b|2c|3d|1e|2 OR §1a|2b|3c|1d|2e|???

I just had a glimpse at the JS function that produces the output result, but there are several places where it looks very odd and i just don't get it why its written this way.

Are you interested in a rewrite? What should be the rules for the starting value? Currently it always starts with 0. I think it would be nice if the start value is the first value of the data points (so you can decide on your own). What are the rules for having not enough data points? No output? Fillup with last values? Error Message?

Greets,

Chris

[olicorn]

Hi Chris,

first, thank you very much for your commitment, this is the studio's first github and it's amazing to see you contribute like this !

your question covers two topics :
1/ start value for the data
the behaviour you describe correspond to a design choice for the font : each character displays a graph according to the value assigned to this character and the value assigned to the previous character.
Since the first character of a string doesn't have a previous value, by default it takes input's first value as the start value
This can be changed using the § sign which is dedicated to this special case.

Now if I find this behaviour right from a logical view, your feedback makes me think it is not obvious the users, so there is space for improvement. Maybe it would be fine to add a radio button that provides a choice between "start value is 0" or "start value is Data's field's first value".
Or maybe we could make this second choice the default behaviour... What do you think ?
In this case, with your example the data would have to be expanded from 5 to 6 entries (1 for the start value and 1 for each character of the string). See second point about expanding data.

2/ data format flexibility
one of the objectives for this tool was to provide a lot of flexibility regarding the data that the user inputs. For example data lenght doesn't have to fit string lenght. If th user provides data which length is different than the lenght of the string, a linear interpolation with "nearest neighbour" method is made using the Smooth.js library (convert.js, line 82)

Another example : boundary values are automatically detected (and can be forced by the user using the minimal / maximal value fields). In your example, 1 is detected as the minimal value and 3 as the maximal value, so the algorithm expands the range of the data to make a 1 in the input correspond to a 0 in the output.
I am not sure how clear I am...
So in your example, if you put 0 in the minimal value field the result is :
§1a|1b|2c|3d|1e|2

To make it short, I think the calculation is not wrong but the process is not totally transparent for the user. How do you think we can improve ?

[ChrisGitIt]

Hi olicorn,

thanks for your feedback! Here are my thoughts about your comments:

1: If you use the font without the tool, i think the choice to make 0 the default first value is totally understandable. But if you use the convert tool, i think the user expects more "whatever" he entered will be used. So if i enter 1,2,3 i expect a steadily growing line without any buckles. I think it would be even more confusing to add additional radio buttons for "a user choice". I think the user already expressed his choice by entering values. Maybe it might be a good idea to add a visual clue if the data length values differ from the text length value. So its more clear that the output is an interpolated form.

2: I actually don't get the "min/max" value stuff. I mean its obvious (and cool) that a marker is added, but here are some examples and outputs using the following input text: "abcd" and data: "1,2,3,4,5"

• using nothing as minimal:
  Output: §0a|0[-]b|1c|2d|3

• using 0 as minimal:
  §1a|1[-]b|1c|2d|3 (why do the data values change?? why isn't it the same as before??)

using 1 as minimal:
§0a|0[-]b|1c|2d|3 (mmmh, i have to think about the result a lot ...)

I think the most obvious choice would be to remove the input field for the min/max value. Just the radio buttons and the rest will be handled by the tool. Maybe it would be beneficial if the the tool provides more than one min/max symbol (by user choice).

So in conclusion: I'm not sure if i'm to much a programmer and see things different, but i think for a normal user the output results are not that obvious.

Here are my "improvements" that i would recommend:

• The first input data value is always used as the first value.
• Removing the min/max input fields and let the tool do its work (maybe multiple min/max)
• Show a visual hint if the data is interpolated (= more "input data" than "input text") just as a hint for the user so that he is aware of the "mismatch" ...

Also: I think the lines can take 7 directions only (up(3) & down(3) & equal(1) = 7 directions). Is there a way to add a more fine grained distinction? I know this i a lot of graphical work within the font but i have the impression that the user usage would require a more fine grained distinction...

[ChrisGitIt]

Ah, i think i got it why the "min value" is used ... if the users input data is 11,12,13 the user can "shift" the graphs baseline with the min/max ... ah,oh ... mmmhhh ... not sure if this is a good idea ... its actually clever but its not that obvious. Maybe renaming would help or giving a dropdown with values that are usable to shift the value ... for example the "10,20,30" would provide a min dropdown with values 0, 7, etc.) ... ok, i'm thinking out loud right now ... the min/max have to be in correlation to the graph entry points ... the entry points can be at the bottom, top and in between ... due to the limitation of the font i think there can only be three baselines, am i right? But what would happen if the the data values are 10, 9 , 11 and the min value is provided with 10? Mmmh, mmmh ... maybe just give the user a dropdown with "start at bottom" , "start at middle" , "start at top" ? But starting at the top would result in an useless graph ... ok, i stop here. I have to rethink the current approach and what i see as a usefull approach. I'll be back soon. Any feedback is appreciate (even if you think that i'm on the totally wrong track)

[olicorn]

Hi Chris !

I fully agree with you on the first point : I am going to make the modification in the js to remove that strange behavior.
I also agree on your suggestion to add a visual clue when the data length values differs from the text length value. Not sure yet on how to to that, any suggestions ?

On the second point, I think you still don't get the interest I see for the min / max field.
It is useful when you have to compare multiple sets of data within the same range. If you don't specify the boundaries of the range with the min/max fields, you can't see compare the different sets
Here's an image that helps to see it

What do you think ?

Finally, on this subject :
Also: I think the lines can take 7 directions only (up(3) & down(3) & equal(1) = 7 directions). Is there a way to add a more fine grained distinction? I know this i a lot of graphical work within the font but i have the impression that the user usage would require a more fine grained distinction...

Actually we redesigned 67 characters of the original font, for each character there are 16 glyphs that allows to display all the directions. There are 3 variants of the font, so it gives a total of 3216 hand drawn glyphs :)
I'd love to increase the "data resolution" of the font from the current 4 to a nice 11 (0 to 10), but that would mean 20100 glyphs to draw ! Quite a long work...

Also, if one day we decide to make it, I think we would change the base font and take a monospace font, where every character has the same length, meaning no variation in the slope of the curve due to letter width variations...

— Olivier

[ChrisGitIt]

Hi Olivier,

thanks a lot for your visual hints and explanation! I think i had a mental issue with the naming convention "min/max value" <=> "min/max symbol" usage. Probably just renaming the input fields would help. "Lower/Upper Baseline/Boundry" or something like this would make the purpose more obvious. Also i would change "DISPLAY" (beneath min/max) to a more distinct name like "Show min/max symbol" because using the min/max SYMBOLS has nothing to do with the min/max values ... i first had the impression that entering a min/max value would set the min/max symbol to this value.

Mmmh, ok, just had a quick rethought ... i think you are describing a special case of usage (comparing datasets). I don't think that this usecase should be THAT prominent within the tool. I think the main purpose is ONE graph with min/max symbols and the axis legend. Your mentioned usecase is not even directly possible within the tool ... you would need more windows or multiple output (and probably input fields) to really make the "comparing" possible. Maybe this should be a separate tool ... KISS (Keep It Short & Simple)

About the visual hint for non matching input data and input text:
I think a little icon like <---> or <....> that indicates a stretching might be enough. If its not that obvious, i would just add a little hint ... like a little "!!" Icon with a PopUp help text or something like this.

Greets,

Chris

[olicorn]

You are right about the wording issue. I made a few changes in the last commit, hope it is more obvious now.

Also I put the radio buttons for the min / max indicators in a separate place, to avoid confusion between what is related to display and what is related to data conversion.

I changed the behaviour of the first character start value. Now if you want to have data that exactly fit your text, your data's length has to be your text's length + 1.
Example :
text = bob
data = 0 1 2 3
returns => §0b|1o|2b|3

Finally, there is a hint that indicate whether the data is extrapolated or not.

I'm more in javascript than in html/css, I think the way I've done it is a little crappy, but it does the job...
Maybe Tim will change that, or don't hesitate if you see shocking things ;-)

Fully agree to keep it simple, this tool is not designed for comparing, but for conversion. Indeed, it can be useful to people that will use Datalegreya for comparisons in some editing software, like illustrator, indesign etc. So I still think this complexity is necessary.