Closed gaenseklein closed 5 years ago
@jochmann ich find zweite variante inzwischen sinnvoller, da sie sich halt auch viel leichter in zukunft erweitern kann für user, die wirklich mehr wollen. für die standarduser sind das logisch erklärbare namen und eindeutiger und leichter zu lernen als an md-code angelehnte syntax. was denkst du?
mal ne komplette chart mit der neuen syntax:
´´´chart:line
$xaxis: Months
$yaxis: Arctic Sea Icecoverage in Thousands of km²
$label1: 2010
$label2: 2011
$label3: 2012
$source: Wikipedia
$description: Chart representing coverage of ice in arctic sea from 2010 to 2012 compared by month
Jan:10:10:9
Mar:10:20:20
May: 20:20:20
July:22:21:21
Sep:19:18:18
Nov:12:12:11
´´´
Zum Vergleich:
´´´chart:line
## Months
## Arctic Sea Icecoverage in Thousands of km²
### 2010
### 2011
### 2012
[^source]: Wikipedia
> Chart representing coverage of ice in arctic sea from 2010 to 2012 compared by month
Jan:10:10:9
Mar:10:20:20
May: 20:20:20
July:22:21:21
Sep:19:18:18
Nov:12:12:11
´´´
Ich finde das trotz Namen immer noch ein wenig verwirrend. Vor allem weiß ich nicht, ob es so glücklich ist, alles über Variablen zu lösen wenn doch die einfachste Lösung eine CSV-Struktur ist. (CSV lässt sich auch einfach importieren)
'''chart:line months, Jan:10:10:9, Mar:10:20:20, May: 20:20:20, July:22:21:21, Sep:19:18:18, Nov:12:12:11 ice (in thousands of km²), 200, 150, 100, 80, 40, 10 ''' chart representing coverage of ice in arctic sea from 2010 to 2012 (source: Wikipedia)
Am 08.03.2019 um 05:06 schrieb gaenseklein notifications@github.com:
@jochmann https://github.com/jochmann ich find zweite variante inzwischen sinnvoller, da sie sich halt auch viel leichter in zukunft erweitern kann für user, die wirklich mehr wollen. für die standarduser sind das logisch erklärbare namen und eindeutiger und leichter zu lernen als an md-code angelehnte syntax. was denkst du?
mal ne komplette chart mit der neuen syntax:
´´´chart:line $xaxis: Months $yaxis: Arctic Sea Icecoverage in Thousands of km² $label1: 2010 $label2: 2011 $label3: 2012 $source: Wikipedia $description: Chart representing coverage of ice in arctic sea from 2010 to 2012 compared by month
Jan:10:10:9 Mar:10:20:20 May: 20:20:20 July:22:21:21 Sep:19:18:18 Nov:12:12:11 ´´´ — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/76#issuecomment-470797843, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBHdBcENsR8zVK_i_oSIEprH9DRPHks5vUeHfgaJpZM4bdiCa.
nein, nur mit csv lässt es sich nicht, wie man an deinem beispiel gut sieht ;)
du vermischst metainfos mit daten. dadurch kommt nur noch murks raus:
metainfo, metainfo+datengemisch, metainfo+datengemisch, metainfo+datengemisch...
metainfo, daten, daten, daten...
das ist nicht parsebar, hat nichts mit einer csv zu tun (die erste zeile macht ja eine rekursive csv auf, also eine csv innerhalb der csv mit doppelpunkt als trennzeichen) und schon garnicht logisch erklärbar. was soll die zweite zeile bedeuten? die weiteren metainfos, die bei mir in der chart mit parsebar waren (aus gutem grund) hast du bei deinem beispiel ausgeklammert. kann man machen, dann aber ists nicht mehr bestandteil der chart und für selbige nicht fassbar. die description wird bspw. von chartist nur für screenreader verwendet - bei deinem beispiel hat chartist darauf garkeinen zugriff. die quelle ist imho nicht wirklich wichtig innerhalb der chart, aber macht schon sinn sie darin zu haben. mit anderen worten: wir kämen zu völlig unterschiedlichen slides, selbst wenn ich chartist deine csv-struktur beibringen könnte.
eine csv ist hauptsächlich eine abbildung von daten, eine tabelle mit komma geschrieben. das hatte ich auch extra schon erfasst, so dass es möglich ist, bestimmte metainfos bereits in die csv zu integrieren. eine reine csv-schreibweise ohne description etc. wäre: ´´´chart months, january, february, march, april icecoverage in thousand km, 10, 20, 30, 40 ´´´ bereits beim einfügen eines zweiten datensatzes wird die durchmischung aber schon an ihre grenzen stoßen, daher hatte ich sie extra halbwegs rausgeklammert: ´´´chart
january, february, march, april 2009, 10, 20, 30, 40 2010, 20, 30, 40, 50 ´´´ daher finde ich es am userfreundlichsten, wenn das strikt getrennt wird - daten und metadaten. dann ists eindeutig und für den user leichter verständlich, wie er seine daten formatieren muss. heißt: die daten zieht er aus der csv, die metadaten gibt er von hand ein. da metadaten nicht so viele sind und daten schon ist das super. wenn wir jetzt noch dem user an die hand geben, dass er die datenstruktur auswählen kann (horizontale vs. vertikale tabelle) dann hat er alles, was er braucht um schnell und einfach charts zu erstellen.
fraglich bleibt nur noch, wie die metadaten als metadaten kenntlich gemacht werden können bzw. deren syntax und da gibt es eben mind. zwei verschiedene wege - sich am md-code orientieren und den versuchen auf die metadaten zu übertragen (erster ansatz) oder eben sich davon zu lösen und lieber descriptive namen für die metadaten benutzen (zweiter ansatz). ich präferiere inzwischen eindeutig zweiten ansatz.
alle metadaten sind übrigens optional. sie sind eine erweiterung der chart für leute, die mehr wollen. was nötig ist ist der datensatz, alles darüber hinaus ist optional. ein datensatz besteht aus bezeichner (x-achsenpunkt-label) und zugewiesenem wert (bspw: januar:10, bei zwei datensätzen januar:10:20) das insertmenü kann bei der eingabe der metadaten sehr hilfreich sein. folgende minimal-charts sind gültig: ´´´chart a:1 b:2 c:3 d:4 ´´´ aber auch momentan csv-style: ´´´chart a,b,c,d 1,2,3,4 ´´´
und vertikaler csv-style: ´´´chart a,1 b,2 c,3 d,4 ´´´
daher ja die idee, die metadaten komplett aus dem datenstyle heraus zu halten um das leichter parsen zu können, aber auch für die user leichter zu entscheiden.
die daten sollten bspw. per copy-paste aus excel eingefügt werden können, das wäre die einfachste form für die meisten user. eine direkte csv ist ja eher aus einer datenbank. aber die struktur ist die selbe wie bei copy-paste aus excel. nur das trennzeichen unterscheidet sich. als trennzeichen momentan implementiert sind "[tab],;".
für die zukunft gedacht: es gibt noch viele interessante einstellungsmöglichkeiten für user, die ich in späteren versionen nachträglich installieren würde.[^*] (für den start reicht was wir haben) die sind ebenso optional, aber damit ist es wirklich möglich, die chart an deine bedürfnisse anzupassen. daher tendiere ich sehr stark zur zweiten lösung, der deskriptiven. das muss nicht mit $variable:wert sein, aber es ist ein gutes beispiel für deskriptiv. es könnte auch ein "kopf" eingebaut werden, so dass daten und metadaten getrennt sind. bspw:
´´´chart
xaxis: Months
yaxis: Icecoverage
---
january: 20
february:30
´´´
[^*]: Beispielsweise linechart bei 0 starten lassen oder nicht, timestamp als labels und automatisches skalieren nach der timestamp, zeichen, was hinter dem wert angezeigt werden soll wie bspw. € oder $, ob prozent auf pie angezeigt werden soll oder originalwert oder beides...
hast mich überzeugt. die Variante mit Kopf (sollte eigentlich auch als Footer gehen) finde ich viel besser, dass wir auch konzeptionell die CSV-Struktur trennen.
Wie genau wir die Meta-Daten-Sektion gestalten, sollten wir später noch mal eleganter machen.
Am 11.03.2019 um 01:54 schrieb gaenseklein notifications@github.com:
für die zukunft gedacht: es gibt noch viele interessante einstellungsmöglichkeiten für user, die ich in späteren versionen nachträglich installieren würde.[^*] (für den start reicht was wir haben) die sind ebenso optional, aber damit ist es wirklich möglich, die chart an deine bedürfnisse anzupassen. daher tendiere ich sehr stark zur zweiten lösung, der deskriptiven. das muss nicht mit $variable:wert sein, aber es ist ein gutes beispiel für deskriptiv. es könnte auch ein "kopf" eingebaut werden, so dass daten und metadaten getrennt sind. bspw:
´´´chart xaxis: Months yaxis: Icecoverage
january: 20 february:30 ´´´ [^*]: Beispielsweise linechart bei 0 starten lassen oder nicht, timestamp als labels und automatisches skalieren nach der timestamp, zeichen, was hinter dem wert angezeigt werden soll wie bspw. € oder $, ob prozent auf pie angezeigt werden soll oder originalwert oder beides...
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/76#issuecomment-471372277, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBCbXUZ4afMKgO90i3dMFXmtGlmgtks5vVak7gaJpZM4bdiCa.
btw, wir sollten uns auch hier an existierenden Konventionen orientieren. Fletcher Penny's Multimarkdown (populär für Blogs) arbeitet mit einem Subset von YAML für Metadaten: https://hiltmon.com/blog/2012/06/18/markdown-metadata/
Am 11.03.2019 um 07:35 schrieb Jakob Jochmann jakob@jochmann.me:
hast mich überzeugt. die Variante mit Kopf (sollte eigentlich auch als Footer gehen) finde ich viel besser, dass wir auch konzeptionell die CSV-Struktur trennen.
Wie genau wir die Meta-Daten-Sektion gestalten, sollten wir später noch mal eleganter machen.
Am 11.03.2019 um 01:54 schrieb gaenseklein <notifications@github.com mailto:notifications@github.com>:
für die zukunft gedacht: es gibt noch viele interessante einstellungsmöglichkeiten für user, die ich in späteren versionen nachträglich installieren würde.[^*] (für den start reicht was wir haben) die sind ebenso optional, aber damit ist es wirklich möglich, die chart an deine bedürfnisse anzupassen. daher tendiere ich sehr stark zur zweiten lösung, der deskriptiven. das muss nicht mit $variable:wert sein, aber es ist ein gutes beispiel für deskriptiv. es könnte auch ein "kopf" eingebaut werden, so dass daten und metadaten getrennt sind. bspw:
´´´chart xaxis: Months yaxis: Icecoverage
january: 20 february:30 ´´´ [^*]: Beispielsweise linechart bei 0 starten lassen oder nicht, timestamp als labels und automatisches skalieren nach der timestamp, zeichen, was hinter dem wert angezeigt werden soll wie bspw. € oder $, ob prozent auf pie angezeigt werden soll oder originalwert oder beides...
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/76#issuecomment-471372277, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBCbXUZ4afMKgO90i3dMFXmtGlmgtks5vVak7gaJpZM4bdiCa.
https://stackoverflow.com/questions/25410701/how-do-i-include-meta-tags-in-pandoc-generated-html#32074800 https://stackoverflow.com/questions/25410701/how-do-i-include-meta-tags-in-pandoc-generated-html#32074800
https://de.wikipedia.org/wiki/YAML https://de.wikipedia.org/wiki/YAML
Am 11.03.2019 um 07:40 schrieb Jakob Jochmann jakob@jochmann.me:
btw, wir sollten uns auch hier an existierenden Konventionen orientieren. Fletcher Penny's Multimarkdown (populär für Blogs) arbeitet mit einem Subset von YAML für Metadaten: https://hiltmon.com/blog/2012/06/18/markdown-metadata/ https://hiltmon.com/blog/2012/06/18/markdown-metadata/
Am 11.03.2019 um 07:35 schrieb Jakob Jochmann <jakob@jochmann.me mailto:jakob@jochmann.me>:
hast mich überzeugt. die Variante mit Kopf (sollte eigentlich auch als Footer gehen) finde ich viel besser, dass wir auch konzeptionell die CSV-Struktur trennen.
Wie genau wir die Meta-Daten-Sektion gestalten, sollten wir später noch mal eleganter machen.
Am 11.03.2019 um 01:54 schrieb gaenseklein <notifications@github.com mailto:notifications@github.com>:
für die zukunft gedacht: es gibt noch viele interessante einstellungsmöglichkeiten für user, die ich in späteren versionen nachträglich installieren würde.[^*] (für den start reicht was wir haben) die sind ebenso optional, aber damit ist es wirklich möglich, die chart an deine bedürfnisse anzupassen. daher tendiere ich sehr stark zur zweiten lösung, der deskriptiven. das muss nicht mit $variable:wert sein, aber es ist ein gutes beispiel für deskriptiv. es könnte auch ein "kopf" eingebaut werden, so dass daten und metadaten getrennt sind. bspw:
´´´chart xaxis: Months yaxis: Icecoverage
january: 20 february:30 ´´´ [^*]: Beispielsweise linechart bei 0 starten lassen oder nicht, timestamp als labels und automatisches skalieren nach der timestamp, zeichen, was hinter dem wert angezeigt werden soll wie bspw. € oder $, ob prozent auf pie angezeigt werden soll oder originalwert oder beides...
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/76#issuecomment-471372277, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBCbXUZ4afMKgO90i3dMFXmtGlmgtks5vVak7gaJpZM4bdiCa.
ok, also kopf ist es. footer würde auch gehen, aber metadaten stehen normalerweise im kopf ;)
meine schreibweise von oben für den kopf war ja schon sehr nah an yaml dran. als trennzeichen zwischen metadaten und daten hatte ich --- gewählt, was der yaml-definition von blöcken entspricht. der rest sind einzelzuweisungen. das ist lesbar und verständlich für menschen. ob wir noch listen einfügen (für datensetlabel?) weiß ich grad nicht obs sinn macht.
dann schreib ich den chart-parser mal um, damit der das reflektiert. sollte relativ zügig gehen.
der chart-parser ist jetzt umgeschrieben und erfasst metadaten und daten getrennt. die trennzeile ist auf --- gestellt. die syntax lasse ich über einen syntax-container steuern, so dass sie an einer stelle zentral eingegeben/geändert werden kann, wenn wir da noch weiter rumprobieren wollen. einstellungen momentan:
newtheme.syntaxContainer = {
//define here new syntax to use for identifiers etc:
headseparator:"---", //line with headseparator will separate metadata(before) from data(after)
dataseparators:[":","\t",",",";"], //possible separators for data-structure (csv or similar)
//metadata:
metadataseparator:":", //separator for metadata-structure - eg: [identifier][separator][value] like xaxis:10
xaxis:"xaxis", //xaxis-label-identifier
yaxis:"yaxis", //yaxis-label-identifier
datasetidentifier:"dataset", //datasetidentifier
//description:"description", //for screenreaders, not implemented yet
//source:"source", //source of data, not implemented yet
}
ob die datenstruktur horizontal oder vertikal ist teste ich einfach, indem ich mir die erste zeile angucke. enthält sie keine zahlen (ausnahme erstes element) dann ist es eine horizontale struktur, weil die erste zeile nur labels enthält. bspw:
january,february,march
1,2,3
4,5,6
ist horizontal (1,2,3 ist erstes datenset, 4,5,6 zweites) während
january,1,4
february,2,5
march,3,6
vertikal ist, da erste zeile (bis auf erstes element) nur nummern hat. schwierig wirds natürlich mit reinen zahlen als daten. die würden jetzt immer als vertikal interpretiert. dafür vielleicht doch möglichkeit einführen zu sagen, was die datenstruktur ist.
insgesamt bin ich damit zufrieden, es ist gut erweiterbar um mehr optionen und lässt sich zentral ansteuern und ändern, falls wir mit der syntax doch mal unzufrieden sind. nur die separierung zwischen daten und metadaten als verschiedenen blöcken/kopf ist jetzt erstmal festgelegt.
Stark
http://jochmann.me exploring meaning in communication
Am 11.03.2019 um 19:39 schrieb gaenseklein notifications@github.com:
der chart-parser ist jetzt umgeschrieben und erfasst metadaten und daten getrennt. die trennzeile ist auf --- gestellt. die syntax lasse ich über einen syntax-container steuern, so dass sie an einer stelle zentral eingegeben/geändert werden kann, wenn wir da noch weiter rumprobieren wollen. einstellungen momentan:
newtheme.syntaxContainer = { //define here new syntax to use for identifiers etc: headseparator:"---", //line with headseparator will separate metadata(before) from data(after) dataseparators:[":","\t",",",";"], //possible separators for data-structure (csv or similar) //metadata: metadataseparator:":", //separator for metadata-structure - eg: [identifier][separator][value] like xaxis:10 xaxis:"xaxis", //xaxis-label-identifier yaxis:"yaxis", //yaxis-label-identifier datasetidentifier:"dataset", //datasetidentifier //description:"description", //for screenreaders, not implemented yet //source:"source", //source of data, not implemented yet } ob die datenstruktur horizontal oder vertikal ist teste ich einfach, indem ich mir die erste zeile angucke. enthält sie keine zahlen (ausnahme erstes element) dann ist es eine horizontale struktur, weil die erste zeile nur labels enthält. bspw:
january,february,march 1,2,3 4,5,6 ist horizontal (1,2,3 ist erstes datenset, 4,5,6 zweites) während
january,1,4 february,2,5 march,3,6 vertikal ist, da erste zeile (bis auf erstes element) nur nummern hat. schwierig wirds natürlich mit reinen zahlen als daten. die würden jetzt immer als vertikal interpretiert. dafür vielleicht doch möglichkeit einführen zu sagen, was die datenstruktur ist.
insgesamt bin ich damit zufrieden, es ist gut erweiterbar um mehr optionen und lässt sich zentral ansteuern und ändern, falls wir mit der syntax doch mal unzufrieden sind. nur die separierung zwischen daten und metadaten als verschiedenen blöcken/kopf ist jetzt erstmal festgelegt.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
das insert-menü reflektiert jetzt auch die änderungen an der syntax. das insertmenü bzw. deren buttons sind momentan händisch programmiert weil es so wenige sind. da hatte es weniger aufwand, das schnell runter zu schreiben als ne logik reinzuprogrammieren nach denen die buttons automatisch aufgebaut werden. kann in der zukunft aber kommen. das insert-menü ist darüber hinaus auch relativ intelligent gehalten, so dass es bspw. nach einem metadatenkopf ausschau hält und dort einfügt, falls der user mal an der falschen stelle ist. ebenso wird ein metadatenkopf erstellt falls keiner da ist. und datensatzlabels werden automatisiert weitergeführt.
@jochmann wie am telefon besprochen machen wir hier n feature-freeze für version 0.9. weitere einstellungsmöglichkeiten werden erst für spätere version evaluiert. wir starten mit dem, was wir jetzt haben. ich schließe daher das issue - falls falsch verstanden, bescheid geben. falls du lieber nochmal gucken willst: schau dir auf http://gionkunz.github.io/chartist-js/examples.html die beispiele an. schon geil, was wir da alles mit einstellen lassen könnten mit der syntax.
das theming der chart (wie dick die striche, bars etc. sowie farben vom label, hintergrund, schrift, line, bar etc.) sollte und kann vom theme bestimmt werden. das läuft alles über css. kannst du gerne mit rumspielen.
sehr cool. aber richtig, dass wir erst mal feature freeze machen
Am 14.03.2019 um 00:27 schrieb gaenseklein notifications@github.com:
@jochmann https://github.com/jochmann wie am telefon besprochen machen wir hier n feature-freeze für version 0.9. weitere einstellungsmöglichkeiten werden erst für spätere version evaluiert. wir starten mit dem, was wir jetzt haben. ich schließe daher das issue - falls falsch verstanden, bescheid geben. falls du lieber nochmal gucken willst: schau dir auf http://gionkunz.github.io/chartist-js/examples.html http://gionkunz.github.io/chartist-js/examples.html die beispiele an. schon geil, was wir da alles mit einstellen lassen könnten mit der syntax.
das theming der chart (wie dick die striche, bars etc. sowie farben vom label, hintergrund, schrift, line, bar etc.) sollte und kann vom theme bestimmt werden. das läuft alles über css. kannst du gerne mit rumspielen.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/76#issuecomment-472645556, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBAJXzltk5DmdQPz_XF3z9U9X1T_iks5vWYltgaJpZM4bdiCa.
charts haben bisher folgende zusatzinfos/metainfos implementiert:
was noch interessant wäre/keine syntax hat und gut in einer chart und nicht besser extern geleistet wird:
zusätzlich wäre es schön, für advanced-user feinheitseinstellungen für die chart zuzulassen.
oder soll die syntax lieber aussagekräftiger/selbsterklärender sein und sich nicht an der syntax hier richten, bspw: