Hello, Guest the thread was called12k times and contains 78 replays

last post from Retrofan at the

Ein UI-Konzept für den Textmodus

  • 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)

  • Ein paar Beispiele für den erwähnten Launcher, eines zeigt unseren Dialog im Maximalausbau (Karteikartenreiter, großer Hauptteil, Knöpfe):



    Aber wie gesagt - wie das Ding aussieht wäre völlig Schnuppe, da kann sich auch jemand im SuperHiresFLI-Modus austoben wenn er's bunt mag. Am Besten
    wären sowieso mehrere verfügbare Alternativen, aus denen der Nutzer seinen Favoriten wählt.

  • Sehr schön gemacht und von allen Mockups, finde ich das da Praktischte, Realistische und Schnellste für den C64.

    Wäre sowas 1985 rausgekommen als "UI Standard" wäre das schon cool gewesen.


    Heute ist es halt realistischerweise doch so, dass die meisten User nur noch Demos und Games auf reale Hardware laufen lassen.

    Der grösste Painpoint dazu ist wohl das Listen des Inhalts einer Diskette (oder virtuelle Diskette mit Flash Lösungen).

    Ob man das auf Diskette braucht zum Vorladen, um den Directory Inhalt anzuzeigen, bezweifle ich, da sicherlich viele User auch ein FC3 & co dazu verwenden, ob real Modul oder als CRT Image, die sowas ja meistens auf eine Funktionstaste mitbringen.

  • Schönes Konzept! Ob es verwendet wird, hängt wohl davon ab, ob es eine leicht zu verwendende Library geben wird.


    EDIT: ein Fortschrittsbalken wäre noch eine schöne Ergänzung.

  • Vielen Dank für das nette Feedback. Oh, richtig - ein Fortschrittsbalken... Peinlich, dass ich ausgerechnet den vergessen habe ;)


    Klar, Sinn machen würde so ein System nur für Leute mit Massenspeicher - mit nur CBM-Laufwerken ist eine Action Replay immer noch unschlagbar. Aber selbst für Standalone-Anwendungen könnte man ja eine freie UI-Bibliothek anbieten, die diese dann für die Kommunikation mit dem Anwender nutzen - so gibt es mehr Programme mit einheitlicher Bedienung... Aber bisher ist das nur ein Hirngespinst, ob ich das jemals anfange steht in den Sternen.


    Aber Brainstorming macht Spaß, weswegen ich mal meinem "Dialog-Editor" (*hüstel*) noch um einen maßgeschneiderten Zeichensatz erweitert habe - Tastatur-Shortcuts werden jetzt immer per Unterstrich markiert.


    Außerdem habe ich mir einen "grafischen" Launcher ausgedacht, samt eigenem Icon-Format. Ob das in der Praxis tatsächlich - wie im Screenshot angedeutet - scrollbar sein wird, müsste man erst noch ausprobieren. Als Icons habe ich mangels Grafiktalent Spiele-Sprites geklaut, weswegen sie fast alle im Multicolormodus sind - eigentlich besteht mein Icon-Format aus zwei Overlay-Hires-Sprites vor einem (mehrfarbigen) Hintergrund aus Textzeichen.

  • Sieht schon mal super aus! Ich finde den Ansatz "erst nachdenken und dann coden" prinzipiell auch deutlich überlegen. :-)

    Und die Gedanken, die Du Dir gemacht hast, sind durchaus sehr sinnvoll.

    Das ganze in eine leicht zu benutzende und trotzdem schlanke library verpackt. Das wäre sicherlich was.


    Ich stand beim Konfigurationsprogramm für den FPGASID vor einem ähnlichen Problem. Es sollte sich alles leicht und vor allem in sich konsistent bedienen lassen. Ich habe mich dann an die Tab-Struktur gehalten und mehere Bildschirme mit thematisch zusammenhängenden Einstellungen in die Tabs gruppiert. Fast alles lässt sich über Tastaturkommandos bedienen, wobei der jeweils korrespondierende Buchstabe auf dem Bildschirm markiert ist. Dort, wo zu viele Buchstaben nötig gewesen wären, kommt man mit den Cursortasten weiter und selektiert die Funktion mit Enter. manchmal kommen pop-up Boxen hoch um eine Aktion zu bestätigen. Es gibt auch Fortschrittsbalken beim flashen und für den Paddle Test bei der Diagnose.


    Das Ergebnis hat durchaus Anklang gefunden. Ich hatte sogar Anfragen bekommen, welche library ich da denn verwendet hätte und ob man die haben kann. Da muss ich aber leider enttäuschen: Die Ausführung in Software nicht sehr generisch gelungen. Das ist viel mehr Fake als tatsächlich schlaue Programmierung dahinter. Eine wirkliche "Library" gibts da nicht.


    Ich finde übrigens, dass die Optik schon auch sehr wichtig ist. Wenn aktive Bereiche hervorgehoben werden, erleichtert das die Bedienung doch sehr. Das habe ich vor allem bei meinen Pop-up Boxen gemerkt. Die hatten Anfangs keinen Schatten und es war nicht immer klar, dass man die erst mal beantworten muss, bevor es weiter geht. Auch ein Wechsel der Farbe (nach rot) brachte da nicht wirklich was. Erst der Schatten hats dann gebracht. :-)


    Wenns interessiert - Bilder vom Programm gibts hier: http://www.fpgasid.de/configuru


    Das Programm (welches auch ohne FPGASID im Demo-Modus läuft) gibts hier:

    http://www.fpgasid.de/downloads

    (link "Click here to download ConfiGuru version 0.D" ganz unten auf der Seite)


    "Jemand" sollte evtl mal ein Video machen, in dem man die Funktionen in live sieht. ;-)

  • Korodny: Danke, daß Du Dir konstruktiv so viele Gedanken machst über eine UI und dazu auch die Mockups zur besseren Veranschaulichung hinzufügst. :thumbup: Das sind m. M. n. brauchbare Ansätze, über die sich zu diskutieren lohnt. Eine kleine Frage hätte ich zu den Icons: Wie sollen diese gespeichert werden? Liegen die auf dem Datenträger in einer Extradatei vor (wie beim Amiga)? Und gibt es neben den spezifischen Icons auch unspezifische für Dateien, die nicht über ein eigenes Icon verfügen?

  • Eine kleine Frage hätte ich zu den Icons: Wie sollen diese gespeichert werden? Liegen die auf dem Datenträger in einer Extradatei vor (wie beim Amiga)? Und gibt es neben den spezifischen Icons auch unspezifische für Dateien, die nicht über ein eigenes Icon verfügen?

    Du denkst zu sehr an die Desktops, die du von Amiga/PC gewöhnt bist. Der "Launcher" startet einfach nur Anwendungen, mehr nicht. Unter "System" wären die Voreinstellungsprogramme zu finden, unter "Browse" kannst du im Textmodus durch alle angeschlossenen Laufwerke wühlen um eine Anwendung zu öffnen. Was unter "Games" und "Apps" auftauchen soll bzw. wie diese Abschnitte heißen würde dann vom Nutzer konfiguriert werden: Bezeichnung, verwendetes Icon, was soll beim Anklicken gestartet werden.


    Andere Einsatzmöglichkeiten (bzw. -notwendigkeiten) für Icons sehe ich auf einem C64 gar nicht. Einen Icon-basierten Dateimanager würde ich auf einem 8-Bit-Rechner nicht nutzen wollen - zu langsam und umständlich.


    Um das Laden von vielen Dutzend winziger Dateien zu verhindern, würde das zum Launcher gehörende Konfigurationsprogramm vermutlich alle benötigten Icons in eine große Datei packen, die würde der Launcher dann laden.

    Also ich persönlich wäre weniger für Icons, denn wir reden hier ja von ein UI für den Textmodus.

    Der Launcher ist einfach nur eine Anwendung, wenn er nicht gefällt nimmt man einen anderen. Aber natürlich hätte der Launcher auch einen reinen Textmodus: Zwei Spalten mit je 10 oder 20 - je nachdem wie "dicht" man den Text packen will - Einträgen, die jeweils 16 Zeichen Lang sind.


    Edit: Der Vollständigkeit halber hier noch ein Screenshot für den Launcher im Textmodus:

  • ich find das mit den icons nicht schlecht. könnte man mit sprites realisieren. wenn man das so wie korodny macht, mit 3 dateien

    pro zeile, könnte man für ein icon 2 sprites benutzen.

    wo ich meine bedenken habe, ist die verarbeitungsgeschwindigkeit.

    die icons könnte man in die reu klatschen. nur das laden, grade von einer sd karte, wäre dann wahrscheinlich tierisch langsam.

  • wo ich meine bedenken habe, ist die verarbeitungsgeschwindigkeit.

    die icons könnte man in die reu klatschen. nur das laden, grade von einer sd karte, wäre dann wahrscheinlich tierisch langsam.

    An dem Punkt, wo du Speichererweiterungen ins Spiel bringst, um Icons zu ermöglichen, solltest du deine Prioritäten vielleicht noch mal überdenken ;)


    Aber du stellst m.E. die falsche Frage: Die erste Frage lautet nicht "Wie implementiere ich Icons?" sondern "Wo machen Icons überhaupt Sinn?".


    Im Launcher - quasi das Equivalent zum Windows-Startmenü - sollte es keine Probleme mit der Verarbeitungsgeschwindigkeit geben: Die Inhalte dort sind alle vorkonfiguriert - und das Konfigurationsprogramm kann sie so abspeichern, dass sie optimal zu parsen sind. Speicherprobleme bekommen wir auch nicht, weil der Launcher und sein separates Konfigurationsprogramm außer den Icons und Programmnamen/Pfaden ja keine Daten im Speicher vorhalten müssen. 100 Icons sind weniger als 14 KB, 100 Bezeichnungen und Dateipfade vielleicht 10 KB - also da sollte reichlich Luft sein.


    Der einzig andere Einsatzzweck für Icons (auf einem 8-Bit-System) wäre ein Dateimanager. Die Frage ist also: machen Icons da Sinn?


    Abgesehen von den verschenkten 10 KB Hauptspeicher bekommst du optische Probleme - im Launcher kann ich die Namen der Einträge so auf zwei Zeilen umbrechen, wie ich will - ein Dateimanager kann das nicht. An einer beliebigen Stelle umzubrechen wird m.E. doof aussehen und die Lesbarkeit stark verringern und die einzig andere Möglichkeit wäre das Ausschreiben der Dateinamen - was bedeutet du müsstest immer 16 Zeichen Platz lassen, das wird sehr viel Leerraum und verschenkter Platz.


    Außerdem funktioniert der Icon-Ansatz aus ergonomischen Gründen m.E. in einem 8-Bit-Dateimanager nicht:

    • 90% der Dateien kannst du gar nicht zuverlässig erkennen - selbst wenn du die Startadresse und/oder den Header analysieren würdest, was sich aber aus Geschwindigkeitsgründen sowieso verbietet. Du würdest also den Großteil der Zeit auf das immer gleiche, generische Icon schauen.
    • Da der Dateimanager auch ausführbare Dateien nicht erkennen kann, müssten wir uns eine Krücke ausdenken wie wir bestimmten Dateien bestimmte Icons zuweisen, bspw. also eigene Datei- bzw. Diskformate oder interne Tabellen mit Dateiname->Icon-Verknüpfungen. Uh... die Konfigurationsarbeit wird hässlich.
    • Der Projekt-zentrierte Ansatz, den du von anderen Systemen gewohnt bist ("oh, ein Word-Dokument - ich doppelklicke das mal") funktioniert auf einem C64 gar nicht, weil Anwendungen nicht per Doppelklick auf eine Projektdatei gestartet werden können. Das könnte man natürlich einführen (uh, Konfigurationsarbeit...), aber dann müssten man auch gleich noch sämtliche Anwendungen umschreiben, damit man ihnen einen beim Start einen Dateinamen übergeben kann...

    Dann erst kommen die technischen Herausforderungen ins Spiel - aber m.E. ist der "Icons im Dateimanager"-Ansatz da schon gestorben.

  • Die erste Frage lautet nicht "Wie implementiere ich Icons?" sondern "Wo machen Icons überhaupt Sinn?".

    Wenn man - wie oben im Beispiel - als Icon das Spielersprite des jeweiligen Spiels benutzt, können auch Vierjährige alleine ihre Lieblingsspiele starten, ohne die Spielnamen lesen können zu müssen.


    Diskussionen über die Sinnhaftigkeit bzw. das Für und Wider bitte nicht in diesem Thread. ;)

  • Hier geht es nur um die beste optische Gestaltung eines Userinterfaces oder Betriebssystem für den C64 oder auch wie es genau realisiert werden soll?


    Ich frage mich immer, wie das funktionieren kann. Wie soll das gestartet werden? Worauf soll es laufen? Wie soll der Wechsel zwischen den Programmen funktionieren? Was ist mit den anderen Programmen, welche ausserhalb dieses OS laufen? Wer soll die ganzen neuen Programme dafür schreiben?


    Eigentlich wäre doch "nur" ein moderner Launcher bzw ein modernes Action Replay nötig, was automatisch beim Start die angeschlossenen Devices abfragt. Den Inhalt des Diskettenlaufwerks/ SD- Karte,... die Echtzeituhr, Onlineinfos über Netzwerk-/ WLanmodul...

    Es könnte eine eigene Cartridge sein oder ein Image auf der 1541 Ultimate und anderen geeigneten Modulen.


    Das Action Replay konnte ja schon Snapshots des aktuellen Systemzustandes machen und auf Diskette speichern. Sehr interessant wäre es nun, wenn ein neues Modul bzw Modulimage diesen Snapshot per Reset- Tastendruck automatisch (auf SD- Karte/ REU oder virtueller REU/ Festplatte/ eingebautem Flashspeicher) abspeichert. Dann könnte man ja endlich relativ einfach und schnell zwischen den verschiedensten Anwendungen oder Spielen wechseln?


    Ich frage mich, ob eine psychische Version oder ein Image, welches den Turbo des Chameleon nutzen könnte(?) nicht noch andere Sachen ermöglichen könnte, für die der C64 allein zu langsam ist. Die Umwandlung oder Erzeugung moderner Dateiformate wie PDF z.B.


    Sorry wenn das vielleicht zuviel OT war.

  • Ehrlich gesagt, die flotteste und bequemste Benutzerführung abseits von Kommandos in einer Shell, waren für mich immer all die Programme, welche Oberflächen wie typische DOS Programme hatten.


    Norton Commander, welches viel mit den F-Tasten schaffte. CrossPoint, Telemate, Telix oder Terminate, welche bestimmte Buchstaben als Kürzel nutzten, aber auch eine JEDERZEIT einblendbare Übersicht über die Kürzel hatten. (Alt-Z und sowas).


    Ich finde, sowas liesse sich auf dem C64 auch deutlich besser machen, als Icons, Maussteuerung und Windows-typische Fenster. Und das, obwohl ich GEOS cool finde.

  • Viel spannender als den Launcher finde ich die Möglichkeit, eine einigermaßen einheitliche Oberfläche für Tools die eine UI brauchen zu schaffen. Ich habe schon eine handvoll solcher Tools geschrieben und fummele mir jedesmal etwas zurecht. Oft halt mit Kompromissen, weil ich zu faul bin mir entweder etwas gescheites auszudenken oder es zu implementieren :).

  • Den Launcher ohne Icons finde ich viel besser, derr nutzt den vorhayndenen Platz viel besser aus, ist schneller, verbraucht weniger RAM, ... der könnte wohl in einem simplen CBM80-Cartridge laufen.

    "Wenn du überredet, ermahnt, unter Druck gesetzt, belogen, durch Anreize gelockt, gezwungen, gemobbt, bloßgestellt, beschuldigt, bedroht, bestraft und kriminalisiert werden musst. Wenn all dies als notwendig erachtet wird, um deine Zustimmung zu erlangen, dann kannst du absolut sicher sein, dass das, was angepriesen wird, nicht zu deinem Besten ist." - Quelle unbekannt.


    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.

    "Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.

    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.


  • Bei Oberflächen solcher Art, wie auch bei Programmen mit denen man zu tun hat, hängt mein erster Eindruck meistens daran fest, wie wenig 40 Zeichen Breite doch tatsächlich sind, und wie negativ sich das in der Praxis auf Lesbarkeit und Darstellungsmöglichkeit von Texten, Labels, Beschreibungen, Dateinamen, etc. auswirkt. Dann noch ein paar PETSCII-Rahmen dazu, und man kann bld. nur noch Abkrz. lesn. wl. kein Pltz. mehr ist...


    Wenn irgendwie möglich (Speicherbedarf etc.) würde ich erwägen, Textanteile optional mit einem 80-Zeichen-mässigen Charset anzubieten, oder wenigstens mit was auf "schmal" optimiertem wie z.B. Retrofans 53er-Zeichensätze aus den Zork-Threads vor einiger Zeit. Das erhöht die Darstell- und Lesbarkeit einfach immens, mMn.