Das Interface von GoogleAnalytics erhielt kürzlich ein kleines Update. Insbesondere eines der Icons, die nunmehr dort zur Anwendung kommen, weckte aufgrund seiner ziemlich ungewöhnlichen Darstellung mein Interesse. Icons from hell.
Ein nach unten gerichteter Pfeil, soviel haben wir über die Jahre im Umgang mit digitalen Medien gelernt, beschreibt im User Interface eine dem Anwender zugewandte Aktion, etwa ein Download eines Fotos oder das Sichern einer Datei auf den eigenen Computer. Im Gegensatz dazu assoziieren wir eine nach oben gerichtete Pfeildarstellung mit einer vom User abgewandten Aktion, beispielsweise ein Upload einer Datei in die Cloud oder das Senden einer E-Mail.
Dieses Darstellungprinzip manifestiert sich in allen prägenden UI-Designsprachen – in den Human Interface Guidelines von Apple ebenso wie im Modern UI von Microsoft und auch im Material Design von Google. Ebenso ist im CSS-Framework Bootstrap, quasi Industriestandard in Sachen Webentwicklung, das Icon für Export mit einem nach oben gerichteten Pfeil ausgestattet.
Man kann also sagen, dass in das Interface von GoogleAnalytics ein ziemlicher Exot von einem Icon Einzug gehalten hat. Die Icon-Leiste samt aufgeklapptem Menüpunkt „EXPORT“ schaut wie folgt aus:
Das ungewöhnliche Export-Icon, das entgegen geltenden Webkonventionen einen nach unten gerichteten Pfeil beinhaltet, bedeutet im Ergebnis: die Aussage von Icon und Menü-Bezeichnung widersprechen sich. Darüber hinaus widerspricht das ominöse Export-Icon Googles eigenen Designprinzipien, die für Upload und Download die folgenden Zeichen vorsehen:
So bleibt festzuhalten: Im Bereich User Interface hat sich seit geraumer Zeit folgendes Prinzip durchgesetzt:
Pfeil nach oben = Upload / Exportieren / User sendet (aktiv) / weg vom eigenen Endgerät
Pfeil nach unten = Download / Importieren / User empfängt (passiv) / auf das eigene Endgerät
Dass das hier vorgestellte Export-Icon im Widerspruch zu dem steht, was Google sonst so in Sachen Interface-Design produziert, zeigt beispielsweise der Blick hinüber zu Google Docs, wo ähnliche Funktionen ganz anders anlegt sind (siehe Abb. unten). Ein nach unten gerichteter Pfeil in Verbindung mit der Bezeichnung Export findet sich weder in Google Docs, noch in anderen mir bekannten Anwendungen, Web, iOS, MacOS, Android und Windows eingeschlossen.
Um abschließend einen Lösungsansatz für den durch das Export-Icon verursachten UI-Konflikt aufzuzeigen:
- Alle in der Icon-Leiste enthaltenen Auswahlmöglichkeiten semantisch und in Bezug auf die Gleichheit von Funktionen ordnen
- Aussehen der Icons sowie Funktionsbezeichnungen harmonisieren (ausgehend von der Google-Designsprache)
- Als Vorlage für die Harmonisierung könnte beispielsweise Google Docs unter Android dienen (siehe Abb. unten). Hier werden unterschiedliche Funktionen unter der sinnvollen Menüpunkt-Bezeichnung „Freigeben und exportieren“ gebündelt und die subsumierten Begriffe durch aussagekräftige Icons ergänzt.
Die oben gezeigte Lösung funktioniert zudem deshalb so gut, da in der Übersicht auf den Einsatz zusätzlicher Icons gänzlich verzichtet wird. Denn: Icons sind erklärungsbedürftiger als reine Textaussagen! „Sprache“ ist eindeutiger als , „Code“ ist verständlicher als  und „Publish“ ist präziser als . Insbesondere dann, wenn sich die Aussagen von Icon und Text widersprechen, wie in dem hier vorliegenden Fall, schaden Icons mehr als dass sie von Nutzen sind. Icons sind bei UI-Designern und -Konzeptern aufgrund der geringen Größe und der damit verbundenen Gestaltungsfreiheit äußerst beliebt, für Anwender stellen Icons allzuoft ein ärgerliches Hinderniss dar.
Was hier nicht stimmt, ist Fokus (erzählerisch) oder Scope (programmiererisch). Der Entwickler nimmt irrtümlich an, ich befände mich als Nutzer wie er im Serverdatenbankmodus. Tatsächlich bin ich aber Nutzer und habe den Wunsch, abzuspeichern, was ich im Browser vor mir habe. SAVE AS lautet die aus meiner Warte gewünschte Funktion und nicht Exportieren. Das Icon dafür ist die Diskette mit Bleistift. Oder eben der Down-Pfeil, weil ich aus meiner Warte etwas zu mir hole.
Das ist nicht ganz korrekt. “Save as” ist eine kontexterhaltende Speicherart, während Export eine reduzierende ist. Gerade Formate wie CSV reduzierenden die mehrdimensionale Datenbasis auf eine zweidimensionale Ansicht.
Zur Sache: Download oder nicht ist abhängig davon, wo man Browser/App und Speichermedien verortet. Es ist durchaus auch legitim, einen Clouddienst als virtuellen, lokalen Speicher anzusehen – jedenfalls wird die nahtlose Integration in die OS-UI + Synchronisation ja seit Jahren vorangetrieben. So betrachtet ist dann jede der Export-Funktionen ein Download. Mehr als der Pfeil nach unten stört mich eigentlich die Schale, in die das Datengut aufgenommen wird.
PS: Dass bspw. Excel auch Tabellen per “save as” in CSV speichert, ändert nichts an meiner Ansicht :)
Ich finde die gewählte Lösung clever und ganz und gar nicht unpassend.
1. Beschriftung:
Export ist die treffende Beschriftung, wie andere Kommentatoren bereits festgestellt haben, weil eben nicht die Analyse-Daten vollständig abgespeichert werden, sondern ein Formatwechsel stattfindet, bei dem Informationen verloren gehen. Daher ist es auch kein klassischer Download oder Speichern.
2. Icon
Das Icon dient als Indikator dafür, dass der Export als Download erfolgen wird. Quasi als Zusammenfassung der Download-Optionen, die sich hinter dem Dropdown-Menü befinden.
Mir zumindest ist anhand des Buttons sofort klar, was passiert: Ich bekomme diesen Teil der Auswertung als Datei zum Herunterladen, mit einem Klick darauf erfahre ich, dann dass ich auch das Format wählen kann.
Seit wann hat Export denn was mit Datenverlust zu tun? Ich kann auch ein JPG öffnen und als PNG exportieren. Oder Pfade aus PS nach Illustrator exportieren.
Bei vielen Programmen ists ja sogar so, dass man das Speichern in anderen Formaten in “speichern als” und “exportieren” unterteilt, obwohl das irgendwie keinen wirklichen Sinn macht und scheinbar macht bei der Einteilung auch jeder was er will.
Ich kann in Pages ne .txt öffnen und als .txt “exportieren” aber nicht “speichern”. Und in Textwrangler kann ich ne .txt öffnen und als .txt “speichern”, aber nicht “exportieren”.
Exportiere eine EPS in JPG und schwupps sind alle Vektor-Informationen hinfort …
Der Vorgang ist kein Export, sondern eine Konvertierung.
Mag sein, nur wird das Wort “Konvertierung” in den wenigsten UI verwandt. Hier hat sich nun mal das Wort “Export” etabliert und jeder weiß was gemeint ist – wahrscheinlich weil die Programmentwickler diese Funktion aus der Warte des Programms und nicht aus der Warte des Datenformates sehen (wollten).
Wenn in den meisten Programmen das Wort „Exportieren“ zur Anwendung kommt, liegt das daran, dass dort in der Regel explizit auch ein Export gemeint ist und eben keine Konvertierung. Zugegebenermaßen kommt es hierbei zu sprachlichen Vereinfachungen, auch um das UI nicht zu überfrachten. So „exportieren“ wir aus Photoshop heraus Bilder als GIF, obwohl „Sichern als“ die bessere Bezeichnung wäre. Bezeichnenderweise gibt es in Photoshop drei Auswahlmöglichkeiten, um ein JPEG zu speichern.
1. Exportieren > Exportieren als
2. Exportieren > Für Web speichern
3. Speichern als
In Affinity gibt es übrigens nur zwei Auswahlmöglichkeiten („Speichern unter“ und „Exportieren“).
@Achim, seh ich ein wenig anders, zumindest ist es in meinem Beispiel in Illustrator eben nicht so wie von dir beschrieben.
Um aus *.ai eine *.eps (also eine andere Vektordatei ohne Informationsverlust) zu speichern gehe ich auf “Speichern unter”. Um eine *.jpg (o.ä. Pixelgrafik mit Informationsverlust) zu speichern geh ich auf “Exportieren”. Hier und in vielen anderen Programmen hat sich also diese Bezeichnung durchgesetzt, weil man die Funktionalität eben – so vermute ich – aus Anwendersicht bzw. Programmebene heraus bezeichnet hat.
Eine Konvertierung findet nüchtern betrachtet nur zwischen den Dateien bzw. von der einen zur andern statt.
So wie es in vielen Belangen Konvertierungstools gibt (da ist der Syntax auch korrekt), die einen Dateityp in einen anderen umwandeln ohne dabei das “Verfasserprogramm” zu benötigen.
Langer Rede kurzer Sinn: In der gängigen Praxis ist Exportieren verlustbehaftet!
Das stimmt einfach nicht. Der Austausch/Export/Import von Datensätzen etwa via MySQL erfolgt verlustfrei. Anderfalls würden große Teile des Webs, eben Datenbank basierte Websites, nicht funktionieren, da bei jedem Export/Import, mit jedem Eintrag in eine Tabellenzelle Daten verloren gingen.
Dass beim sogenannten „Exportieren“ via Photoshop, Illustrator, Affinity, Sketch, etc. in das Datenformat GIF oder JPEG Daten verloren gehen, liegt daran, dass in diesem Fall auch eine Datenkompression erfolgt. Das sind zwei Vorgänge, die innerhalb des UI zugegegbenermaße als ein Vorgang ausgegeben werden. Ich kann beispielsweise aber auch aus Affinity heraus ein EPS „exportieren“, ohne dass damit ein Datenverlust einherginge.
OK, hätte vlt. schreiben sollen “In der gängigen Praxis kann Exportieren auch verlustbehaftet sein!”
Bei dem Importieren/Exportieren von SQL o.ä. findet ja auch garkeine Konvertierung statt, es sind alles Text- bzw. XML-Dateien.
Ich befürchte wir reden immer ein wenig aneinander vorbei. Es geht doch nicht um die technische Verarbeitung oder Algorithmus dahinter. Sondern es ging mir (wie ja das eigentliche Thema auch) um die Nomenklatur der UI und darum, dass man unter “Exportieren” eben die technische Einrichtung der Konvertierung findet (ohne das sie so benannt ist). Und im Umkehrschluss findet dann logischerweise auch MANCHMAL ein Informationsverlust statt, wenn man z.Bsp eine Illustrator-Datei in eine Bild-Datei “exportiert” hat.
Bei EPS bleiben zwar Vektordaten erhalten, aber nicht alle Bearbeitungsfunktionen (Programmeigene Effekte, Metadaten, etc.).
Bei MySQL werden nur nur Teile der vorhandenen Daten und Struktur der Tabellen exportiert, die Datenbank selbst hat aber weitaus mehr Informationen, die nicht zwingend bei einem Export mitgegeben werden (Autoincrement, Index, Informationen zu Relationen).
Hier sind doch Leute aus der Praxis anwesend. Da muss man doch erkennen, dass “speichern unter“ und “export“ sich genau da unterscheiden.
Auch das Verhalten der Anwendung unterschiedet sich oftmals. Beispiel csv: speichere(!) ich in Excel die Datei als csv, arbeite ich mit eben dieser csv-Datei weiter (sieht man in der Fensterleiste am Dateinamen). Beim Export verlasse ich meine aktuelle Datei nicht, es wird eine möglicherweise verlustbehaftete, konvertierte Datei an einem externen Ort abgelegt.
Ich schließe mich Axelplus an. Ich wäre nie auf die Idee gekommen, dass hier ein Design-Fehler vorliegt. Ich möchte ja die Daten auf meinen PC herunterladen, also Pfeil nach unten. Weiß nicht, was diese Diskussion hier soll.
Export an dieser Stelle bedeutet, ich möchte mir die Daten auf mein Endgerät laden. Also nach der Logik des Verfassers dieser Kritik würde das Icon dann doch passen. Zitat: “Pfeil nach unten = Download / … / auf das eigene Endgerät”.
Ein Export aus bspw. einer externen Webanwendung kann ein “Download” “auf das eigene Endgerät” sein und ein Export aus einer Anwendung auf dem eigenen System kann ein Handlung
“weg vom eigenen Endgerät” sein.
So klar wie die Abgrenzung der Icon-Darstellungen und semantischer Bezug hier dargestellt wird, ist sie nicht.
Das geht nur, wenn man den Prozess aus der Warte der Daten beschreibt. Ich bin aber keine Daten, sondern der User.
Hi,
“uminös” wird mit “o” statt “u” geschrieben. ;-) Und den Satz :”Icons sind erklärungsbedürftiger als reine Textaussagen! „Sprache“ ist eindeutiger als , „Code“ ist verständlicher als  und „Publish“ ist präziser als . ” sollte man sich mal auf der Zunge zergehen lassen! Wer so etwas schreibt hat den Sinn von Icons als Grafiker schlechtweg nicht verstanden. “Text” ist “Nationalsprachen-gebunden” Icons sind “Nationalsprachenungebunden” Dafür stehen sie und bedürfen bei internationaler Verwendung natürlich bei Unklarheiten der sprachlichen Erläuterung in der jeweiligen Sprache. Aber so einen Sprach/Bild Kauderwelsch wie im genannten Beispiel sollte man als Autor eines Fachbeitrags besser nicht verfassen.
Schön, dass Sie einen Tippfehler gefunden haben. Er wurde soeben korrigiert.
Bin kein Grafiker. Bin Designer. Nur mal so.
Das zeigt ja sehr schön das Dilemma. Wohl ohne es zu wollen bekräftigen Sie mit Ihrem Kommentar die im Artikel von mir getroffenen Aussage: Icons sind allzu oft ungenau und erfordern eine textsprachliche Erläuterung. Nun, dann kann man halt auch ganz auf ein Icon verzichten.
Tatsächlich finde ich als User das neue Icon viel eindeutiger. Denn tatsächlich möchte ich gar nichts “exportieren”, sondern die vorliegenden Daten in einem Format meiner Wahl speichern. Das eingängige Icon zeigt jetzt Usern, die in der Anwedung derartiger Programme weniger firm sind, visuell eindeutig, was sie zu tun haben. Als Ausbilder merkt man nämlich schnell, dass Leute ohne entsprechenden Background dämlich suchen, wenn sie nach einer Speichermöglichkeit suchen, diese jedoch per Icon mit einem wegführenden Pfeil dargestellt wird. “Export” heißt für einen Programmierer eben ewas anderes als für den Durchschnittsuser. Das neue Icon hebt dies ein Stück weit auf.
Ok. Soweit teilen wir die gleiche Auffassung. Nur warum steht neben dem Icon dann „Export“? Wenn ich – als User – die Daten sichern will?
Das ist offensichtlich so. Wenn der Programmierer in die Rolle der Daten schlüpft, verliert er dabei den Fokus aus User-Sicht aus den Augen, und es entsteht ein UI-Konflikt wie dieser.
Icons wie auch die dazugehörigen Bezeichnungen sollten für Programmierer nicht etwas anderes bedeuten als für Nicht-Programmierer. Findest Du nicht auch?
Da schließe ich mich der Frage von violator natürlich an: Seit wann hat Export denn was mit Datenverlust zu tun? Mir scheint hier verwechseln einige Kommentierer Export mit Konvertierung oder Komprimierung/Kompression.
Export: Übertragung von Daten zwischen zwei Programmen; diese ist, sonfern die Übertragung vollständig ist, immer verlustfrei. Wenn Daten exportiert werden, erfolgt eine Übernahme von Daten aus einem Anwendungsprogramm bzw. einem Datenbankverwaltungssystem in ein anders, und zwar eins zu eins, nur eben auf eine Weise, bei der das aufnehmende Programm die Daten verarbeiten kann.
Konvertierung: Umwandlung einer Datei von einem Dateiformat in ein anderes mit Hilfe eines Dateikonverters; diese kann sowohl verlustfrei, verlustbehaftet oder sinnhaft sein.
Komprimierung/Kompression: Techniken zur Codierung von Daten durch Eliminierung von Redundanzen. Bei diesem Vorgang wird die Menge digitaler Daten verdichtet oder reduziert; auch hier wird zwischen verlustfreier und verlustbehafteter Kompression unterschieden. Beispiel: Beim Exportieren einer Photoshop-Datei zu JPEG erfolgt eine Bildkompression, mit dem Ziel, eine Datei zu erstellen, die die weniger Speicherplatz benötigt. Auf diesem Wege gehen Daten verloren. Wohingegen eine verlustfreie Komprimierung mittels Abspeichern als ZIP-Datei möglich ist; hierbei bleiben die Originaldaten erhalten.
Etwas verwundert mich der Diskussionsverlauf schon, denn eigentlich sollte es doch auf der semantischen Ebene ganz klar sein: Verwende ich Bildzeichen + Text, dann sollen ergänzende / spezifizierende und nicht konträre Informationen vermittelt werden. Das ist hier nun ins Gegenteil umgeschlagen, wenn man ein Icon wählt, bei dem ein Pfeil in etwas hineinzeigt und dieses dann mit der Bezeichnung Export (Ausfuhr) koppelt. Insofern hat Achim hier absolut zu Recht darauf hingewiesen.
Schöne Übersicht der Inkonsistenzen bei Google, ich verstehe jedoch die Diskussion in den Kommentaren um die Warte des Programmierers, der Daten oder des Users nicht – deshalb finde ich das Icon auch überhaupt nicht unpassend auch wenn die Inkonsistenzen ggf. ärgerlich sind.
Gerade in Analytics geht es bei einem Export ausschließlich darum die Daten herunterzuladen um dann auf dem Endgerät weiter zu analysieren bzw. zu verarbeiten. Ich erwarte daher als User stets dass die Daten aus der Cloud zu mir kommen (d.h. Pfeil runter). Dementsprechend gibt es bei Analytics sowieso keinen Import und also auch kein Pfeil hoch bei dem Daten hoch in die Cloud geschoben werden könnten.
Deswegen kann es m.E. auch anders als das “Öffnen in”-Icon in Google Docs sein, da es da ja durchaus verschiedene Programme gibt die direkt mit den Daten “da oben in der Cloud” irgendwie weiterarbeiten können, ohne dass ich etwas vorher runterladen muss.
Aus User-Sicht finde ich also das Icon gelungen, im Analytics-Kontext auch das Wort Export. Jetzt bleibt noch der Kommentar
Pfeil nach oben = Upload / Exportieren / User sendet (aktiv) / weg vom eigenen Endgerät
Pfeil nach unten = Download / Importieren / User empfängt (passiv) / auf das eigene Endgerät
der für Programme wie PS sicherlich perfekt passt da Export = Grafik aus Programm raus irgendwo hin. Das gleiche findet auch bei Analytics statt: Tabelle raus um in Excel reinzukommen. Der Unterschied ist m.E. nur, dass nunmal der Vorgang bei PS auf dem Gerät, bei Analytics aber in der Cloud startet.
Es geht daher im Endeffekt nicht um “hin oder weg zum Gerät” sondern “hin oder weg von der Quelle” oder gar “hin oder weg vom User”. Die Diskussion ist also de facto in diesem Fall ob der User den Unterschied versteht ob sein Programm lokal oder in der Cloud läuft. Ich denke, dass kann und muss man ihm zutrauen.
Dafür, dass sich in dieser Diskussion offenbar tatsächlich zwei gänzlich konträre Auffassungen gegenüberstehen, gelingt der Austausch, wie ich meine, bemerkenswert gut. Die Unterschiedlichkeit der Sichtweisen verstehe ich jedenfalls als Informationsgewinn.
Danke an dieser Stelle an alle, die sich konstruktiv einbringen!
Also für mich ist im Web Exportieren = Download = Pfeil runter und Importieren = Hochladen = Pfeil hoch.
Ich hab den ganzen Beitrag auch echt nicht kapiert und in sich widersprüchlich empfunden bis ich folgenden Ansatz gelesen habe: