search

FriendsOfREDAXO / tricks

Tipps und Tricks rund um REDAXO 5
https://friendsofredaxo.github.io/tricks/
MIT License
105 stars 33 forks source link

Die Tricks werden langsam unübersichtlich / Website anpassen #58

Closed skerbis closed 6 years ago

skerbis commented 6 years ago

Alternativen? Vorschläge zum Aufbau?

alxndr-w commented 6 years ago

Noch geht's, wenn man sich https://friendsofredaxo.github.io/tricks/ anschaut.

Zwei Ideen:

IngoWinter commented 6 years ago

den link von @alexplusde kannte ich noch gar nicht. welche möglichkeiten hat man denn da, per css und javascript zu arbeiten?

skerbis commented 6 years ago

Ist nur eine von Github generierte Seite. Nicht veränderbar

IngoWinter commented 6 years ago

da ist doch ein theme installiert. und über ein theme müsste man doch css und javascript laden können...

alxndr-w commented 6 years ago

https://help.github.com/articles/customizing-css-and-html-in-your-jekyll-theme/

schuer commented 6 years ago

Die GitHub Pages sind sehr flexibel. Im Frontend (HTML, CSS, JS) sowieso, aber auch im Umgang mit den Repo-Daten geht einiges — wenn auch nicht so viel wie etwa in einer PHP-Umgebung. Am Ende bleibt es eine statische Seite. Die gleiche Technik nutzt übrigens auch unsere Community-Map und die FOR-Website.

Weitere Vorschläge, um die Tricks übersichtlicher und zugänglicher zu gestalten:

skerbis commented 6 years ago

Darf gerne jemand übernehmen.

schuer commented 6 years ago

Ich setze gerne mal die Tricks-Website auf, allerdings ist zu bedenken, dass dafür das Repo etwas umgebaut werden muss, so dass es danach nicht mehr ganz so gut über die GitHub-Weboberfläche zugänglich ist:

Die Tricks werden auf der GitHub-Weboberfläche also an Übersichtlichkeit verlieren, dafür wird die neue Website sehr schnieke und aufgeräumt:

Fragen in die Runde also: Ist das in eurem Sinne, dass wir die Ansicht der Tricks von der GitHub-Oberfläche hinüber zur Website verlagern?

IngoWinter commented 6 years ago

+1 für schnieke Tricks Website

dergel commented 6 years ago

und in die redaxo.org integrieren ? oder ist das zu umständlich ? Wir hatten ja mal die Idee Codeschnipsel/Tricks als Suche innerhalb von redaxo.org einzubauen. Eventuell kann man auch eine externe Seite machen und nur die Suche mit auf redaxo.org aufnehmen.

dtpop commented 6 years ago

Es gab immer wieder mal die Idee die Tricks in die Doku zu integrieren. Ich halte sie allerdings unverzichtbar separat zu halten, da einiges Core- und AddOn-übergreifend ist und so den unbedarften Benutzer animiert auch mal ein unbekanntes AddOn in seine Architektur aufzunehmen. Durchsuchbar aus redaxo.org wäre fast so etwas wie must have. Gerade die nicht-Experten tun sich schwer mehrere verschiedene Quellen abzusuchen. Und ... genau ... Danke für die Initiative!!!

alxndr-w commented 6 years ago

+1 für die Integration in die Hauptwebsite und eine Suchfunktion für Doku und Tricks.

schuer commented 6 years ago

Integration in redaxo.org und Implementierung einer Suche müsste dann jemand übernehmen. Ich würde nur die GH-Pages-Lösung umsetzen, falls diese gewollt wird.

staabm commented 6 years ago

integration in redaxo.org würde ich nicht machen, da wir viel zu wenig leute haben die zeit haben dort was einzubauen und zu pflegen.

wenn es standalone auf github bleibt ist der user-kreis der daran arbeiten kann viel größer (sind im prinzip die gleichen argumente wie für die community map)

skerbis commented 6 years ago

Das haben wir schon oft diskutiert. Die besagte Snippet-Sammlung wäre mir lieber auf REDAXO.org. Dann werden auch die Tricks schlanker. Die Tricks sollten auch eher Anwendungsfälle lösen. Die banalen Snippets könnten hier raus.

dergel commented 6 years ago

lasst uns das weiterüberlegen.. Die Argumente gegen die Webseite sind ja eher wegen Aufwand und nicht, weil es nicht dort bessser aufgehoben wäre. Was bräuchten wir für Felder und welche Art von Suche.

Titel, Beschreibung, Code, Kategorie/Bereich ? Nur Volltextsuche mit Highlighting ?

alxndr-w commented 6 years ago

Vielleicht hat @tyrant88 ja eine zweckdienliche Idee zur Umsetzung, schließlich führt er das Repo zu search_it.

tyrant88 commented 6 years ago

Search it nutzt zwar Sockets zum Indexieren, aber eine "Spider" ist es noch nicht. Also bei externen Inhalten hilft es nicht.

alxndr-w commented 6 years ago

Die Diskussion, wie Inhalte von hier auf redaxo.org kommen können, hatten wir eigentlich schon mal ergebnislos geführt: https://github.com/FriendsOfREDAXO/friendsofredaxo.github.io/issues/2

schuer commented 6 years ago

@alexplusde In der verlinkten Diskussion ging es vor allem darum, wie wir mit FOR unsere AddOns veröffentlichen können, ohne dass es ein manueller Prozess ist und alle Beteiligten die Zugangsdaten benötigen. Und ergebnislos war die Diskussion gar nicht mal, sondern der Plan war am Ende, dass irgendwann eine automatische Veröffentlichung aus GitHub heraus implementiert werden soll. Allerdings ist das bisher noch nicht geschehen, und wir veröffentlichen weiterhin manuell mittels Zugangsdaten.

skerbis commented 6 years ago

Insgesamt bin ich mit der Auffindbarkeit der Informationen in den Tricks (aber auch der Doku) sehr unzufrieden. Die Mehrheit der Tricks sind Snippets und kleine Manuals. Diese brauchen eine Struktur (Kategorisierung) und ggf. Tagging. Ich weiß nicht ob sich dies in GitHub wirklich lösen lässt. Ggf. eine REDAXO Website, die sich die Daten wie bei den Dokus auf REDAXO.org zieht. Eigentlich ist es ein wenig peinlich, dass wir in REDAXO auf sowas wie GitHub-Pages zurückgreifen.

staabm commented 6 years ago

Eigentlich ist es ein wenig peinlich, dass wir in REDAXO auf sowas wie GitHub-Pages zurückgreifen.

die ganz großen wie symfony etc. machen das auch so. github hat den ultimativen vorteil dass eben jeder daran pflegen kann und man keinen speziellen account dafür brauch.

skerbis commented 6 years ago

Hier meinte ich eher die Ausgabe der Seiten @staabm

schuer commented 6 years ago

Für GitHub Pages kann man auch eigene Subdomains verwenden, z. B. docs.redaxo.org oder tricks.redaxo.org.

alxndr-w commented 6 years ago

Dann könnte man bspw. snippets.redaxo.org nehmen und tricks.redaxo.org - womit das ursprüngliche Thema angegangen würde - die Tricks übersichtlicher machen und so gliedern.

schuer commented 6 years ago

Was sind denn diese Snippets eigentlich und warum sind sie nicht Teil der Tricks? Und warum soll das alles so verteilt auf viele Instanzen sein — Doku, Tricks, Snippets —, statt gemeinsam unter einem Dach? Die Kritik von Nutzern ist ja oftmals, dass REDAXO-Hilfe zu breit verteilt ist und dadurch schlecht gefunden wird. Sollten wir hier nicht lieber entgegenwirken, indem wir versuchen, mehr zu bündeln?

skerbis commented 6 years ago

Die Doku bezieht sich auf den Auslieferungszustand. Die Tricks sollten Lösungen oder Problemlösungen auch "AddOn"-übergreifend darstellen. Aber es finden sich aktuell hier auch Basics (z.B. Minibeispiele) die eher in einer Snippet/Template/Modul-Datenbank gesammelt werden sollten, finde ich. Die es nun ja ebend nicht (mehr) gibt

schuer commented 6 years ago

Okay, dann können wir nach der ganzen Diskussion schonmal festhalten, dass die Doku besser auf redaxo.org bleiben sollte und langfristig aber unbedingt mal eine Suche erhalten sollte, richtig?

Dann bleiben noch Tricks und Snippets, danke für die Info @skerbis! Ich persönlich sehe die Tricks eher als GitHub Pages — erreichbar unter der von GitHub angebotenen Domain https://friendsofredaxo.github.io/tricks/ oder über eine REDAXO-Subdomain wie z. B. https://tricks.redaxo.org —, und ich würde Tricks und Snippets unbedingt gemeinsam anbieten, nicht zwei Projekte draus machen. Die Tricks wären damit eine Anlaufstelle für alles, was nicht in die Doku passt, also AddOn-bezogene Tutorials, Codebeispiele oder sonstige Hilfen.

Ich würde die Tricks nicht in redaxo.org integrieren, weil die Integration und Pflege sonst von den Core-Leuten übernommen werden muss, während wir an GitHub Pages alle gemeinsam arbeiten könnten. Zudem ist das Hosting bei GitHub robuster, schneller und weniger aufwendig. Es läuft einfach, niemand muss sich drum kümmern.

Bezüglich Suche und Tagging: GitHub Pages sind vollständig statisch, werden also aus den Repo-Daten heraus einmalig generiert und haben keine Möglichkeit von serverseitiger Datenverarbeitung, wie man sie etwa bei einer Suche bräuchte. Dennoch ist eine Suche mit GH Pages möglich, und sogar sehr komfortabel: Die Indizierung übernimmt ein externer Service (algolia.com, dauerhaft kostenlos für OSS-Projekte), und die Integration auf der Seite ist dann mittels JS und API. Bei Jekyll oder symfony seht ihr, wie das funktioniert: Einfach irgendwas ins Suchfeld tippen, dann kommt ein Flyout mit Vorschlägen. Und auch Tagging ist möglich, indem man einfach eine Tag-Übersichtsseite generiert, die auf die einzelnen Artikel verlinkt. Beispielhaft hier zu sehen: http://codinfox.github.io/blog/tags/

schuer commented 6 years ago

Kleines Update: Die Suche für GH Pages steht längst zur Verfügung. Ich dachte, wir müssten aufs nächste Release warten, aber das war Bullshit. Die Suche, weil extern, kann schon jetzt eingesetzt werden. ✅

alxndr-w commented 6 years ago

Wer kann sich um die Integration kümmern?

IngoWinter commented 6 years ago

@schuer hat schon vor 5 tagen angeboten, sich drum zu kümmern...

schuer commented 6 years ago

@schuer hat schon vor 5 tagen angeboten, sich drum zu kümmern...

(Aber nur GH Pages. Falls Integration in redaxo.org gewünscht wird, also auf PHP-Basis, müsste das jemand anderes machen.)

IngoWinter commented 6 years ago

ach, wenn das unbedingt auf redaxo.org soll (wobei mir der nicht klar ist, welchen vorteil das bringen soll), kann @gharlan ja einfach nen iframe reinnageln und gut ist.

skerbis commented 6 years ago

Hauptsache es wird schnieke. @schuer lass rocken! Suche, Tagging - cool. Dann wird das was.

dergel commented 6 years ago

gerne extern - weil es realistischerweise zeitlich auf redaxo.org nicht klappen wird und veränderungen erst recht dauern. Ich würde dennoch die Tricks auffällig auf der r.org seite verlinken... Wenn die Seite so cool wird wie die community seite - top !!

schuer commented 6 years ago

GitHub hat inzwischen Jekyll 3.7 am Start (siehe https://pages.github.com/versions/), und ich hatte irgendwie gedacht, dass sie in dem Zusammenhang auch jekyll-algolia als Plugin hinzufügen, was es einfacher machen würde, die Inhalte der Seite bei Änderungen an die Algolia-Docsearch zu übergeben, so dass der Index dort immer schnell auf dem aktuellen Stand ist. Aber nein, das Plugin haben sie nicht hinzugefügt.

Macht aber nichts, denn man kann zum Push der Inhalte Travis CI verwenden, so wie hier beschrieben: https://community.algolia.com/jekyll-algolia/github-pages.html

Und auch ohne Travis könnte Agolia problemlos angebunden werden, verfügt es doch über einen Crawler. Der ist naturgemäß langsamer bei Änderungen, als ein Push es wäre, aber sollte in unserem Fall auch gut funktionieren.

schuer commented 6 years ago

Suche muss noch integriert werden (#81), aber ansonsten können wir jetzt sicherlich schließen.