IF-Forum

» IF-Forum - Autorencafé - Schreiben! - Stand deutscher Entwicklungssysteme
AntwortenNeues ThemaNeue Umfrage
» Mehrere Seiten: 12345

Stand deutscher Entwicklungssysteme

Geschrieben um 21:53 am 06.12.2022 | Zitat | Editieren | Löschen
proc
Avatar
Mitglied
Retired Gumby
Beiträge: 663

Ich habe jetzt mal Le jeu à énigmes en mode texte auf donjon.fi angeguckt und bin froh, dass wir auf deutsch stets so ein großes Angebot an Systemen haben. Aber gut, vielleicht macht's ja Sinn, für mich jedenfalls nicht.

-----
Geschrieben um 12:07 am 07.12.2022 | Zitat | Editieren | Löschen
Hannes
Avatar
Globaler Moderator
Prof Gumby
Beiträge: 487

Martin:

Diese niederschwelligen Systeme scheinen auf jeden Fall die Quantität der Spiele zu erhöhen ...

Ist halt wieder der gleiche Effekt wie seinerzeit mit ADRIFT und Quest oder noch viel früher mit AGT. Bei Systemen, die die Komplexität nicht verstecken (denn sie existiert ja immer, egal wie sehr man sie per Drag & Drop-Interface maskiert), ist die Einstiegshürde so hoch, dass man ziemlich sicher sein kann, meist Autoren mit der Geduld und dem Sinn für Details zu haben, dass nachher was Vernünftiges rauskommt. Aber was ist das richtige Maß an sog. Zugänglichkeit? Weiß keiner.

Geschrieben um 21:34 am 14.12.2022 | Zitat | Editieren | Löschen
Martin
Avatar
Mitglied
Prof Gumby
Beiträge: 603

proc: Ich habe jetzt mal Le jeu à énigmes en mode texte auf donjon.fi angeguckt und bin froh, dass wir auf deutsch stets so ein großes Angebot an Systemen haben.

Hm. Hatten wir nicht festgestellt, dass man, wenn man Spiele auf Deutsch schreiben will, eine Auswahl von meist veralteten und schlecht gepflegten Systemen ist? Drehen wir uns hier im Kreis?

Hannes: Bei Systemen, die die Komplexität nicht verstecken (denn sie existiert ja immer, egal wie sehr man sie per Drag & Drop-Interface maskiert), ist die Einstiegshürde so hoch, dass man ziemlich sicher sein kann, meist Autoren mit der Geduld und dem Sinn für Details zu haben, dass nachher was Vernünftiges rauskommt. Aber was ist das richtige Maß an sog. Zugänglichkeit? Weiß keiner.

Das Programm sollte also eine steile Lernkurve haben, damit sichergestellt ist, dass nur geduldige Autoren überhaupt ein Spiel schreiben können?

Die Komplexität steckt ja schon darin, das Spiel selbst zu entwerfen. Das System selbst sollte da möglichst wenig im Weg stehen. Der Unterschied zwischen den "einfachen" und den "komplexen" Systemen zeigt sich ja oft nur, wenn ich etwas besonders Komplexes machen will, das sich mit den einfachen Systemen dann nicht umsetzen lässt.

Zugänglichkeit ist nichts Schlechtes. Die einfachen Sachen sollen einfach, die komplexen zumindest möglich sein. Wenn man sein Spiel aber so entwirft, dass die komplexen Dinge nicht nötig sind, kann man mit den so genannten einfachen Systemen auch ein gutes Spiel schreiben.

Dass eine gute Zugänglichkeit dazu führt, dass es auch mehr Schlechtes gibt, damit muss man sich wohl abfinden. Solange man die guten Sachen unter den schlechten noch findet, finde ich das nicht weiter schlimm.

Wo die Komplexität liegt, ändert sich auch. Im Designers' Manual von Inform 6 lag noch ein sehr starkes Augenmerk auf komplizierten Parser-Spielchen. Ein großer Teil der Übungen befasst sich mit sprachgesteuerten Bordcomputern, Bibeln, in denen man einzelne Bücer nachschlagen kann, riesigen begehbaren Schachbrettern, die mit mur einem Raum und einem Objekt umgesetzt wwerden und, und, und. Für Inform 7 hat Emily Short die Direktive ausgegeben, dass man nie wieder parse_name verwenden soll. Die Parser-Geschichten sind weitestgehend verschwunden, dafür gibt es jetzt umfangreiche Relations, mit denen man die Beziehungsgeflechte aus den Romanen von Jane Austen nachstellen kann.

Man kann mit den komplexen Systeme übrigens auch "einfache" Spiele schreiben. Das französiche I7-Tutorial beginnt man in einer Oase, die eigenartigerweise direkt neben einem Dschungel liegt:

Sie sehen hier eine Steintür, ein Dromedar und eine Palme.

Grrr. Diese lieblose und unsortierte Auflistung der Gegenstände ist leider typisch für Inform, egal ob 6 oder 7. Alles, was nicht ausdrücklich als scenery gekennzeichnet ist, wird gelistet. Ehrlich gesagt, ist das nicht viel besser als

I'm in an Oasis.

Obvious exits: N W E S

I can also see: stone door - dromedary - palm tree

Meiner Auffassung nach gehören nur Objekte, die ich aufheben kann in die allgemeine Auflistung. Die Steintür gehört zum Ausgang im Süden und wird daher in der Raumbeschreibung erwähnt. Ebenso die Palme, mit der ich noch nicht einmal etwas Gescheites machen kann. Das Dromedar sollte zumindest einen eigeen Absatz bekommen und nicht zusammen mit anderen Objekten aufgelistet werden. Dabei bietet Inform ja mit initial und listing_together die Möglichkeit, das zu ändern.

proc: [Donjon FI] Aber gut, vielleicht macht's ja Sinn, für mich jedenfalls nicht.

Du hast ja recht: Donjon ist nicht doll und macht mit dem unterimplementierten Demo-Spiel Coincé des Autors auch nicht unbedingt Werbung.

Dass ich mit dem System nicht warm werde liegt auch daran, dass der Autor nicht dieselbe Vorstellung von einem Textadventure hat wie ich. Das Interface ist eher wie eine Linux-Shell gestaltet: Wenn ein Verb nicht verstanden wird, kommt direkt ein langer Hilfetext. Wenn ein Objekt zu einem Verb nicht verstanden wird, kann man manchmal mit "aide prendre" oder so eine gezielte (aber für mich nicht besonders nützliche) Hilfe anfordern.

Wenn ich etwas aufhebe, heißt es: "Sie haben die Murmel Ihrem Inventar zugefügt." Viel technischer kann man das ja nicht sagen.

Geschrieben um 22:47 am 14.12.2022 | Zitat | Editieren | Löschen
StefanH
Avatar
Mitglied
Bachelor Gumby
Beiträge: 51

Grrr. Diese lieblose und unsortierte Auflistung der Gegenstände ist leider typisch für Inform, egal ob 6 oder 7. Alles, was nicht ausdrücklich als scenery gekennzeichnet ist, wird gelistet.

Doofe Frage: Wie willst du es denn sonst machen als es an sowas wie dem scenery-Flag (oder weiteren Flags ähnlicher Beschaffenheit) festzumachen?

Geschrieben um 09:03 am 15.12.2022 | Zitat | Editieren | Löschen
Hannes
Avatar
Globaler Moderator
Prof Gumby
Beiträge: 487

Martin:

Hannes: Bei Systemen, die die Komplexität nicht verstecken (denn sie existiert ja immer, egal wie sehr man sie per Drag & Drop-Interface maskiert), ist die Einstiegshürde so hoch, dass man ziemlich sicher sein kann, meist Autoren mit der Geduld und dem Sinn für Details zu haben, dass nachher was Vernünftiges rauskommt. Aber was ist das richtige Maß an sog. Zugänglichkeit? Weiß keiner.

Das Programm sollte also eine steile Lernkurve haben, damit sichergestellt ist, dass nur geduldige Autoren überhaupt ein Spiel schreiben können?

Eine steile Lernkurve erhöht die Wahrscheinlichkeit eines "geduldigen" Autoren ungemein. Das ist nur eine Feststellung. Sollte man deshalb den Einstieg schwierig machen? Nein, das habe ich nicht gesagt und ist auch nicht meine Meinung.

Wobei das, was heute als "steile Lernkurve" bezeichnet wird, ja ehrlich gesagt auch alles tatsächlich zugängliche Hochsprachen sind. Selbst I6 ist ja sehr, sehr nahe an kanonischem Englisch, man kann den Code von Objektdefinitionen und zugehörigen Aktionen auch als Nichtprogrammierer lesen und im Wesentlichen verstehen, was das soll. (Nein, ich spreche nicht von parse_name Verrenkungen.)

In diesem Sinne bin ich durchaus der Meinung, dass ein sanity check bzgl. Entwicklererwartungen auch immer mal wieder angebracht wäre.

Geschrieben um 18:05 am 15.12.2022 | Zitat | Editieren | Löschen
Martin
Avatar
Mitglied
Prof Gumby
Beiträge: 603

StefanH: Doofe Frage: Wie willst du es denn sonst machen als es an sowas wie dem scenery-Flag (oder weiteren Flags ähnlicher Beschaffenheit) festzumachen?

Ja, natürlich muss so etwas auf Basis der Objekteigenschaften passieren. Für Inform sind scenery (das Objekt wird nicht aufgelistet) und static (Objekt kann nicht aufgehoben werden) aber zwei unabhängige Konzepte. (Und concealed gibt es auch noch, um das Objekt in der Liste zu unterdrücken. Das DM4 selbst zitiert Andrew Plotkin in einer Fußnote zur Beschreibung des Weltmodells: "I've always said that the definition of concealed was ad-hoc and not well understood by anybody.")

Außerdem fallen auch Personen unter "alles, was nicht 'scenery' ist", was sie zusammen mit allerlei Gerümpel in Listen erscheinen lässt, wenn man nicht explizit einen eigenen Absatz mit describe oder initial angibt.

Das kann man so machen, aber meine (subjektive) Empfindung ist, dass viele Autoren diese Attribute nicht verstehen. Vielen Autoren und Spielern sind die ungeordneten Listen auch egal, aber mich stören sie.

Geschrieben um 20:54 am 16.12.2022 | Zitat | Editieren | Löschen
StefanH
Avatar
Mitglied
Bachelor Gumby
Beiträge: 51

Das kann man so machen, aber meine (subjektive) Empfindung ist, dass viele Autoren diese Attribute nicht verstehen.

Ok, das klingt jetzt so, dass das eigentliche Problem ist, wie die Autoren mit diesen Attributen umgehen. Die Attribute selbst kann ich allesamt nachvollziehen und die sind im Phoney Island Objektmodell auf erstaunlich gleiche Weise auch so enthalten, ohne dass ich das von irgendwo übernommen hätte. Inklusive dieses etwas brachialen concealed Attribut. Offensichtlich ergeben sich diese Attribute fast von selbst.

Geschrieben um 12:26 am 17.12.2022 | Zitat | Editieren | Löschen
Martin
Avatar
Mitglied
Prof Gumby
Beiträge: 603

StefanH: Ok, das klingt jetzt so, dass das eigentliche Problem ist, wie die Autoren mit diesen Attributen umgehen.

Stimmt schon, man könnte auch sagen, dass die leblosen Listen ein Benutzerfehler sind. Und ja, das Attribut concealed bedeutet genau das, was draufsteht.

Ich finde aber trotzdem, dass das System, in diesem Fall das Modell der I6-Library, es dem Autoren so leicht wie möglich machen sollte. Wieso werdrn die Konzepte "wird aufgelistet" und "kann man mitnehmen" getrennt betrachtet? Für mich sind diese beiden Konzepte miteinander verknüpft: In der generischen Liste der Dinge im Raum ("Außerdem siehst du hier ...") tauchen nur Dinge auf, die ich mitnehmen kann. Alles andere wird entweder in der Raumbeschreibung erwähnt oder bekommt einen eigenen Absatz. Die genersche Liste am Ende der Raumbeschreibung existiert ja nur, weil man diese Sachen mitnehmen und woanders wieder ablegen kann.

A propos "kann man mitnehmen": In I6 werden Dinge, die man nicht mitmehmen kann, als 'static' gekennzeichnet, in I7 als 'fixed in place'. Meiner Meinung nach ist das genau falsch herum: Alles sollte fest sein, nur Gegenstände, die man aufheben kann, sollten zum Beispiel als 'portable' gekennzeichnet werden.

Im Abschnitt über Türen des Designers' Manual heißt es:

Note that the door is static - otherwise the player could pick it up and walk away with it. (Experienced play-testers of Inform games try this every time, and usually come away with a door or two.)

oder Fußnote 2 im Abschnitt Finishing:

It wasn't until the fifth proofs of §12 of this manual that any of us noticed that the "great stone slab" altar of 'Ruins' had never been made static.

Ein anderer Default würde so etwas verhindern: Dass man Dinge, die man aufheben können sollte, nicht aufheben kann, bemerkt jeder Tester. Wahrscheinlich bemerkt es der Autor selbst schon schnell und ein automatischer Start-Ziel-Durchlauf findet es auch.

Ach ja, ich hacke wieder auf Inform herum, dabei finde ich vieles dort nicht so schlecht. Und Inform 6 wurde in den Neunzigern entworfen, als Spiele halt noch viel mehr mitnehmbare Objekte hatten. Trotzdem finde ich es schade, dass diese Sachen in I7 nicht überarbeitet wurden.

StefanH: Die Attribute selbst kann ich allesamt nachvollziehen und die sind im Phoney Island Objektmodell auf erstaunlich gleiche Weise auch so enthalten, ohne dass ich das von irgendwo übernommen hätte. Inklusive dieses etwas brachialen concealed Attribut. Offensichtlich ergeben sich diese Attribute fast von selbst.

Na klar. Als Graham Nelson Curses geschrieben hat, stand er natürlich vor den gleichen oder zumindest sehr ähnlichen Fragestellungen wie Du bei Phoney Island.

Hannes: Eine steile Lernkurve erhöht die Wahrscheinlichkeit eines "geduldigen" Autoren ungemein. Das ist nur eine Feststellung.

Mag sein. Ich glaube, ich verstehe jetzt, was Du sagen willst: Es gibt allgemein geduldige und weniger geduldige Menschen. Die Geduldigen können sich in ein System einarbeitet und haben auch die Geduld, ein rundes Spiel zu schreiben.

Ich glaube aber, dass die Geduld nicht gleich verteilt ist: Wer geduldig ein Spiel entwirft lernt nicht unbedingt geduldig ein neues System.

Hannes. Wobei das, was heute als "steile Lernkurve" bezeichnet wird, ja ehrlich gesagt auch alles tatsächlich zugängliche Hochsprachen sind. Selbst I6 ist ja sehr, sehr nahe an kanonischem Englisch, ...

Da stimme ich dir zu: Vieles bei den als komplex empfundenen Systemen ist auch nur "Formulare ausfüllen", wie bei den einfachen Systemen. Und man muss die Komplexität der Systeme nicht unbedingt ausreizen.

(Über die Zugänglichkeit von I6 sage ich aber mal lieber nichts.)

Hannes: In diesem Sinne bin ich durchaus der Meinung, dass ein sanity check bzgl. Entwicklererwartungen auch immer mal wieder angebracht wäre.

Das verstehe ich, glaube ich, nicht ganz. Wer soll denn seine Erwartungen überprüfen ‒ Autoren ihre Erwartungen an vermeintlich einfache oder komplexe Systeme oder die Entwickler die Erwartungen an die Akzeptanz ihrer Systeme?

Geschrieben um 09:08 am 20.12.2022 | Zitat | Editieren | Löschen
Hannes
Avatar
Globaler Moderator
Prof Gumby
Beiträge: 487

Martin:

Wieso werdrn die Konzepte "wird aufgelistet" und "kann man mitnehmen" getrennt betrachtet?

Weil vielleicht nicht die gesamte Welt deine Präferenz zur logischen Verknüpfung der beiden teilt? Deine Argumentation ist in sich stimmig, aber eben nur im spielmechanischen Sinn. Erzählerisch mag es diverse Gegenbeispiele geben, wo anderes Verhalten zu bevorzugen ist.

Hannes. Wobei das, was heute als "steile Lernkurve" bezeichnet wird, ja ehrlich gesagt auch alles tatsächlich zugängliche Hochsprachen sind. Selbst I6 ist ja sehr, sehr nahe an kanonischem Englisch, ...

Da stimme ich dir zu: Vieles bei den als komplex empfundenen Systemen ist auch nur "Formulare ausfüllen", wie bei den einfachen Systemen. Und man muss die Komplexität der Systeme nicht unbedingt ausreizen.

(Über die Zugänglichkeit von I6 sage ich aber mal lieber nichts.)

Du hast es gerade getan. Die Objektdefinitionen von I6 finde ich schon ziemlich intuitiv. Attribute, Aktionsoverrides – ergibt Sinn. Blöd ist die Aufteilung in Tokens ('') und Strings (""). Außerdem halte ich life für absoluten Unsinn, mag aber auch daran liegen, dass ich nie richtig verstanden habe, wann nun life und wann normales before greift.

Richtig schlimm finde ich I6, wenn es an die Umdefinition von tieferem Libraryverhalten geht. Also bspw. den Listenschreiber umzuschreiben.

Hannes: In diesem Sinne bin ich durchaus der Meinung, dass ein sanity check bzgl. Entwicklererwartungen auch immer mal wieder angebracht wäre.

Das verstehe ich, glaube ich, nicht ganz. Wer soll denn seine Erwartungen überprüfen ‒ Autoren ihre Erwartungen an vermeintlich einfache oder komplexe Systeme oder die Entwickler die Erwartungen an die Akzeptanz ihrer Systeme?

Gerne beide. Aber meine Aussage bezog sich schon auf die Spielautoren. Zu denken, man könne jemals einen Baukasten komplett vorgefertigter Bausteine haben, die man nur noch mit Prosa füllen muss, ist schlicht und einfach naiv. Von den typischen Softwareentwicklungsaufgaben wie dem Denken in variablen Zuständen, logischen Aktionsabfolgen, dem Vorsehen von vielen, vielen Alternativen und dem Abfangen/Implementieren „unerwünschten“ Verhalten wird man niemals wegkommen. Das kann kein Entwicklungssystem leisten, es ist rein logisch unmöglich.

Geschrieben um 15:19 am 20.12.2022 | Zitat | Editieren | Löschen
StefanH
Avatar
Mitglied
Bachelor Gumby
Beiträge: 51

Von den typischen Softwareentwicklungsaufgaben wie dem Denken in variablen Zuständen, logischen Aktionsabfolgen, dem Vorsehen von vielen, vielen Alternativen und dem Abfangen/Implementieren „unerwünschten“ Verhalten wird man niemals wegkommen.

Es ist ja - zumindest in manchen Fällen - noch viel schlimmer. Gerade grafische Programmiersysteme haben die recht unangenehme Angewohnheit, einen nach einem simplen und hoffnungsfrohen Start gnadenlos zu strangulieren, weil man plötzlich an Grenzen stößt. Technische Grenzen des verwendeten Systems, die Grenzen dessen, bis zu welcher Komplexität sich logische Zusammenhänge grafisch anschaulich darstellen lassen, etc.

Ein sinnvolles Einsatzgebiet für solche "Ich klicke mir mein Spiel zusammen"-Tools ist aber natürlich beim Rapid Prototyping. Da machts dann auch nicht mehr so viel, wenn ein Projekt an seine Grenzen stößt.

Geschrieben um 11:42 am 21.12.2022 | Zitat | Editieren | Löschen
biegomar
Mitglied
Pupil Gumby
Beiträge: 16

StefanH:

Was ist eigentlich aus Biegomirs System geworden? Ich fand jetzt den Konsolen-Ansatz nicht so attraktiv, aber da das Ganze .NET-based und in C# ist, hat mans ja nicht so weit zum Windows Desktop, zur App oder zum Browser.

Oh sorry, erst jetzt wahrgenommen...

Ja, die Entwicklung geht weiter und den neuen Beitrag zum Wettbewerb werde ich auch wieder mit Heretic umsetzen. Wie Martin geschrieben hat, ist das Repo frei verfügbar. Die aktuelle Entwicklung liegt aber in einem separaten Branch und der Plan ist, im Weihnachtsurlaub wieder eine neue Version zu veröffentlichen. Ich habe mich hier im Thread zurückgehalten, weil Heretic als One-Man-Privatvergnügen natürlich nicht mit den bestehenden Systemen konkurrieren kann. Natürlich ist in die Weiterentwicklung viel der geäußerten Kritik eingeflossen und ich schaue mal, wie es wird :)

Wen es interessiert: https://github.com/biegomar/Heretic.InteractiveFiction

Geschrieben um 17:06 am 22.12.2022 | Zitat | Editieren | Löschen
Martin
Avatar
Mitglied
Prof Gumby
Beiträge: 603

[Nur tragbare Objekte auflisten] Erzählerisch mag es diverse Gegenbeispiele geben, wo anderes Verhalten zu bevorzugen ist.

Das mag sein und man sollte es auch umsetzen können, aber ich denke die Voreinstellung, die man ohne Weiteres erzielt, sollte sein, wie ich es beschrieben habe.

Und auf die Gefahr hin, dass schon wieder nicht die gesamte Welt meine Vorlieben teilt: Ich sehe auch erzählerisch wenig Anlass, kunterbunte Listen wie "Du siehst hier eine leere Sardinenbüchse, Prinz William und ein Beistelltischchen" zu erzeugen.

Apropos Vorlieben: Ich habe natürlich so meine Vorstellungen, wie ein Textadventure aussehen sollte, aber diese Vorstellungen kommen ja nicht aus dem Nichts, sondern daher, dass ich mir schon das ein oder andere Spiel angeschaut habe und weiß, was (für mich) funktioniert hat und was mir gefallen hat.

[Inform 6] Blöd ist die Aufteilung in Tokens ('') und Strings ("").

Die Aufteilung hat schon ihren Sinn, weil die Z-Maschine (und auch die I6-Umsetzung in Glulx) diese beiden Arten von Strings unterscheidet: Einträge ins Wörterbuch ('schluessel') kommen ins Wörterbuch und werden auf neun Zeichen beschnitten. Ausgabetexte ("Kuckuck!") werden ans Ende der Spieldatei gepackt und im Z-Code intern als packed address abgelegt.

Inform 7 trifft diese Unterscheidung aus dem Kontext: Understand-Phrasen erzeugen Wörterbucheinträge, alles andere Ausgabetext. (Frühe Versionen von I6 haben das auch gemacht, und so kann man bei name und allem, was bei Verb definiert wird, beide Varianten benutzen, um Wörterbucheinträge zu erzeugen.)

Außerdem halte ich life für absoluten Unsinn, mag aber auch daran liegen, dass ich nie richtig verstanden habe, wann nun life und wann normales before greift.

Ja, life ist irgendwie Quatsch. Man kann aber alles, was man in life machen kann auch in before abfangen. Und man kann immerhin selbst Aktionen erzeugen, die life aufrufen, indem man in der Aktions-Routine RunLife aufruft.

(Ich schreibe "immerhin", weil es oft keinen allgemein gültigen Mechanismus gibt und viele Dinge fest im Parser verdrahtet sind. Das betrifft zum Beispiel einige fake actions, etwa ##LetGo und die vorgegebenen Verben mit topic, bei denen im Parser das jeweilige Objekt als Sonderfall mit einem Wörterbucheintrag belegt wird.

Dieses Klein-Klein, mit dem historisch bedingte Sonderfälle umgesetzt werden, macht Inform aus meiner Sicht nicht gerade sehr zugänglich. Hier fehlen übergeordnete, allgemein gültige Mechanismen. Ein Autor oder eine Autorin können in ihren Spielen ruhig Ad-hoc-Definitionen verwenden, aber in einer Bibliothek sind sie fehl am Platz.)

Von den typischen Softwareentwicklungsaufgaben wie dem Denken in variablen Zuständen, logischen Aktionsabfolgen, dem Vorsehen von vielen, vielen Alternativen und dem Abfangen/Implementieren "unerwünschten" Verhalten wird man niemals wegkommen. Das kann kein Entwicklungssystem leisten, es ist rein logisch unmöglich.

Vieles von dem, was Du aufzählst, ist ja nur im engeren Sinne Programmierung, also das womit einem ein Autorensystem helfen kann. Im weiteren Sinne ist es Spieldesign und damit sollte man sich natürlich schon befassen, wenn man ein Spiel schreibt.

Das Spieldesign, also das Planen der Erzählung und das Gestalten der Texte, sollte sogar im Vordergrund stehen. Deshalb ist es ideal, wenn man die einfachen Dinge in einem System leicht umsetzen kann.

Manchmal ist es aber sogar gut, wenn das System den Ideen des Autors im Wege steht, nämlich dann, wenn dieser etwas implementeren will, das den gängigen Konventionen entgegenläuft.

(Ich sehe übrigens hier Parallelen zu grafischen Benutzeroberflächen. Die Raumbeschreibung ist der Teil des Interfaces, der mir die Handlungsmöglichkeiten im Raum aufzeigt. Wenn da steht "Du siehst hier einen Stein", ist das eine Einladung, den Stein aufzuheben oder ihn zumindest zu untersuchen, genau wie ein breiter Fensterrahmen mich dazu einlädt, die Größe des Fensters zu ändern† oder ein Schieberegler dazu, ihn zu bewegen.

Und irgendwann fragt ein Newbie: Wie mache ich es, dass ich immer nur eine meiner Checkboxen anklicken kann? Und die Antwort, die vermutlich leicht mit jedem Toolkit umzusetzen ist, ist: Nimm keine Checkbox, sondern einen Radiobutton, denn das kennen die Benutzer. Die eckigen Dinger kann ich individuell ankreuzen. Von den runden Dingern kann immer nur eins in der Gruppe aktiv sein.

† Ich rede hier offensichtlich nicht von Windows 10.)

» Mehrere Seiten: 12345
AntwortenNeues ThemaNeue Umfrage
Powered by Spam Board SVN © 2007 - 2021
Impressum / Datenschutz