soztag / soztag.github.io Goto Github PK

get back to gerald about this, make sure this looks/feels like other laboratory or sabine-pfeiffer.de projects.

erst nach vertragsabschkuss

maybe as a brainstorming thing before the meeting?

depends on digitalcraftsman/hugo-agency-theme#73

or maybe use Sabine's Logos, though that might clash with the other typography.
Existing photos are just placeholders to avoid copyright shenanigans.

• favicons
• wortmarke landscape
• wortmarke portrait
• nur q

jeweils als vector, raster und quadratisch zugeschnitten

see email to sandra, sabine etc.

etwa: https://about.gitlab.com/handbook/#paid-time-off

depends on digitalcraftsman/hugo-agency-theme#74

https://kim.uni-hohenheim.de/95493

that's what it is for after all ..
Right now, they are just pasted in as static assets.

@sabpf the idea is that we try a Q-approach (with people as people-variables) with the BIBB/BAuA data (selected variables on workplace characteristics), and see whether we can find clusters.

Methodological interest would be to try the Q-approach, but with a different algorithm (not PCA; but perhaps Multiple-Correspondence or some other clustering approach).

Substantive interest would be to see whether we can actually find a more nuanced typology of workplaces, including an appreciation of creativity in supposedly "manual" jobs etc.

based on biopolitics, subjectivation, etc.

also highlight publications in another way, they seem hard to find.

https://kim.uni-hohenheim.de/95499

Hier eine Tagesordnung für diese Fragen:

Output des Toolchains

Erstmal grundsätzliches: Unser Toolchain (R, shiny, bookdown/blogdown/rmarkdown) produziert zwei Arten von Ergebnissen:

1. Statische HTML-Seiten, ggfs. mit etwas Interaktivität durch Client-side JavaScript (also nur im Browser). (Statische Ergebnisse können übrigens immer auch nach PDF, Word uvam. gerendert werden).
2. Shiny-Webapps, mit viel Interaktivität, ggfs. eingebunden in statische HTML-Seiten.

Dazu:

• Wann immer möglich versuche ich mit 1. auszukommen, weil das keine aktive Serverinstanz braucht, und somit günstiger/zukunftssicherer ist.
• Eine aktive Erhebung ist ein Sonderfall von 2.
• Sowohl 1 als auch 2 akzeptieren beliebiges CSS, d.h. look and feel können vollständig angepasst werden.

Unser Toolchain für konkrete Projekte immer statisches HTML produziert.
Das Toolchain hat große Vorteile: Ergebnisse können automatisch aktualisiert werden und sind robust zu reproduzieren.

Eine tiefe Integration direkt in ein CMS (Contao) ist daher schwierig (außer iFrames o.ä.?).

Es wäre daher vielleicht am einfachsten, jedenfalls auf die statischen Seiten nach 1 einfach zu verlinken.

Hinter den Shiny-Apps nach 2. muss immer eine Server-Instanz stehen, auf der eine lizensierte Version von RStudio Software läuft.

Domain für QWrks (erledigt): qwrks.labouratory.de

Einzelne Projekte können dann unter qwrks.labouratory.de/project leben, oder labouratory.de/qwrks/projekt, ist eigentlich egal.

Potentielles Problem: Falls Webspace und/oder Hosting (s.u.) von der Uni Hohenheim kommt, gibt es dann da ein Problem mit einer “fremden” Domain, die aber Uni Ressourcen nutzt? Frage mich ob die Uni Hohenheim auf ihre Server verweisen lässt von fremden Domains... – auch Datenschutz könnte erschwert werden.

Landing Page für QWrks:

Idee wäre eine einfache (single-page) Landing Page, auf der sich Besucher

1. oberflächlich über QWrks als Ansatz informieren können und
2. Links zu laufenden und abgeschlossenen Projekten (soweit diese denn öffentlich sein dürfen).
3. möglichst nichts von sabinepfeiffer.de etc. zu duplizieren.

Ich habe (etwas voreilig) einen Entwurf hier erstellt: qwrks.github.io.

Bitte entschuldigt, dass war ein Missverständnis meinerseits; ich hatte mir gemerkt, das Gerald mit Contao labouratory.de verantwortet, und ich dann die landing page bei labouratory.de/q.

Wenn möglich scheint es mir auch besser, wenn die landing page in Contao lebt, vor allem wegen einheitlichem Design und einfacherer Verwaltung durch Sabine.

Außerdem sieht’s natürlich professioneller aus via Contao; ich bin ja kein Webdesign-profi.
Also: gern qwrks.github.io killen, war für mich trotzdem ein guter technischer Test für unser Toolchain.
Vielleicht kann Gerald ja aus den Inhalten etwas verwenden.

Webspace

Für die statischen HTML-Ergebnisse (nach 1. wie oben) brauchen wir simplen Webspace, auf den wir die Ergebnisse hochladen können.
Idealerweise vielleicht in einen Ordner, aus dem dann das statische HTML direkt als subdirectory zu erreichen ist (qwrks.labouratory.de/projekt1 für kram der in ../projekt1/ abgelegt wird.

Bisher sind die Projektergebnisse alle auf github.com gehostet, das ist auch sehr praktisch, aber alle anderen Webspace-Lösungen (via FTP o.ä.) gehen sicher auch.

Hosting

Für die shiny-Apps brauchen wir einen (Linux-)Server, am besten als elastische virtuelle Maschine.
@maxheld83 kann die RStudio software darauf verwalten, aber nicht einen Linux-Server sicher administrieren.
Vorerst setzen wir daher auf shinyapps.rstudio.com, einem gehosteten angebot von Rstudio, aber das wird mittelfristig wegen Datenschutz etc. schwierig werden.

Ich vermute, das wir hier auf ein Angebot der Uni Hohenheim zurückgreifen wollen (also eine von deren Servern benutzen).

Fraglich ist dann aber, ob die bereit sind von externen Seiten auf diese Server zugreifen zu lassen.

ist das so ok?

• maxheld.de
• uni-hohenheim einrichtungsdate
• sabine-pfeiffer.de
• ...

https://kim.uni-hohenheim.de/95502

the idea is that this is a pretty simple landing page:

• linking to subprojects, each of which have their own site (with complete results)
• a newsletter entry form