Hier gibt's ja immer wieder Diskussionen über "neue OS" bzw.
Benutzeroberflächen. Ich hab die bisherigen Vorschläge immer für optisch
nett aber komplett praxisfern gehalten. Nachdem Retrofan mich
aufgefordert hatte, "doch mal mein Konzept" vorzustellen, ist mir
aufgefallen, dass ich gar kein Konzept habe 
Fand
das aber eine nette Denksportaufgabe, also habe ich mich mal hingesetzt
und mir was ausgedacht. Mehr ist das hier nicht - also Hinweise zur
Nutzlosigkeit oder der Flut an solchen Themen bitte nach /dev/null.
Ach ja: Hier geht's erst mal nur um ein UI, nicht um ein OS.
Grundidee
Die Frage war: wie sollte eine moderne Benutzeroberfläche für C64-Anwendungen aussehen? Meine Anforderungen an so ein UI wären:
- möglichst einfache Anpassung von existierendem Code
- Textmodus - entlastet RAM und CPU
- Mausbedienung möglich, aber nicht zwingend - Mehrheit der Nutzer hat keine Maus
- einheitliche Bedienung über alle Anwendungen hinweg
- moderne Konzepte, wo möglich und sinnvoll - bspw. "Öffnen"/"Speichern"-Dialoge
- Konzentration auf die Anwendungen bzw. Anwendungsfälle die beim C64 bereits existieren - ein UI für einen Web-Browser oder eine WYSIWYG-Textverarbeitung braucht es nicht wirklich
Ich habe für die folgenden Mockups den Original-Zeichensatz verwendet, mit einem eigenen Zeichensatz wäre das optisch sicher besser umzusetzen: Schönere Rahmen, Unterstrich statt farblicher Hervorhebung für Shortcuts usw. Ich bin kein Grafiker, ich versuche lediglich ein Bedienkonzept zu illustrieren.
Fenster oder Dialoge?
"Fenster" gibt es bei mir nicht - die sind auf einem C64, wo immer nur eine Anwendung läuft und diese immer nur ein Projekt geöffnet hat, schlicht unnötig. Die Idee ist, Programmierern eine möglichst vielseitige Dialogbox zur Verfügung zu stellen, die vor der laufenden Anwendung ein- und nach Benutzung wieder ausgeblendet wird. Diese Dialogboxen erstellt der Programmierer mit einem einfachen Editor, der gleich Assembler-Sourcecode generiert.
Die einfachste Form besagter Dialogbox ist das hier:
Hier sieht man alle wesentlichen Elemente in ihrer einfachsten Form: Den Reiter ("Warning"), der hat - erst mal - nur informellen Charakter. Der Hauptteil, der hier nur einfachen Text enthält, sowie die "Knöpfe" - die aus Platzgründen, im Gegensatz zu modernen GUIs an der Seite angeordnet sind statt unterhalb: Bei nur vierzig Zeichen ist sonst bei vier oder fünf Knöpfen Schluß - und wir werden gelegentlich mehr brauchen.
Tastaturbedienung: STOP bricht alles ab, auch Dialoge - deswegen gibt es nirgendwo "Cancel"-Knöpfe. Mit CRSR und RETURN wird das gelbe Highlight bewegt und der gewünschte Knopf aktiviert. Alternativ kann man einen Knopf mit den Tastatur-Shortcuts aufrufen ("S" für Save, "D" für Don't save").
Mausbedienung: Wird die Maus bewegt, verschwindet das gelbe Highlight erst mal und taucht von da an immer dann auf, wenn sich der Mauszeiger über einem klickbaren Element befindet. Anklicken mit Links, Ein Rechtsklick entspricht der STOP-Taste.
Die folgenden Mockups zeigen kompliziertere Dialoge. Der Hauptteil kann ebenfalls Gadgets enthalten - aber keine Knöpfe. Zu sehen sind hier Texteingabefelder ("___"), Checkboxen (wechseln zwischen "[N]" bzw. "[Y]") und Drop-Down Gadgets (Klick auf "(08)" öffnet eine Auswahlliste). Der Reiter kann weggelassen werden, ebenso wie der Hauptteil, statt einer Reihe Knöpfe kann der Dialog auch zwei Reihen enthalten.
Bedienung wie gehabt: Jedes Element kann mit CRSR+RETURN, Tastatur-Shortcut oder der Maus aktiviert werden. Wenn ein Texteingabefeld aktiv ist (Cursor blinkt), müssen Tastatur-Shortcuts mit CONTROL+Buchstabe eingegeben werden.
Möglich wäre auch ein Dialog ganz ohne Knöpfe, bspw. Für eine "About"-Info, einen kurzen Hilfstext o.ä. Der würde dann schlicht per beliebigem Tastendruck (außer CRSR, wegen Scrolling) oder Mausklick beendet.
Menüs
Für Produktiv-Anwendungen, die das aktuelle Projekt (fast) bildschirmfüllend anzeigen, machen Menüs Sinn. Die klassische Menüzeile hätte hier aber eine Reihe Nachteile:
- funktioniert nur im Textmodus, also bspw. für Grafikprogramme sinnlos
- benötigt zusätzlichen, Menü-spezifischen Code (und vermutlich einen Cache)
- belegt dauerhaft Platz auf dem Bildschirm, verkompliziert Bildschirmaufbau
- zu Maus-zentriert
Meine Alternative: Wenn es gerade nichts abzubrechen gibt, blenden STOP bzw. Rechtsklick einen Menü-Dialog ein. Um die Baumstruktur klassischer Menüs abbilden zu können, führen wir einfach Karteikartenreiter ein:
Die Idee ist, dass jeder Keybord-Shortcut exklusiv ist, so dass erfahrenere Anwender gleich "STOP", "O(pen)" statt "STOP", "F(ile)", "O(pen)" drücken können. Eventuell macht man die Keyboard Shortcuts wie bei den großen Systemen auch gleich außerhalb des Menüs verfügbar: CONTROL+O.
Dieser Menü-Dialog könnte auch Kontext-Sensitiv sein, also unterschiedliche Menüs anbieten je nachdem wo wir uns gerade befinden oder ob ein Text- bzw. Grafikausschnitt markiert ist oder nicht.
Zum Schluss noch die erwähnten "Speichern/Öffnen"-Dialoge (sowie ein mal Öffnen mit der Option mehrere Einträge zu wählen):
Sonstige GUI-Elemente?
Ehrlich gesagt fallen mir gar keine weiteren UI-Elemente ein, die es braucht. Ich hatte noch an eine Statuszeile gedacht, aber die einzig globalen - also vom System verwalteten - Status-Meldungen wären "Uhrzeit" und "Online-Status". Beides benötigt Zusatzhardware, die nicht jeder hat. Außerdem fallen mir nur extrem wenige Anwendungen ein, die eine ausdrückliche Statuszeile nutzen - eigentlich nur Textverarbeitungen.
Desktop?
Einen Desktop brauchen wir nicht, weil die meisten Aufgaben eines Desktop bei uns gar nicht anfallen. Stattdessen gibt es wie bei Android oder TheC64 einen Launcher. Der ist einfach nur eine simple Anwendung, zum Starten anderer Programme - die beliebig aussehen kann, sofern sie die grundlegenden Anforderungen (Maus- und Tastaturbedienung etc.) erfüllt bzw. die Farbgebung übernimmt.
(weiter im nächsten Beitrag - Attachment-Limit erreicht)
