FontAwesome 5

1st Official Post
    App
    WoltLab Suite Core

    Hallo zusammen,

    der Vorschlag wurde verständlicher Weise vor dem Release der 3.1 bereits abgelehnt, da der Aufwand zu groß für einen kurzfristigen Umbau war.

    Nun ist zum Release der neuen WoltLab Suite sicher noch einiges an Zeit für sinnvolle umbauten. Da FA5 bereits seit Monaten der neue Standard im Web ist und viele großartige Möglichkeiten bietet, schlage ich die Implementierung von Font Awesome 5 als offizielles Icon-Paket in der kommenden Suite vor.

    Ich stelle mir das so vor, dass man die Icons mit eigenen Paketen (z.B. FA5 Pro) beliebig selbst erweitern kann und die Standard-Icons so nahtlos ergänzt werden können.

    Durch die frische Optik der neuen Version und die vielfältigen Einsatzgebiete der Icon-Pakete wird außerdem ein weiterer Anreiz für das Update von 3.1 auf 3.2 gegeben.

    Viele Grüße,

    Daniel

    Folge-Thema siehe: Font Awesome 6

    Ich könnte auf die Icons verzichten wenn dadurch die Kompatibilität zum WSC 3.2 bestehen bleibt.

    Sollten die Icons kommen heißt das im Grunde, das wieder alle Plugins angepasst werden müssten.

    • Official Post

    Das aktuell größte Hindernis gegen eine Umsetzung ist die Lizenz von FA5, die es uns nicht gestattet die Pro-Schriftarten in ein Open-Source-Repository (z. B. auf GitHub) einzupflegen. Auf Grund der starken Fragmentierung von FA5 über die einzelnen Schriftarten, ist eine konsistente und ansprechende Darstellung rein auf Basis der kostenfreien Varianten nicht möglich.

    Wir wären also nach aktuellem Stand gezwungen, im Standardumfang auf ein durcheinander gewürfelte und unvollständiges Icon-Set zurückzugreifen und die "richtige" Version irgendwie mit kostenpflichtigen Paketen auszuliefern. Ach ja und es gäbe massive Kompatibilitätsprobleme bei den Templates und JavaScript-Klassen, bis hin zu abweichenden Selektoren beim individuellen CSS von Stilen.

    Pro:

    • Neue Icons, juhu!

    Contra:

    • Inkompatibel mit FontAwesome 4, die Templates und Teile des JavaScript wären nicht mehr abwärtskompatibel.
    • Unvollständiges und uneinheitliches Icon-Set im Core. Manche Icons sind in fettdruck, andere mit dünnen Linien ausgestattet und die Icons sind abwechselnd mal ausgefüllt ("solid") oder mit transparenten Hintergründen.
    • Vollständiges FontAwesome 5 Pro-Icon-Set nur durch ein kostenpflichtiges Plugin von uns.
    • FA5 Pro enthält deutlich mehr Icons als die Free-Version, Entwickler müssen entweder das kommerzielle Plugin voraussetzen oder können nur auf einen kleinen Teil von FA5 Pro zurückgreifen.

    Mirco83

    Solche Argumentation steht jedem Fortschritt im Weg. Früher oder später müssen diese Anpassungen eh durchgeführt werden, wenn die Software zukunftsfähig bleiben möchte.

    Im Gegensatz zu den Anpassungen von WCF2 auf WSC3 oder die langfristige Anpassungen zur JS-Kompatibilität, die noch kommen wird, ist das Tauschen von Icon-Bezeichnern übrigens noch die geringste Anpassung.

    Für meine 20+ Plugins schätze ich den Aufwand auf ca. 1-2 Stunden. (inkl. Testen und Aktualisieren der Store-Einträge)

    Quote from Alexander Ebert

    Auf Grund der starken Fragmentierung von FA5 über die einzelnen Schriftarten, ist eine konsistente und ansprechende Darstellung rein auf Basis der kostenfreien Varianten nicht möglich.

    Welche Icons fehlen denn in der kostenfreien Version?

    Quote from Alexander Ebert

    Pro:

    Neue Icons, juhu!

    Hast du dich wirklich bereits ausreichend mit der neuen Version auseinander gesetzt? Siehst du keinerlei Vorteile für Designer, Entwickler und Seitenbetreiber unterschiedlichster Projekte abseits der Forenwelt?

    Quote from Alexander Ebert

    Inkompatibel mit FontAwesome 4, die Templates und Teile des JavaScript wären nicht mehr abwärtskompatibel.

    Das ist der einzige Punkt aus deiner Liste den ich aktuell unterschreiben würde. Eine Anpassung aller Plugins auf das neue API-Level wäre also zwingend notwendig - so wie es in der Vergangenheit bei neuen Core-Releases ebenfalls bei vielen Plugins der Fall war. Und wie oben beschrieben ist die Anpassung der Icons dagegen ein Witz - aus Sicht der Plugin-Entwickler.

    Quote from Alexander Ebert

    Unvollständiges und uneinheitliches Icon-Set im Core. Manche Icons sind in fettdruck, andere mit dünnen Linien ausgestattet und die Icons sind abwechselnd mal ausgefüllt ("solid") oder mit transparenten Hintergründen.

    Warum sich dann nicht einheitlich an einen Stil halten? In meinen Projekten abseits des WSC nutze ich konsistent entweder die Light, Regular oder Bold, je nach Stil. Das macht sich mit FA5 sehr gut. Da ist nichts unvollständig und auch nichts uneinheitlich - im Gegenteil.

    Übrigens lassen sich die Stile untereinander auch wunderbar kombinieren. Beispielsweise die Glocke bei unseren Benachrichtigungen wäre aktiv fas fa-bell und inaktiv far fa-bell. Super-einfach und konsistent.

    Quote from Alexander Ebert

    Vollständiges FontAwesome 5 Pro-Icon-Set nur durch ein kostenpflichtiges Plugin von uns.

    Quote from Alexander Ebert

    FA5 Pro enthält deutlich mehr Icons als die Free-Version, Entwickler müssen entweder das kommerzielle Plugin voraussetzen oder können nur auf einen kleinen Teil von FA5 Pro zurückgreifen.

    Hier stellt sich mir erneut die Frage, was du mit den Pro-Icons vor hast. Klar da sind ein paar interessante Icons dabei, weswegen ich mir unbedingt eine optionale Integration wünsche. Aber für Suite + Forum fällt mir grad kein Icon ein, welches ich in der Free nicht finden würde. Immerhin umfasst die kostenlose Version bereits über 1.100 Icons, was fast doppelt so viel ist wie in FA4!

    • Official Post
    Quote from Darkwood-Studios

    Eine Anpassung aller Plugins auf das neue API-Level wäre also zwingend notwendig - so wie es in der Vergangenheit bei neuen Core-Releases ebenfalls bei vielen Plugins der Fall war.

    Und wegen exakt diesem Kritikpunkt haben wir einen verstärkten Fokus auf die Abwärtskompatibilität gelegt und extra das System der separaten API-Versionen geschaffen, um genau diesem Problem entgegen zu gehen. Du forderst uns hier indirekt auf, komplett darauf zu pfeifen und die Kompatibilität vorsätzlich vor die Wand zu fahren, einzig und alleine für ein paar hübschere Icons. Wir haben eine extrem breite Kundenbasis und wir müssen dementsprechende stets die unterschiedlichsten Anforderungen irgendwie unter einen Hut bekommen - die bestmögliche Abwärtskompatibilität ist hier eines der entscheidenden Kriterien.

    Quote from Darkwood-Studios

    Warum sich dann nicht einheitlich an einen Stil halten?

    Ich sprach ausdrücklich von FontAwesome 5 Free, bei dem man eben nicht die freie Wahl der Stile hat, sondern nehmen muss, was da ist.

    Der Core selbst steht unter einer Open-Source-Lizenz und darf daher die Pro-Version nicht enthalten, daher wäre eine Installation des Cores ohne unsere kostenpflichtigen Pakete auf die Free-Version beschränkt. Insbesondere durch die inzwischen hohe Anzahl an Apps von Drittanbietern bzw. die sinnvolle und reale Einsatzmöglichkeit des Cores ohne unsere Apps ergäbe sich ein hochgradig inkonsistentes Bild.

    Quote from Alexander Ebert

    Ich sprach ausdrücklich von FontAwesome 5 Free, bei dem man eben nicht die freie Wahl der Stile hat, sondern nehmen muss, was da ist.

    Nur um sicherzugehen, dass wir vom selben sprechen -> https://fontawesome.com/

    Ich lade mir die Free-Version runter und habe die freie Wahl der Stile. Ich würde im WSC also womöglich brands/regular/solid einbinden und je nach Bedarf nutzen. Das deckt 100% aller bisherigen FA4 Icons ab und sogar noch mehr.

    Beispielsweise die Glocke bei unseren Benachrichtigungen wäre aktiv fas fa-bell und inaktiv far fa-bell. Super-einfach und konsistent.

    Quote from Alexander Ebert

    Der Core selbst steht unter einer Open-Source-Lizenz und darf daher die Pro-Version nicht enthalten

    Das habe ich verstanden, aber nochmal: Wozu benötigt der Core die Pro?

    • Official Post

    Bitte verstehe mich an dieser Stelle nicht falsch, wir sind sehr daran interessiert, FontAwesome 5 in unserer Software einzusetzen. Wir haben das Thema intern bereits seit längerem in der Diskussion und auch eine ganze Reihe an internen Tests durchgeführt, um die Machbarkeit von verschiedenen Ansätzen ausgiebig zu testen.

    Leider sehen wir aktuell keine belastbare Möglichkeit, um FontAwesome 5 unter Beibehaltung der Abwärtskompatibilität mit WoltLab Suite 3.2 zur Verfügung zu stellen. Die Umsetzung ist von unserer Seite aus fest eingeplant und wird mit einer zukünftigen Version von uns umgesetzt werden.

    Quote from Alexander Ebert

    wir sind sehr daran interessiert, FontAwesome 5 in unserer Software einzusetzen.

    Sehr gut, das wollte ich hören. :thumbup:

    Quote from Alexander Ebert

    Leider sehen wir aktuell keine belastbare Möglichkeit, um FontAwesome 5 unter Beibehaltung der Abwärtskompatibilität mit WoltLab Suite 3.2 zur Verfügung zu stellen.

    Technisch wird es doch sicher so sein, dass die 3.2 ein neues API-Level (=2019 ?) bekommt. Aktuelle Plugins schließen standardmäßig die 3.2 sowieso aus - laufen ohne ein Update also eh erstmal nicht. Was spricht dagegen den Entwicklern eine kurze Doku mit den Änderungen der neuen API (z.B. neues Icon-Paket) zur Verfügung zu stellen, sodass die Änderung beim Pluginupdate (welches ohnehin nötig ist) durchzuführen?

    Also ich für meinen Teil nehme mir gerne die Zeit und führe diese Änderung in all meinen Plugins durch. Ob das schon in WSC3.2 passiert oder erst in 4.0 macht doch technisch gar keinen Unterschied. So oder so muss man in den sauren Apfel beißen - bekommt aber einen riesen Fortschritt bei der Entwicklung von spannenden Projekten mit der WoltLab Suite dafür.

    Quote from MysteryCode

    Falsch. Genau das ist ja der Sinn dieses neuen API-Level-Features. ;)

    Das musst du mir genauer erklären. Es ist für WoltLab ein leichtes alle Pakete ohne explizite Angabe von API-Level 2019 aus der Installation in 3.2 auszuschließen, somit müssen alle Plugins ohne Angabe zwangsläufig aktualisiert werden. Wo ist das Problem?

    Das ist durchaus korrekt. Aber der Sinn hinter dem Feature ist (theoretisch), dass man nicht explizit die nächste Version präventiv ausschließt, sondern WoltLab bei der Veröffentlichung entscheidet, ob eine Kompatibilität gewährleistet werden kann. Sprich ich könnte jetzt in der Versenkung verschwinden und WoltLab könnte dennoch in den neuen Versionen festlegen, dass meine Plugins sehr wahrscheinlich kompatibel sind und dennoch installiert werden können.

    Klar können sie so auch 2018 komplett blockieren, aber damit machen sie sich keine Freunde - vor allem nicht für eine dann inkonsistente Umsetzung eines Icon-Pakets, das erst konsistent wird, wenn man ein kostenpflichtiges Plugin erwirbt (oder es genauso bescheuert beigelegt wird wie die zwei Plugins aktuell, die man nur in Verbindung mit den Anwendungen bekommen kann). Vernünftig oder gar nicht - meiner Meinung nach.

    Quote from MysteryCode

    sondern WoltLab bei der Veröffentlichung entscheidet, ob eine Kompatibilität gewährleistet werden kann

    Korrekt. Nach der Implementierung von FA5 (was laut Alexander Ebert früher oder später passieren wird) muss WoltLab so oder so die alten APIs als inkompatibel erklären. Es ändert sich also nichts, nur der Zeitpunkt. (schon 2019 mit WSC3.2 oder 2020 mit WSC4) - das macht doch technisch keinen Unterschied.

    Quote from MysteryCode

    vor allem nicht für eine dann inkonsistente Umsetzung eines Icon-Pakets, das erst konsistent wird, wenn man ein kostenpflichtiges Plugin erwirbt

    Worauf beziehst du dich hier? Wenn die Suite 3.2 auf FA5-Free setzt (welches 100% der FA4 Icons bereits kostenlos abdeckt), und alle Plugins, durch die neue API-Kompatibilität, auf demselben Icon-Paket basieren (müssen), ist das wunderbar konsistent.

    Quote from Darkwood-Studios

    Korrekt. Nach der Implementierung von FA5 (was laut Alexander Ebert früher oder später passieren wird) muss WoltLab so oder so die alten APIs als inkompatibel erklären. Es ändert sich also nichts, nur der Zeitpunkt. (schon 2019 mit WSC3.2 oder 2020 mit WSC4) - das macht doch technisch keinen Unterschied.

    Aber für die User, denn man möchte nicht jedes Jahr wieder warten müssen bis Plugins kompatibel gemacht werden.

    Die Anpassung vom 3.0 zu 3.1 war zum Glück nicht so groß das man teilweise selbst eingreifen konnte.

    Ich nehme jetzt mal Viecode als Beispiel, hast du ein Projekt wo der Marktplatz unverzichtbar ist, muss man warten bis dieser angepasst ist.

    Da die Plugins dort sehr umfänglich sind, dürfte eine Anpassung des Marktplatz beispielsweise Monate dauern, da die Priorität der Shop ist.

    Als User möchte man gerne auch einfach mal weiter machen und das WL Update durchführen ohne warten zu müssen oder wichtige Plugins vorübergehend deinstallieren zu müssen.

    Deswegen sind meiner Meinung nach auch immer noch so viele auf älteren Versionen oder verzichten mittlerweile komplett auf Plugins.

    Quote from Mirco83

    Aber für die User, denn man möchte nicht jedes Jahr wieder warten müssen bis Plugins kompatibel gemacht werden.

    Wer zwingt dich dazu jedes Jahr unverzüglich auf die neue Version zu migrieren?

    Quote from Mirco83

    Da die Plugins dort sehr umfänglich sind, dürfte eine Anpassung des Marktplatz beispielsweise Monate dauern

    Wie kommst du darauf, dass das Umbenennen von Icons Monate dauert? Ich bin mir sicher, dass die Jungs von VieCode sowas durchaus schneller hinbekommen. - Falls nicht, siehe den ersten Punkt.

    Unabhängig davon wirst du das angeführte Problem zu jedem Zeitpunkt haben. Ob du 2019 einige Wochen auf Plugins warten musst - oder 2020, spielt dabei keine Rolle. Egal wann es passiert, niemand zwingt dich dazu sofort umzustellen, obwohl deine Lieblingsplugins noch nicht verfügbar sind. Also sehe ich hier keinen Grund weswegen man dem Fortschritt im Weg stehen muss.

    Quote from Darkwood-Studios

    Wie kommst du darauf, dass das Umbenennen von Icons Monate dauert? Ich bin mir sicher, dass die Jungs von VieCode sowas durchaus schneller hinbekommen. - Falls nicht, siehe den ersten Punkt.

    So sehr ich den Fortschritt begrüßen würde, ist die Kompatibilität ein enormes Problem für mich. Die Anpassung selbst ist kein Problem, aber die Wartung macht es aufwändig. Ich muss für meine Produkte Fehlerbehebungen mittlerweile in 3 Versionssträngen (WCF 2.1, WSC 3.0, WSC 3.1) führen. Das ist bei kleineren Plugins wahrscheinlich kein Problem, aber bei größeren Produkten unheimlich zeitaufwendig. Ich habe den dreifachen Aufwand (Implementierung, Test, Auslieferung). Jede Version, welche in mehreren WSC Versionen funktioniert, ist für mich eine enorme Erleichterung und ich kann mich der Entwicklung von neuen Funktionen widmen. Ich muss Alexander schon Recht geben, dass derzeit eine Umstellung wenig Vorteile bringt und dafür die Kompatibilität zu brechen bringt wesentlich mehr Nachteile.

    Aber irgendwann muss es einen Break geben, dass eine Abwärtskompatibilität nicht mehr möglich ist. Die Zeit bleibt nicht stehen, die Technologien und Möglichkeiten entwickeln sich weiter. Was heute noch nicht möglich ist, ist es in 5 Jahren vielleicht. Dafür sind andere Dinge veraltet und sollten in den Umfang nicht mehr genutzt werden.

    In gewisser Art und Weise muss man irgendwie mit der Zeit gehen...

    Das kann man ja auch irgendwann machen wenn ein paar Dinge zusammen kommen, aber du willst doch nicht wirklich wegen ein paar Icons, dessen Unterschiede man mit der Lupe suchen muss, die Kompatibilität kaputt machen.

    Wenn es keine Rolle spielt ob Icons angezeigt werden oder nicht, dann kann man die auch gleich weglassen und das Update auf V5 erst recht.

    Da fehlen einem manchmal echt die Worte…

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login