New Firefox GUI - Text

Großansicht: Mockup 1, Mockup 2


Das Interface eines Browsers sollte möglichst minimal sein und dem User viele Freiheiten bieten. Anstatt die Menüs in kleine Buttons zu pferchen, schlage ich vor, sie an anderer Stelle unter zu bringen und ihnen mehr „Raum“ zu geben. Ideal wäre dafür ein frisch geöffneter, leerer Tab. Dieser bietet genug „Oberfläche“ und hat den Vorteil, dass die Bedienelemente wegfallen, sobald man eine Internetseite aufruft. Diesen ehemalig leeren Tab könnte man zu einer Art „zweitem Desktop“ („Fire-Desktop“) umfunktionieren, in dem alle Elemente in Form von Widgets darauf positioniert werden. Dadurch würde man der oft geforderten Anpassbarkeit Rechnung tragen und dem User weitestgehend entscheiden lassen, wie er die neu gewonnene Oberfläche nutzt und gestaltet.

Klickt der User z.B in der „Sub-Navigationsleiste“ auf „Lesezeichen“, wird anstatt einer Dropdown-Liste die komplette untere Seite zum Anzeigen der Informationen genutzt. Dies erlaubt es, bessere Darstellungsmethoden zu wählen als bisher. Die Browser-Chronik könnte um einen Zeitlinien- und Baumdarstellungsmodus erweitert werden. Zusätzlich finde ich, dass Firefox unbedingt einen guten RSS-Reader von Beginn an mitliefern sollte, da RSS-Feeds zu einem fester Teil des Internets geworden sind (von der Handhabung her könnte man sich am „Brief-Reader“ orientieren).


Über die Widgets:

Wie bereits geschrieben, wäre jedes Element innerhalb des „Fire-Desktops“ ein Widget. Durch einen Klick auf das Schloss in der unteren rechten Ecke entsperrt man diese. Danach lassen sich die verschiedenen Widgets frei positionieren, ihre Größe ändern, verschiedene Widget-Skins wählen (groß-bunt oder minimalistisch-klein), Widget-Optionen anpassen, neue Widgets hinzufügen und bestehende entfernen. Viele würden sich sicherlich darüber freuen, wenn sie ein Desktop-Hintergrundbild frei wählen könnten.


Neue Widgets installiert man über die Mozilla Add-on-Seite, die eine extra Unterkategorie „Widgets“ enthalten sollte. So könnte der User seinen „Fire-Desktop“ individuell einrichten, was einen erheblichen Mehrwert darstellen dürfte.


Mit der Zeit würden sich immer mehr, neue, sinnvolle Möglichkeiten für den „Fire-Desktop“ finden. Weshalb eine möglichst offene Gestaltung des Desktops wichtig ist.


Grüße

Paradiesstaub


PDF: Firefox GUI – Eine Idee


Eine-Zeile-GUI - Mockup - GER

Advertisements

Diese Idee ist auf mein Konzept angepasst, dass ich für die Mozilla Design Challenge 09 eingereicht hatte. Ohne den Inhalt der Tabs zu kennen, versuche ich mittels Baumstruktur Interessengebiete in Gruppen zu fassen.


Da es hier im Detail darum geht, nach welchen Regeln Tab-Gruppen erstellt werden, sollte dieser Gedankengang für andere Konzepte übertragbar sein. Das angestrebte Ziel ist es, möglichst wenige, gut sortierte Tab-Gruppen am Ende zu erhalten. Um meine Idee nahe zu legen, erkläre ich sie zunächst Schritt für Schritt und danach erst, warum etwas passiert.


Browser wird geöffnet. Dabei wird ein „Geburtsbaum“ eingerichtet und die Startseite geöffnet. Wie der Name „Geburtsbaum“ schon sagt, werden hier Bäume geboren, genauer gesagt Tab-Bäume. Der erste Ast in diesem Baum ist die Startseite. Für den „Geburtsbaum“ gilt eine extra Regel: „Alle Tabs (Superior Tabs), die neu geöffnet werden, gehören anfangs dem „Geburtsbaum“ an. Erst wenn von einem neuen Tab (Superior Tabs) aus ein weiterer Tab (Sub Tab) geöffnet wird, werden diese zwei zusammenhängenden Tabs in eine eigene Tab-Gruppe überführt“. Diese Auskopplung gilt solange die Tab-Gruppe aus mehr als einer Seite besteht“. „Superior Tabs“ sind Tabs die durch das Klicken auf das Plus-Zeichen oder per STRG+T entstehen – „ Sub Tabs“ entstehen beim Öffnen eines Links von einer Seite zu einer anderen (z.B. durch einen „mittleren Maustaste“-Klick auf einen Link). Dieser Geburtsprozess der Tab-Gruppen verhindert, dass ein User 50 Tabs mit STRG+T öffnet und er danach 50 Tab-Gruppen hat. Die weiteren Ausführungen beschäftigen sich ausschließlich mit der Baumstruktur eines Tabs, der diesen Geburtsprozess durchlaufen hat und somit eine eigene Tab-Gruppe darstellt (kurzum, nur mit „Sub Tabs“).


Bisher würde das Ganze so aussehen:


Bild1


Der oberste Punkt auf dem Bild (der Stern) ist der Starter, er begründet die Gruppe. Darunter ist die erste Seite (Seiten und Tabs sind weiße Kästchen), von der ein Tab abgeleitet wurde.


Da das Generieren von Tab-Gruppen nach der obigen Regel wenig Sinn für „erwachsene Tabs“ macht, habe ich mir eine weitere Regel ausgedacht: „Werden von einer Seite mehr als zwei Tabs geöffnet, wird die Tab-Baum-Struktur solange hochgegangen, bis die vorliegende Regel das nächste Mal verletzt wird oder bis der Tab-Starter erreicht ist, um einen Ast auszuhängen und eine neue Ast-Gruppe zu bilden“.

Diese Regel scheint etwas kompliziert, doch Grafiken helfen diese leichter zu verstehen.


Bild2Bild3













Wie man auf den Bildern sieht, wird die neue Gruppe (gelb) in den bisherigen Baum eingebunden. Dies hat den Vorteil, dass die Zuordnung weiterhin anpassbar bleibt. Da der User zwischen den einzelnen Tabs hin und her springen kann, muss die Baumstruktur flexibel sein, dies zeigt folgendes Beispiel. Wir nehmen an, dass ein User zunächst mehrere Tabs und dann anschließend weitere Tabs an einem höher gelegenem Knotenpunkt erstellt. Dies hätte zur Folge, dass eine weitere Ast-Gruppe gebildet wird und sich die Baum-Struktur der zweiten Ast-Gruppe verändert.


Bild4

Da nicht nur neue Tabs geöffnet, sondern auch Tabs geschlossen werden können, stellt sich bei dieser Baumstruktur die Frage, wie sie sich verhält und vor allem, wie sie sich verhält, wenn Tabs/Knotenpunkte geschlossen werden, die für mehrere Ast-Gruppen von Bedeutung sind. Beim Schließen eines Tabs werden die unteren Strukturen einfach an den nächst höheren Knotenpunkt angehängt. Sind die Bedingungen, um eine Ast-Gruppe darzustellen, nicht mehr erfüllt, wird die Gruppe aufgelöst und in die obere eingegliedert. Wird allerdings wie im nächsten Bild ein wichtiger Verbindungsknoten gelöscht (ist auf dem Bild mit einem ‚x‘ markiert), stellt sich die Frage: „Welche von den beiden Gruppen darf jetzt den von beiden beanspruchten Tab einbinden?“.


Bild5aBild5b













Die Antwort ist, dass der Tab der Gruppe angehört, die ihn zuletzt besaß. Dadurch wird verhindert, dass einzelne Tabs ständig zwischen den verschiedenen Ast-Gruppen hin und her springen.


Bis jetzt war es für den User relativ egal, welche Tabs welcher Ast-Gruppe angehören und ob eine Ast-Gruppe erstellt oder aufgelöst wird, da er nach meinem Konzept noch alle Tabs wie gewöhnlich geöffnet hat. Erst wenn eine Tab-Ast-Gruppe minimiert wird, bekommen die darin enthaltenen Tabs eine Bedeutung, da sie fest ausgelagert werden. Siehe Bild: Es zeigt eine Tab-Ast-Gruppe, auf die einmal geklickt wurde (auf dem Bild sind zwei minimierte Tab-Gruppen zu sehen).


Bild6

Es wäre sehr ärgerlich, wenn man in einer minimierten Ast-Gruppe ein paar Tabs löschen würde und plötzlich die ganze Ast-Gruppe verschwindet, da diese nicht mehr der Regel entspräche und somit woanders eingegliedert würde. Um dieses zu verhindern, schlage ich das Einfrieren der minimierten Tab-Struktur vor. Dadurch wäre es möglich, einzelne Tabs zu löschen, ohne dass die Ast-Gruppe woanders eingegliedert wird. Stellt der User aus einer minimierten Tab-Ast-Gruppe einen einzelnen Tab wieder her, so wird dieser „aufgetaut“ und es gelten die Standardregeln.


Bild7aBild7b

Bild7c

























Beim Speichern einer Tab-Gruppe wird die zugrunde liegende Baum-Struktur mitgespeichert. Da der User weitere Tabs einer bereits gespeicherten Gruppe hinzufügen kann, schlage ich vor, diese direkt unterhalb des Starters einzubinden, was zur Folge hätte, dass die bisherigen Gruppen-Strukturen nicht beeinflusst würden.



Der Vorteil dieser Methode:

Sie ermöglicht es einem, viele Internetseiten in wenige, strukturierte Gruppen zusammen zu fassen, deren Struktur ableiten lässt, woher man kommt. Ein kleines Beispiel: Nehmen wir an, das folgende Bild würde eine Google-Suche darstellen, dann wäre die erste Seite das Google-Suchergebnis. Verschiedene Suchergebnisse würden in Form von geöffneten Tabs darauf folgen. Einer dieser Tabs wäre ein Wikipedia-Artikel, von dem wir aus weitere Links öffnen. Solange wir dabei nicht mehr als zwei Tabs von einer Seite aus öffnen, gehört die ganze Struktur der „Google-Gruppe“ an (rot). Erst wenn der User mehr als zwei Tabs von einer Seite aus öffnet, wird eine neue Ast-Gruppe gebildet (gelb). Diese beinhaltet alle Tabs des Baumes bis hin zum Wikipedia Artikel (der auch enthalten ist). Für den User ist es nicht so wichtig genau zu wissen, wie die zweite Tab-Gruppe entstanden ist. Für ihn ist vielmehr wichtig, dass er in der zweiten Tab-Gruppe sieht, woher er kommt, nämlich von Wikipedia.


Bild3



Nachteil:

Der User wird in den meisten Fällen nicht verstehen, warum eine neue Tab-Gruppe gebildet wurde (dies ist meiner Meinung nach zu vernachlässigen, da der gewünschte Effekt erzielt wird). Wie tauglich letztendlich meine vorgeschlagen Methode ist, kann nur ein Feldtest beweisen.


Anfügen möchte ich hier noch, dass ich automatisierte Konzepte für wesentlich geeigneter halte als Konzepte, die das Tab-Gruppieren dem User überlassen. Zudem sollte immer darauf geachtet werden, das möglichst wenige Klicks nötig sind und die Mauswege kurz gehalten werden. Soweit zu dieser Idee. Mich würde interessieren, was ihr darüber denkt und wo ihr die Stärken/Schwächen seht.



Grüße

Paradiesstaub



PDF: Idee – Wie man Tabs sinnvoll gruppieren könnte

Creative Commons-Lizenz: Namensnennung 3.0 Vereinigte Staaten von Amerika