Milestones setzen

[gaenseklein]

@jochmann Es wäre hilfreich, zu wissen, was bis wann fertig sein sollte - also Priorisierungen vorzunehmen. Welche Funktionen sollten bis zum Test-Release / Demoversion in der Landing Page stehen? Welche Funktionen sollte das Programm beim eigentlichen Start des Projektes beherrschen? Wenn du dir darüber schon Gedanken gemacht hast kannst du gerne die Issues hier den Milestones zuordnen. Vielleicht hast du ja auch noch andere Ideen für Milestones?

[jochmann]

habe am Wochenende dazu schon einiges gearbeitet und mir die Basis-Funktionalität anhand eines simulierten Designs vergegenwärtigt. Siehe screenshot. Ich muss das die Woche noch fertig stellen und dann exportiere ich dir die Animationen, dass die Übergänge und wenn-dann-Logik deutlicher wird. Und wir können gemeinsam die jeweils relevante Funktionalität extrahieren und einer road map zuweisen.

Aus dem screenshot gleich ersichtlich: Ich habe bei unserem Markdown-Dialekt ein paar Änderungswünsche (für die Sections), weil es im Design viel übersichtlicher und obendrein näher an GitHub-flavored-Markdown ist. Machbar?

On 23. Nov 2018, at 16:20, gaenseklein notifications@github.com wrote:

@jochmann https://github.com/jochmann Es wäre hilfreich, zu wissen, was bis wann fertig sein sollte - also Priorisierungen vorzunehmen. Welche Funktionen sollten bis zum Test-Release / Demoversion in der Landing Page stehen? Welche Funktionen sollte das Programm beim eigentlichen Start des Projektes beherrschen? Wenn du dir darüber schon Gedanken gemacht hast kannst du gerne die Issues hier den Milestones zuordnen. Vielleicht hast du ja auch noch andere Ideen für Milestones?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/47, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBNyXJ437MhItxVQ7HlRnjbcoL017ks5uyBJCgaJpZM4Yw0N0.

[gaenseklein]

Dein Screenshot ist wieder nicht angekommen. Markdown-Dialekt ändern ist bestimmt machbar. Nur die Sections oder alle Dateneingaben? (also alles, was ||datenstruktur|| hat?) Fänds gut, wenn das einheitlich bleibt, damit User sich nicht unnötig viel Markdown-Dialektik merken müssen

[jochmann]

alles ||datenstruktur||

siehe gif. im besten Fall funktioniert das auch mit dem (optionalen) titel und den Kommentaren in der start-zeile

[gaenseklein]

ok, also aus

||datenstruktur||
asdf
||datenstruktur||

wird

  ```datenstruktur
  asdf
  ``` .

das ist machbar. ist zwar ein bischen arbeit und ich weiß nicht, obs so schlau ist, aber ich hatte die idee auch mal und habs verworfen, weil ich code und data-strukturen auch im markdown getrennt haben wollte. aber wenn du das lieber so haben willst mach ich das.

danke für den screenshot, daraus werden einige aufgaben klarer, die ich mir mal als issues rausarbeite.

[jochmann]

ist halt viel einfacher zu tippen und (in plain text) zu lesen und folgt etablierten konventionen. super, wenn das klappt. wenn auch noch titel und kommentare in die erste Zeile gehen, wäre das super elegant

---

http://jochmann.me exploring meaning in communication

Am 27.11.2018 um 01:14 schrieb gaenseklein notifications@github.com:

ok, also aus

||datenstruktur|| asdf ||datenstruktur|| wird

  asdf
  ``` .
das ist machbar. ist zwar ein bischen arbeit und ich weiß nicht, obs so schlau ist, aber ich hatte die idee auch mal und habs verworfen, weil ich code und data-strukturen auch im markdown getrennt haben wollte. aber wenn du das lieber so haben willst mach ich das.

danke für den screenshot, daraus werden einige aufgaben klarer, die ich mir mal als issues rausarbeite.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[gaenseklein]

ich weiß ja nicht, welche tastatur du benutzt, aber das ` zeichen ist auf einer normalen, deutschen tastatur ein "dead-key". sprich: ich muss shift + taste drücken und dann noch ein leerzeichen hinterher - erst dann und nur dann erscheint `. umständlicher geht es kaum. währenddessen ist | einfach altgr + taste. ehrlich gesagt, ich würde ab da nur noch buttons benutzen, weil mir das den schreibfluss zu sehr unterbricht ein ` zu schreiben - zumal auch noch drei hintereinander. damit quält man user, das ist das gegenteil von einfach zu tippen. hier auf github verwende ich daher meist stumpf die buttons dafür - erst schreiben, dann markieren und button drücken. etablierte konvention ist es auch nicht, denn es ist eigentlich für "code" gedacht - und etablierte konvention ist, dass danach höchstens noch angegeben wird, welcher code (javascript, html, perl, php...) in der box ist, damit das highlightning sich daran ausrichtet und nicht raten muss. zu lesen - naja... ich find das ||datenstruktur|| lesbarer als ```datenstruktur. aber mir solls egal sein, wenn du das haben willst. titel in den header zu schreiben - oh man. natürlich geht das, aber das ist nicht cool weil es die gesamte logik durchbricht die ich dachte bzw. diese logik damit hinfällig ist und neu strukturiert werden muss. der header einer datenstruktur sollte anweisungen beinhalten, keinen content. titel ist aber ein content. anweisung wäre bspw. bei der section "left" oder "right". zumal du grad nur die charts im kopf hast glaube ich - woanders gibts titel doch garnicht und selbst bei charts finde ich den titel eigentlich doof und sollte lieber außerhalb geschehen. aber wenn du die charts-semantik ändern willst mach dafür bitte ein eigenes issue auf

[jochmann]

du kannst die titel auch in einen <section data-tag"titel"> packen. Wichtig sind die, für Referenzierung. Nicht für Darstellung

[gaenseklein]

für die referenzierung ist das aber was ganz anderes als momentan verwendet. momentan wird ein chart-title erzeugt - der imho überflüssig ist und besser außerhalb gelöst werden sollte. ich hatte es mit rein genommen um mal die unterschiede zu sehen, bin aber inzwischen davon überzeugt, dass das totaler blödsinn ist und eben nicht zu den aufgaben von chart.js gehören sollte, einen titel über die chart zu packen. das macht unser slidenote-programm - chart.js soll nur die nötige grafik erstellen.

generell können wir natürlich anbieten, optionale referenzierungen zu erstellen. aber das würde ich auf später verschieben, weils momentan einfach nicht gebraucht wird und erst bei mehr plugins die wir reinnehmen ersichtlich wird, was wir alles als variablen brauchen. eine einmal festgelegte syntax später wieder zu ändern ist doof. daher lieber später erweitern.

[jochmann]

ja, chart-title passt tatsächlich nicht unbedingt. ein data-type macht da mehr sinn. jede semantische section sollte außerdem eine fortlaufende numerierung als ID bekommen, das reicht schon mal für interne querverlinkung. sauberes management von referenzen kümmern wir uns später drum

On 5. Dec 2018, at 02:03, gaenseklein notifications@github.com wrote:

für die referenzierung ist das aber was ganz anderes als momentan verwendet. momentan wird ein chart-title erzeugt - der imho überflüssig ist und besser außerhalb gelöst werden sollte. ich hatte es mit rein genommen um mal die unterschiede zu sehen, bin aber inzwischen davon überzeugt, dass das totaler blödsinn ist und eben nicht zu den aufgaben von chart.js gehören sollte, einen titel über die chart zu packen. das macht unser slidenote-programm - chart.js soll nur die nötige grafik erstellen.

generell können wir natürlich anbieten, optionale referenzierungen zu erstellen. aber das würde ich auf später verschieben, weils momentan einfach nicht gebraucht wird und erst bei mehr plugins die wir reinnehmen ersichtlich wird, was wir alles als variablen brauchen. eine einmal festgelegte syntax später wieder zu ändern ist doof. daher lieber später erweitern.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/47#issuecomment-444318314, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBM1eLUCwmbVPXsI9JT52K85HDxxDks5u1xtMgaJpZM4Yw0N0.

[gaenseklein]

das issue hat seinen ursprünglichen sinn vollkommen verloren und artet zu einem sammelbecken für nicht-issue-relevante probleme aus. die oben genannten probleme werden in den issues

55 Änderung von Datensyntax und

57 interne referenzen/links (oben fälschlicherweise titel benannt)

behandelt. Das Issue ist noch nicht gelöst, aber der thread hier ist imho dafür versaut - daher closed.