Stellen Sie sich vor, Sie arbeiten an einer Website, die ein Icon-System verwendet. Viele Leute, die an der Website arbeiten, interagieren mit dem Icon-System. Designer erstellen neue Icons, sie überarbeiten bestehende, sie haben Ideen, was sie mit den Icons machen wollen. Entwickler, die die Seiten der Website erstellen, nutzen das System.
Stellen Sie sich vor, Sie sind der Frontend-Entwickler. Sie implementieren dieses System. Sie sind der Mittelsmann. Sie sind der Ersteller und Verbraucher dieses Systems.
Was fragen Sie die Designer?
Option 1) „Bitte tun Sie genau diese Dinge.“
So etwas wie
Gestalten Sie Ihre Icons in reinem Schwarz auf einer 100x100 Zeichenfläche in Illustrator. Speichern Sie die Datei in diesem speziellen Ordner namens „icon-NAME.svg“ mit genau diesen Optionen. Achten Sie darauf, was immer Sie in Illustrator optimieren können, wie z. B. das Zusammenführen von Pfaden und das Reduzieren von Punkten. Wenn ein neues bereit ist, führen Sie `gulp svgstore` vom Projektstammverzeichnis aus, damit das Icon für die Produktion bereit ist. Machen Sie Commits zum Projekt, die sich auf neue Icons beziehen, getrennt von blah blah usw. Sie verstehen schon.
Option 2) „Bitte befolgen Sie diese Grundlagen.“
So etwas wie
Icons auf unserer Website sind einfarbig und quadratisch. Wir haben einen Ordner in Dropbox, in dem wir die Originale aufbewahren. Wenn Sie ein neues oder ein geändertes haben, erledigen Sie es dort und lassen Sie es mich wissen.
Option 3) „Geben Sie mir, was Sie wollen, ich kümmere mich darum.“
So etwas wie
Wenn möglich, arbeiten Sie mit Vektoren, aber ansonsten arbeiten Sie so, wie Sie es am besten können, und ich werde es für unser System passend machen.
Waren Sie schon einmal in einer solchen Situation? Wie organisieren Sie das Team?
Ich bin der einzige Icon-Designer in meinem Unternehmen. Die Leiter bitten normalerweise um Icons wie Ihre Option Nr. 3, aber wenn ich die Icons liefere, ist es meine Schuld, dass ich ihre Gedanken nicht gelesen und XYZ getan habe. Ich wurde einmal beschimpft, weil ich nicht wusste, dass eine Anwendung keine ICOs verwenden konnte und nur BMPs mit einem magentafarbenen Hintergrund für Transparenz akzeptierte, obwohl ich vorher mehrmals gefragt hatte. Ich denke, die Ursache des Problems ist, dass ich nie mit den tatsächlichen Entwicklern spreche, die die ICOs implementieren.
Für uns ist es eine Mischung aus Option 1 und 2. Wir haben eine Reihe von Regeln für Icons und den Export, aber wir verlangen von den Designern nur, dass sie sie in einen Ordner legen und uns Bescheid geben. Die weitere Optimierung und das Einspeisen in die Produktion sowie die Versionierung erfolgen durch die Frontend-Leute.
Wir verwenden gulp und ein SVG-Sprite für alle unsere Icons, daher ist es eine Art Kombination aus den oben genannten.
Beliebige Größe und Form und Farbe, die Sie wünschen/benötigen
Wenn Sie sie exportieren, befolgen Sie einige einfache Richtlinien, stellen Sie aber sicher, dass sie „icons“ genannt werden (Illustrator fügt nach dem Dateinamen den Namen Ihrer Zeichenfläche hinzu (z. B. icons_home.svg)).
Von dort aus nehme ich als FE-Entwickler diese Icons auf und lege sie in meinen Sprite-Ordner, um sie zu verwenden. Wenn sich die Icons in der Größe ändern, wird das CSS aktualisiert.
(Für alle Interessierten, wir verwenden gulp svg sprite für unsere SVG-Sprite-Kompilierung.)
Ich neige zu Option 3, weil ich das Gefühl habe, dass das der Job ist. Lassen Sie den Designer so arbeiten, wie er sich am wohlsten fühlt, in seiner Welt. Ich mache, was ich tue, in meiner Welt.
Es gibt jedoch viele Dinge, die eine Situation in die Bereiche #2 oder #1 drängen können. Zum Beispiel, wenn der Designer spezifische Richtlinien und Arbeitsabläufe wünscht. Wenn das Team groß genug ist, dass es Richtlinien benötigt, damit es nicht aus den Fugen gerät. Wenn ein Vorfall auftritt (wie Jon oben beschrieben hat), bei dem fehlgeschlagene Erwartungen Probleme verursachen.
Die Art und Weise, wie ich Icons behandle, ändert sich je nach ihrem Zweck. Normalerweise habe ich einen Satz von „Utility“-Icons: etwas wie die Icons von FontAwesome, die auf der ganzen Website für Interaktions-Icons (wie ein Hamburger-Icon für die mobile Navigation) oder für Social-Icons verwendet werden.
Für Utility-Icons verwende ich IcoMoon, um die Größen zu überprüfen und den Sprite zu generieren. (Nebenbei bemerkt, ich entferne normalerweise überschüssigen horizontalen Platz – ansonsten wird der Rand/Abstand beim horizontalen Ausrichten normalerweise durcheinander gebracht.) Mit IcoMoon ist das Finden und Hinzufügen eines neuen Icons ziemlich einfach.
Komplexe Icons behandle ich anders. Diese Icons werden für Anzeige- oder beschreibende Zwecke verwendet; Orte, an denen ein einlagiges Raketenschiff-Icon nicht ausreicht.
Ich würde diese von dem Utility-Sprite trennen, denke ich, besonders wenn komplexe Hover-/Interaktionseffekte involviert sind. Es erfordert zwar, dass ich mehr Zeit in Illustrator verbringe, aber die Komplexität der Icons macht es notwendig.
Typischerweise Option 3. Wenn sie jedoch nicht vollständig in Vektor funktionieren, versuche ich, sie daran zu erinnern, in einem höheren Auflösungsformat zu arbeiten, damit sie hochauflösende Displays berücksichtigen. Ansonsten mach was du willst.
#3 ist Chaos und ehrlich gesagt Müll. Ich weiß, das ist hart, aber die wenigen Male, in denen ich in dieser Umgebung gearbeitet habe, wurde es schnell toxisch. Jeder, der in einem Team arbeitet, sollte einige Richtlinien für die Arbeit in diesem Team haben, egal wie detailliert oder spärlich sie sind. Es mag auf sehr kleiner Basis funktionieren, aber das ist eher ein glücklicher Zufall als ein gut durchdachtes System.
Stellen Sie sich vor, ein Ingenieur kommt herein und sagt, er wolle in einer anderen Sprache codieren und diesen Code mit einem anderen Versionskontrollsystem verwalten, weil „er so am besten arbeitet und sich am wohlsten fühlt“. Nein, das ist keine Option. Es ist derselbe Grund, warum Teams Linter implementieren: Konsistenz ist oft wertvoller als die Vorteile einer einzelnen Person, die unterschiedliche Mittel einsetzt.
#1 und #2 sind beides Richtlinien, sie unterscheiden sich nur in ihrer Strenge. Diese Strenge sollte ein gegebenes Team entscheiden, aber keine Richtlinien als Team zu haben, innerhalb derer man arbeiten kann? Anarchie.
Meine nicht-wissenschaftliche, rein anekdotische Beobachtung ist, dass die meisten unserer Kunden bei Cloud Four in die Lager der Optionen 1 oder 2 fallen. Aber ich würde sagen, wir als Agentur tendieren eher zu den Optionen 2 oder 3.
Letztendlich sind die einzigen beiden Dinge, die zählen, dass das Icon gut gestaltet ist (lesbar, skalierbar, harmonisch) und dass es so implementiert ist, dass die Wiederverwendung maximiert wird und keine unnötige Dateigröße entsteht. Solange diese beiden Kriterien erfüllt sind, spielt es keine Rolle, welche Apps, Formate oder Prozesse Sie verwendet haben, um dorthin zu gelangen.
Wir halten uns an #2. #3 ist ein Durcheinander, und #1 ist ein No-Go für Designer (es ist nicht ihre Aufgabe, Build-Aufgaben auszuführen oder in ein VCS einzuchecken).
Ich liege irgendwo zwischen 1 und 2. Designer sollten ihre Assets optimieren (doppelte Punkte entfernen usw.), da dies ein Kernbestandteil ihres Werkzeugkastens ist. Andernfalls liegt es oft an den Entwicklern, die Absichten eines Designers zu interpretieren. Mein Arbeitstag besteht mehr aus Frontend-Entwicklung als aus visuellem Design, aber ich kann mit Zuversicht sagen, dass Einschränkungen bei Dingen wie Kompositionsgröße und Farbe den kreativen Prozess unterstützen.
Wir folgten Option 1 mit minimalem Aufwand seitens der Designer – im Grunde „exportieren Sie Ihr SVG mit diesen genauen Einstellungen, dieser genauen Zeichenflächengröße und übergeben Sie uns die Datei“. Ich habe den Designern gesagt, dass es sich auf lange Sicht besser auswirkt, wenn sie Pfade kombinieren, aber es nicht von ihnen verlangt. Ich habe auch verlangt, dass sie alles einfarbig verwenden, aber nicht unbedingt schwarz. Wir haben die technischen Details auf ein Minimum beschränkt.
Von dort aus habe ich den SVG-Code von Hand bereinigt – Adobe Illustrator fügt gerne eine Menge zusätzlicher Dinge hinzu. Habe sichergestellt, dass alle Farben entfernt wurden. Habe sichergestellt, dass alles in einem quadratischen Bereich war. Habe sichergestellt, dass das ID-Attribut des SVG-Tags mit dem Dateinamen übereinstimmte. Von Zeit zu Zeit habe ich Dinge entdeckt, die nicht ausgerichtet waren, also habe ich mit den Designern gesprochen und sie von Hand richtig ausgerichtet. Ich bin sicher, dass ein Großteil des Prozesses automatisiert werden könnte, aber ich hatte nicht die Zeit, den Aufwand dafür zu betreiben (Icons änderten sich selten, also war es keine so häufige Erscheinung, dass eine Automatisierung viel/irgendeine Zeit gespart hätte). Danach wurde es in die Codebasis aufgenommen, die Grunt und die svgstore-Aufgabe verwendete.
In den Fällen, in denen sie ein Icon benötigten, das mehrere Farben hatte, oder wenn es eine nicht-quadratische Form hatte; diese nannten wir dann „Symbole“ statt Icons, und sie folgten anderen Regeln. Icons konnten ihre Farben programmgesteuert auf einfache, standardmäßige Weise ändern. Icons konnten relativ einfach nebeneinander angezeigt werden, und die Skalierung funktionierte auf standardmäßige, einheitliche Weise, um unterschiedlich große Buttons zu unterstützen. Ich habe nicht viel Vorverarbeitung der SVG-Datei für ein Symbol betrieben, sondern dem SVG-Element im Grunde nur ein ID-Attribut gegeben. In den seltenen Fällen, in denen wir ein Symbol in einem Button brauchten, war es einfach genug, es als Einzelstück zu behandeln und trotzdem von den Vorteilen der Standard-Icon-Implementierung zu profitieren.
Die Bezeichnung von SVG-Bildtypen als „Icons“ gegenüber „Symbolen“ hat für uns viele Probleme gelöst.
Ich denke, SVGOMG ist das, was Sie brauchen. Vereinfacht Pfade, entfernt unnötige Dinge. Als ich es das letzte Mal benutzte, hat es 97% eines Illustrator-SVGs entfernt, ohne visuelle Unterschiede.
Im UI-Team bei WGU streben wir wirklich nach einem vollständig automatisierten Frontend-Framework, das wir in eine lebendige Style-Guide integrieren können, daher bitten wir die Designer im Wesentlichen um Option 1. Wir müssen diese Icons durch ein automatisiertes Illustrator-Skript laufen lassen, das sie in Sprites umwandelt, und dann durch einen Grunt-Prozess, der die SASS- und Base64-Strings aus diesen Sprites generiert.
Der Dateiname, die Zeichenfläche, die Struktur des SVG… all das muss stimmen, und wir haben eine deutliche Neugestaltung durchgemacht, bei der wir Dutzende von Icons haben und es werden mehr. Die Designer müssen mitmachen.
Außerdem bin ich schlecht in AI, daher ist es sowieso schneller für sie, es auf die vorlagenbasierte Weise zu tun!
Hier ist, was wir tun
Jedes Icon ist eine Zeichenfläche in einer Sketch-Datei mit Namen wie myicon-24 (24 ist die Größe).
Das ist es eigentlich.
Ein Gulp-Task
Exportiert alle Zeichenflächen als SVG
Bereinigen mit (svgo)
Es wird eine Symboldatei erstellt, wobei jedes Icon mit „-icon“ präfigiert wird
Die resultierende Symbol-SVG-Datei wird nach der Datei benannt, aus der sie erstellt wurde
Sowohl der Dateiname als auch die Datei werden nach Git gepusht
Jetzt,
Die Symboldatei wird entweder direkt in das HTML eingefügt, wenn der Browser keine externen Symbole unterstützt, oder die Symbole werden direkt referenziert, z. B. assets/icons-6373737.svg#icon-myicon-24
Der Entwickler kümmert sich nicht wirklich darum, was passiert, da eine React-Komponente oder eine Icon-PHP-Funktion sich darum kümmert.
Das mag komplex erscheinen, ist aber wirklich super einfach und sofort.
Da die Screen-Designer und wir Frontend-Entwickler zwei Teams derselben Abteilung sind, haben wir diskutiert, wie der Icon-Workflow funktionieren soll, die verschiedenen Möglichkeiten zur Einbindung von Icons in unsere Seiten in unserem Unternehmen bewertet (inline SVG für SPAs und background-image für normale Seiten) ein paar Dinge ausprobiert, einige davon verworfen und mehrere Ansätze zu etwas vereint, das für uns funktioniert. Im Grunde #1, aber nicht wir allein fordern bestimmte Formate. Automatische Konvertierung ist gefährlich, da sie die Qualität des Subpixel-Renderings leicht beeinträchtigen kann.
Ich arbeite für eine große Finanzinstitution. Es ist viel näher an #1 als an #2 oder #3. Wir haben ziemlich strenge Richtlinien und jede neu eingeführte Ikone würde wahrscheinlich eine Teamgenehmigung erfordern.
Ich würde sagen, in einer perfekten Welt weiß ein Designer genau, wie er Icons für das Web in einem korrekten Format, konsistent und für Leistung und Farbanforderungen optimiert entwerfen muss. Das Web ist auch ihr Medium, und es sollte keine separate „Welt“ geben. Die Zeiten, in denen man Statiken in Photoshop erstellt und sie über die Mauer wirft, sollten vorbei sein.
Doch ich weiß, dass das nicht der Fall ist, nicht überall. In der Praxis würde ich mich für Option 1 entscheiden, so spezifisch wie möglich, im Voraus. Was auch helfen könnte, ist eine öffentliche Icon-Demo-Seite, auf der sie in einem Raster angezeigt werden. Wenn etwas nicht stimmt, sollten Sie es schnell sehen können. Eines der häufigsten Probleme ist, dass Icons nicht richtig ausgerichtet sind.
Ich arbeite als Designer und Frontend-Entwickler, daher sehe ich (und habe erfahren) Probleme auf beiden Seiten des Zauns. Dennoch halte ich es für entscheidend zu verstehen, dass es hier zwei sehr unterschiedliche Seiten der Argumentation gibt. Aus Design-Sicht sollten die Icons konsistent sein (Farbschemata, Strichstärke, Größe, Stil usw.), aber diese Einschränkungen haben nichts mit Entwicklungsbeschränkungen zu tun. Ich kann kaum ein Argument aus Entwicklungssicht finden, denn mit SVG und Build-Tools wie Gulp sollte es einfach sein, mit einer Vielzahl von Formen und Größen umzugehen (was im Grunde alles ist, worüber man sich Sorgen machen muss).
Anständige Icons zu entwerfen ist mühsam, sie dauern länger als erwartet, und dann muss man noch Zeit damit verbringen, Pfade manuell zu hinterlegen, damit Punkte auf exakte Pixel fallen – es gibt nichts Enttäuschenderes, als all diese Zeit und Mühe in Kauf zu nehmen, nur damit ein Frontend-Entwickler stattdessen Font-Awesome verwendet!
Option #1 hier.
(Team hat 3 Designer, 3 Frontend-Entwickler, 4 Backend-Entwickler)
Nicht nur das, unser Designer committet das Icon bereits im richtigen Ordner auf Github (mit dem neuen Drag-and-Drop-Uploader).
Irgendwann geht etwas schief. Eine falsch benannte Datei oder ein nicht optimiertes Icon wird committet. Aber wir ziehen es vor, sporadische Probleme zu beheben, als die Arbeit aller zu blockieren.
Einige Grundlagen, die Designer befolgen sollen, dann eine robuste Automatisierung für alles, was ich kann :-)
Versuchen Sie Option 1. Versuchen Sie Option 1. Versuchen Sie Option 1. Versuchen Sie Option 1. Versuchen Sie Option 2. OK… Option 3 ist es dann.
Ich und mein Team verwenden Sprite CSS Generator und Adobe Illustrator. Es ist ein nettes kleines Werkzeug und wir können unsere Sprites als Illustrator-Datei speichern, und keine Information geht verloren. Wir können auch die Icons neu anordnen und der Code aktualisiert die richtigen Positionen. Es ist nett und kostenlos: http://spritecssgenerator.formfcw.com
Unser Designer hört nie auf das, was wir ihm sagen! Er macht, was er will!!! Icons haben unterschiedliche Farben, Größen, und natürlich kann man nie von ihm erwarten, dass er uns einen Bild-Sprite liefert: „Dafür ist er zu beschäftigt!!!“