it-swarm.com.de

Wie finde ich das beste Symbol für ein Konzept?

Ich entwickle eine visuelle Programmiersprache und nach dem Lesen von dieses Papier sieht es so aus, als wären Symbole eine sehr gute Lösung, um die Sprache zu verbessern und das Verständnis zu verbessern. Da ich Programmierer und kein UI-Designer bin, kann ich (jetzt) ​​kaum darüber nachdenken, wie ich Symbole auswählen kann, die die Semantik meiner Programmiersprache vermitteln.

In meiner Sprache bedeutet beispielsweise ein Objekt (dargestellt durch ein Rechteck), das mit einem Prozess (dargestellt durch eine Ellipse) mit einer Verknüpfung verbunden ist, die mit einem offenen Kreis endet, dass der Prozess das Objekt als Werkzeug verwendet und es nicht ändert (siehe Bild unten):

enter image description here

Aber welches Symbol soll ich anstelle des offenen Kreises verwenden? ein Werkzeug? ein Buch (schreibgeschützt)? ein Griff einer Maschine? Und natürlich ist dies nicht der einzige Link, der in der Sprache verwendet werden kann. Ich möchte auch Symbole zu Objekten hinzufügen, die Argumente und ähnliches sind.

Alle Fragen mit der Frage "Was ist das beste Symbol für XXX?" Werden geschlossen, da sie zu spezifisch sind. Meine Frage lautet daher: Wie wähle ich das zu verwendende Symbol aus? Gibt es Bücher/Papiere/Tutorials, die ich zu diesem Thema lesen kann?

6
vainolo

Die kurze Antwort besteht darin, dass einige von Ihnen einige Ideen erarbeiten und dann iterative Tests an echten Benutzern verwenden, um die Auswahl einzugrenzen und zu verfeinern. Weitere Informationen finden Sie unter Wie erstellen oder wählen Sie ein Symbol für eine Funktion aus? .

Bedenken Sie jedoch, dass die "Wahrnehmungsähnlichkeiten", die Symbole bieten, für Sie möglicherweise nicht so wichtig sind wie andere Überlegungen, einschließlich derer, die Moody in dem von Ihnen zitierten Artikel erörtert. Diese anderen Überlegungen können mit dem Erreichen eindrucksvoller Symbole konkurrieren:

  • Diskriminierung. Die eindrucksvollsten Symbole für zwei unterschiedliche Konzepte sehen möglicherweise ähnlich aus, was zu Verwirrung führt.

  • Unordnung. Symbole müssen häufig groß und detailliert sein, damit Benutzer erkennen, was sie hervorrufen sollen. Dies kann jedoch zu großen, visuell überfüllten Diagrammen führen, die schwer zu lesen sind.

  • Beschriftungsraum. Mit einfachen Umrisssymbolen können Sie ihre Beschriftung innerhalb ihrer Grenzen platzieren, wodurch die Beschriftung eindeutig wird. Symbole können mit Details gefüllt sein, die Sie dazu zwingen, Etiketten daneben zu platzieren. In dichten Diagrammen kann unklar werden, was was kennzeichnet.

  • Ausdruckskraft. Mit einfachen Formen können Sie andere grafische Abmessungen (z. B. Schatten, Muster) verwenden, um zusätzliche Informationen zu codieren. Eine solche Codierung kann für Symbole ungeeignet sein; Zum Beispiel muss ein Radiergummi rosa oder weiß sein, um erkennbar zu sein. Dies bedeutet jedoch, dass Sie möglicherweise keine Farbcodierung (blau, grün usw.) verwenden können.

Bedenken Sie, dass jeder Grad an Wahrnehmungsähnlichkeit, den Ihre Symbole hervorrufen, wahrscheinlich bestenfalls bescheiden ist, da sich die abstrakten Konzepte, die Sie in der visuellen Programmierung haben, nicht gut visualisieren lassen. Denken Sie auch daran, dass Sie relativ wenige Symbole haben sollten und Anfängern einen einfachen Zugriff auf eine Legende oder einen Schlüssel ermöglichen können, sodass das Lernen auch mit beliebigen Symbolen schnell sein sollte. Insgesamt sind Sie mit einfachen Formen möglicherweise besser dran als mit Symbolen.

Oder vielleicht haben Sie beides: Standardmäßig und für Anfänger verwenden Sie (große und überfüllte) Symbole, damit sie leicht zu erlernen und für die einfachen Programme geeignet sind, mit denen ein Anfänger wahrscheinlich beginnen wird. Ermöglichen Sie dem Benutzer, die Symbole global zu ähnlichen Formen zu vereinfachen, sobald sie gelernt sind und der Benutzer für komplexere Programme bereit ist. Zum Beispiel kann ein Prozess durch ein Zahnrad dargestellt werden, das bei Vereinfachung zu einem Kreis wird. Eine Objekteigenschaft ist eine Schublade, die bei Vereinfachung zu einem Rechteck wird. Vielleicht sollten Sie zuerst die einfachen Formen auswählen , um Ihre anderen Überlegungen zu erfüllen, und dann rückwärts arbeiten, um sie zu eindrucksvollen Symbolen für Anfänger zu machen.

3

Anscheinend suchen Sie nicht nach Symbolen, sondern nach Symbolen . Es gibt einen grundlegenden Unterschied (siehe http://www.iicm.tugraz.at/thesis/ahollosi_html/node6.html ) und wenn Sie diesen Unterschied verstehen, haben Sie Ihr Problem bereits zur Hälfte gelöst.

Sie verwenden eine Ellipse als Prozess, ein Rechteck als Objekt, ... mit anderen Worten: Sie verwenden bereits Symbole, suchen Sie also jetzt nicht nach Symbolen.

Entweder sollten Sie eine eigene Symbolsprache erstellen, ähnlich wie UML, oder Sie können einen vorhandenen Satz von Symbolen wie Flussdiagrammsymbole verwenden. Oder Sie gehen von einer bestimmten vorhandenen Basis aus und fügen zusätzlich Ihre eigenen Symbole hinzu. In diesem Fall können Sie Ihren offenen Kreis perfekt verwenden, solange Sie ihm eine klare Bedeutung geben, die auf verschiedene Weise vorzuziehen ist. Werden die Symbole aus einer Palette ziehbar sein? In diesem Fall müssen die Symbole auf der Palette gut beschrieben sein, z. B.: Nur-Lese-Verbindung/Lese-/Schreibverbindung/Prozess/Objekt/... Was passiert, wenn Sie auf eine Verbindung klicken? Können Sie irgendwo einige Immobilien sehen? Kann ein Benutzer die Eigenschaften einer vorhandenen Verbindung ändern? Grundsätzlich sollten Sie sich Rational Rose ansehen und wie sie mit Verbindungen umgehen, wie "hat ein", "abgeleitet von", ...

Wenn Sie wirklich nach einem Symbol suchen, das "schreibgeschützt" anzeigt (was ich bezweifle), ist das erste, was mir in den Sinn kommt, ein Bleistift mit einem Kreuz darüber oder ein Schloss.

3
Bart Gijssens

Sie sollten darüber nachdenken, welches Symbol ein Objekt oder vielleicht ein Datensegment darstellt und welches Symbol einen Prozess oder vielleicht eine Aktion darstellt.

Die Antwort kann von Ihren Benutzern abhängen:

  • Wenn es sich um Programmierer handelt, werden sie an Konventionen von UML und IDEs verwendet (z. B. Rechtecke für Klassen, Blitz für Ereignisse).

  • Wenn sie keine Programmierer sind (und möglicherweise auch nicht), dauert es weniger lange, bis sie verstehen, wenn Sie an Äquivalente außerhalb der Softwarewelt denken (z. B. einen Satz mechanischer Räder, ein Rohr oder eine Lupe für einen Prozess) , ein Paket oder ein Buch für ein Objekt). Versuchen Sie, ein Paar zu finden, das im wirklichen Leben zusammenpassen kann, und verwenden Sie es.

Wenn Ihre Benutzer aus einer bestimmten Domain stammen, versuchen Sie, Entsprechungen aus ihrer Domain zu finden.
Z.B. Wenn es sich um Programmierer handelt, können Sie Entsprechungen aus der Welt der Computerhardware verwenden (z. B. eine CPU und eine Datei).

Versuchen Sie, einige Alternativen in einem einfachen, aber realistischen Beispiel eines Szenarios zu skizzieren und verschiedene Personen zu fragen, was sie aus dem Bild verstehen (ohne vorher Informationen zu geben, sollten Sie möglicherweise jeder Person ein Bild zeigen, um ein akkumuliertes Verständnis zu verhindern).

0
Danny Varod