Session D-DRAG

Drag & Drop mit
Visual FoxPro

Dipl.-Psych. Wolfgang Schneider
Beratung für Softwareergonomie


EINLEITUNG

Was bedeutet eigentlich "Drag&Drop"?

Drag&Drop bedeutet z.B. das Bewegen von Daten (Objekten) oder das Kopieren-Bewegen von Daten (Objekten) innerhalb einer Anwendung oder zwischen Anwendungen auf bestimmte Zielobjekte.

Darüberhinaus können mit Drag&Drop auch weitere Funktionen aufgerufen werden, z.B. die Drucken-Funktion, indem eine Datei (oder ein Symbol davon) direkt auf den Drucker gezogen wird. Bestens bekannt ist auch die Papierkorb-Funktion. Die assoziierte Funktion mit Drag&Drop ist dann die Löschen-Funktion. Mit der Ausführung dieser Funktionen werden oft weitere Spezifizierungen der Funktionsausführung (in Popups) ermöglicht, z.B. die Druckreihenfolge oder die Druckerauswahl. Ergonomisch spricht man von einer Operand(Objekt)/Command/Option-Abfolge für Drag&Drop-Dialoge, was reichlich theoretisch ist.

In dieser Session wird deswegen das "übliche" Drag&Drop mit Bewegen/Kopieren-Bewegen von Daten oder Objekten ohne die Beschreibung von "weiteren" Funktionszuordnungen diskutiert.

Technisches Hilfsmittel ist meist ein Zeigeinstrument wie die Maus (seltener die Tastatur), mit der Objekte aufgenommen, bewegt und verschoben werden können. Dies wird im Ergonomiechargon "direkte Manipulation" genannt, Objekte werden direkt verändert/bewegt, wobei dies zeitgleich auf dem Bildschirm sichtbar ist.

Drag&Drop-Objekte können Originaldaten sein oder durch Symbole (Icons) repräsentiert werden. In jedem Fall sind beide immer sicht- und manipulierbar. Es kann sich ferner um alphanumerische Daten (zeichenorientierte Objekte) handeln oder um rein graphische Daten auf Pixelebene.

Der Zielort oder das Zielobjekt muß nicht unbedingt auf derselben Bildschirmseite liegen, sondern kann zu Beginn des Ziehvorgangs nicht sichtbar außerhalb des Bildschirms liegen.

Entscheidenster Konkurrenz-Dialog zu Drag&Drop ist Cut&Paste (oder Copy&Paste), wobei der erste eher einer Mausbedienung zugeordnet werden kann und der zweite eher der Tastaturbedienung. Die Geschichte von Drag&Drop hat ihren Usprung in der graphischen Bearbeitung von Daten/Objekten, also einer Aufgabenstellung, die hauptsächlich mit der Maus erledigt werden kann (oder sogar werden muß). Bei der graphischen Bearbeitung (auf Pixelebene) ist nämlich folgendes Kriterium vorrangig:

Es gibt sehr viele Möglichkeiten zur Plazierung von gezogenen Objekten, nämlich alle Pixel auf dem Bildschirm. Insofern ist eine freie Positionierbarkeit (als Arbeitsaufgabe) zum Ausprobieren/Durchführen von Objektpositionen entscheidend. Es ist sinnvoll, dies mit der Maus zu machen. Mit der Tastatur wäre eine Zielbestimmung viel umständlicher (allerdings ist sie zuweilen genauer).

Falls jedoch, wie bei der Verarbeitung von alphanumerischen Daten in Masken, ganz bestimmte Felder/Objekte als definierbare Zielorte vorhanden sind, kann man die Bewegung von Daten zu einem ganz bestimmten Zielort mit Cut&Paste einfacher gestalten (auch ein Button wäre denkbar - Daten/Objekte werden auf Knopfdruck routinemäßig von einem Feld ins andere geschaufelt).

Mit mindestens mehr als einem möglichen Zielort kann Drag&Drop jedoch schon sinnvoller werden als Cut&Paste. Allerdings bleibt dann noch die Frage, um welche Daten und um welchen Arbeitsvorgang es sich handelt, den es zu unterstützen gilt. Auch Drag&Drop ist nämlich nicht per se ergonomisch.

Mit anderen Worten, Drag&Drop lohnt sich besonders, wenn man viele Möglichkeiten hat, Daten zu plazieren (und es wird z.B. mit der Maus gearbeitet). In einer Text- oder Datenverarbeitung ist man manchmal schneller mit der Tastatur bzw. Cut&Paste, als erst mühsam die Maus zu suchen und das Mauskabel zwischen Kaffeetasse und Cola-Flasche zu entwirren, selbstverständlich nur, wenn die Navigation mit der Tastatur optimiert wurde. Wenn die Dialogwege für den Tastaturdialog zu lang werden (z.B. zu viele Tab-Tastendrücke), kann auf der anderen Seite ein Drag&Drop wesentlich schneller sein.

Zusammengefaßt:

Es gibt zu viele Trade-offs, um abschließend bewerten zu können, welche Methode wann die bessere ist. Drag&Drop ist jedoch im Zuge der allgemeinen Einführung objektorientierter Oberflächen eine hervorragende Methode, um viele Systemfunktionen in einer Anwendung zu bedienen. Drag&Drop wird somit in Zukunft die Arbeit wesentlich erleichtern.

Zum Abschluß sei gesagt, daß sowohl die Gestaltung der Graphik (Icons, Objektrepräsentationen) als auch der spezielle Anwendungsbereich in Usability-Tests abgesichert werden sollte. Mit Hilfe spezieller Ermittlungsverfahren mit dem Benutzer zusammen läßt sich in jedem Fall der Einsatzbereich von Drag&Drop ermitteln.


NAVIGATION BEIM DRAG&DROP

Die Navigation beim Ziehen sollte so einfach wie möglich gestaltet sein, d.h., das Ziehen muß einen entscheidenden Vorteil über der Cut&Paste-Funktion mit Hilfe der Tastatur besitzen. Neben der direkten Manipulation des markierten Objekts sollte eine häufige Mausbenutzung vorherrschend sein. Wenn es erforderlich ist, zu einem Ort zu ziehen, der zum Ziehbeginn nicht sichtbar ist, sollte das über einen definierten Bereich (z.B. über den Bildschirmrand) hinausgehende Ziehen eine Scroll- oder Blätteraktion hervorrufen.

Individuell einstellbares Scrollen (z.B. die Scrolleinheiten wie ganze Masken blättern oder Masken pixelweise scrollen) und/oder einstellbare Scrollgeschwindigkeiten (Wahrnehmbarkeit von Daten beim Scrollen) sind zur individuellen Gestaltung des Dialogs ntowendig.

Eine Unterscheidung der Geschwindigkeit der Scrollautomatik in Abhängigkeit von der Strecke, die mit dem Maus-Cursor über einen definierten Randbereich (z.B. Fenster, Liste) hinausgeht, ist sinnvoll (im folgenden wird vom Maus-Cursor als Pointer oder graphischer Mauszeiger ausgegangen, um Verwechslungen mit der FoxPro-Terminologie zu vermeiden). Das Scrollen selbst sollte aber immer zusätzlich mit einer Beschleunigungsfunktion verbunden sein.

Die Anfangsgeschwindigkeit sollte immer sehr gering sein. Der Beschleunigungsfaktor sollte individuell einrichtbar sein.

Der Randbereich sollte immer in gewissem Abstand zum Bildschirmrand selbst liegen, sonst verschwindet der Maus-Cursor. Eine Idee hierfür wären auch sogenannte Scrollfelder (z.B. Buttons zusätzlich zu der Bildlaufleiste), die automatisch immer dann auf dem Bildschirm erscheinen, wenn der Drag&Drop-Vorgang ausgelöst wird.

Es ist sehr sinnvoll, das Scrollen automatisch sofort dann zu stoppen, sobald das letzte Feld zum Fallenlassen der Daten auf dem Bildschirm erschienen ist.

Zusätzlich kann das Betätigen von Navigationselementen (Scrollbars z.B.) ermöglicht werden, sobald der Drag-Maus-Cursor über einen definierten Rand hinausgeht.

In diesem Fall wird der markierte und gezogene Datenbereich bis zum Scrollelement hingeführt, der Maus-Cursor ändert seine Gestalt auf dem Scrollelement, wobei der markierte Datenbereich auf dem Bildschirm stabil bleibt. Das Objekt wird in dem Fall nicht auf das Scrollelement fallengelassen (das Objekt ist entsprechend definiert). Nur die Scrollfunktion ist aktiviert.

Dies ist insofern sinnvoll, da bei einer vorausgehenden Maskenbearbeitung u.U. andere, für Drag&Drop unpassende Mauszeigergeschwindigkeiten eingestellt sind. Für das Ziehen über weite Bildschirmstrecken sind diese dann inadäquat. Oft ist schnell das Ende des Mauspads erreicht. Umständlich wäre das Einstellen der Mauszeigergeschwindigkeit vor jedem Ziehen über weite Strecken.

Eine weitere Idee ist das "Absetzen" der gezogenen Daten zwischendrin auf ganz bestimmten hierfür vorgesehenen Feldern auf dem Weg zum Zielort. Diese Felder erscheinen nur während des Drag&Drop-Vorgangs.

Es wäre gut, wenn das Ziehen auch ohne permanenten Druck auf eine Maustaste möglich ist (gewissermaßen durch einen On-Status, in dem die markierten Daten am Maus-Cursor festgemacht werden). Allerdings war bis zu diesem Zeitpunkt diese Funktion in Visual FoxPro (VFP) noch nicht abgeklärt.

Die Zielortbestimmung braucht dann nur noch durch das Bewegen der Maus vorgenommen zu werden. Dann wird erneut die Maustaste betätigt und auf den Ort geklickt, um die Daten/das Objekt fallen zu lassen (durch Maus-Select-Taste Up/Down).


DAS FALLENLASSEN

Bei Drag&Drop von Daten sollte per Default der Einfügemodus eingestellt sein.

Dies gilt hauptsächlich für Daten-Drag&Drop. Für Objekte gilt, daß andere Objekte durch das Einfügen von gezogenen Objekten nicht verschwinden oder gelöscht werden dürfen.

Dies sollte vermieden werden.

Folgende Einfügeprozesse sind denkbar: 1. die Einfügung, in der der ursprüngliche Zustand dees gezogenen Objekts nicht bestehen bleibt, 2. die Einfügung, in der der Zustand des gezogenen Objekts genau so übernommen wird, wie er am Ursprungsort vorhanden war.

Komplementär dazu: 3. Veränderung der "umgebenden" Daten/Objekte nach dem Fallenlassen des gezogenen Objekts (z.B. deren Anordnung), oder 4. keine Veränderung der Umgebung, jedoch eine Überlappung von "umgebenden" Objekten und gezogenen Objekten.

Zu 1. Dieser Einfügeprozeß ist hauptsächlich bei der Textverarbeitung oder alphanumerischen Eingaben der Fall. Die Anordnung oder der Zustand der ursprünglichen Daten (Objekte) kann nach dem Einfügeprozeß (Drop) verändert und angepaßt sein (z.B. kopierte Textstellen in anders formatierte Umgebungen). Aber auch bei graphischen Ziehvorgängen können prinzipiell diese Objekte in Abhängigkeit der umgebenden Objekte verändert werden.

Zu 2. Hier wird das gezogene Objekt haargenau so übernommen, wie es vor dem Ziehen angeordnet war. Dies ist hauptsächlich bei graphischen Ziehvorgängen so.

Zu 3. Die Anpassung der Umgebung oder Zielobjekte an das gezogene Objekt ist eher selten, kann aber bei der Übermittlung von Attributen oder Einstellungen sinnvoll sein, z.B. wenn es um das Übertragen von Textformaten geht oder der Zustand von Dateien.

Zu 4. Gar keine Veränderung der Umgebung wird sowohl bei graphischen Objekten wie auch bei alphanumerischen Objekten zwangsläufig zu graphisch-visuellen Überlappungen führen.

Daraus ergeben sich die vier Möglichkeiten:
Zustand gezogenes Objekt Zustand Umgebung /Zielbereich
verändert nicht verändert
verändert verändert
nicht verändert verändert
nicht verändert nicht verändert

Alle Möglichkeiten sollten, wenn sie vorkommen können, vom Benutzer erwartbar oder sogar einstellbar sein.

(Für diese Funktion siehe Solitärspiel in Windows).

Diese Funktion bietet sich an, wenn es bestimmte vordefinierte Felder (z.B. in Masken) mit nur einer reduzierten Anzahl von Zielorten gibt. Bei der Magnetfunktion wird die Positionierung zu einem bestimmten Ort automatisch vorgenommen, sobald der Maus-Cursor (mit dem Objekt) oder die markierten Daten sich in einer gewissen Entfernung zum vordefinierten Zielort (Anziehungsbereich) befinden.

Als Definition des Anziehungsbereichs kann man verschiedene Möglichkeiten nehmen: 1. die Hälfte der Strecke zwischen Ausgangs- und Zielort, wenn keine anderen Möglichkeiten in diesem Bereich liegen, ansonsten die geometrische Mitte zwischen verschiedenen möglichen Zielorten, 2. einen "Hof" um den Zielort, der aktiv wird, wenn das mitgezogene Objekt sich mit einem Bruchteil in diesem Hof befindet.

Dies ist besonders hilfreich, wenn die Anzahl der Zielorte gering ist oder wenn die Daten routinemäßig nur an einen bestimmten Ort gezogen werden müssen (was z.B. bei Solitär der Fall ist). Dies kann auch sinnvoll sein, wenn die Rasterung von Zielbereichen relativ grob ist.

Kompliziert ist oftmals der Ziehprozeß. Er erfordert eine sehr genau Auge-Hand-Abstimmung und natürlich die entsprechende Übung. Nicht jeder Benutzer kann dies auf Anhieb erlernen. Bei häufigen Ziehoperationen zu einem Zielort wäre es eine gute Idee, wenn man den Zielort automatisch durch dessen Speicherung ansteuern kann. Dies könnte man durch Ziehen mit der rechten Maustaste bewerkstelligen oder durch eine Tastenkombination.

Bei mehreren Routinezielorten kann man den Ziehweg eine bestimmte Strecke andeuten, dann die Maustaste frühzeitig los- und die Daten fallenlassen. Der Einzugsbereich des "Schwarzen Lochs" als Zielort wird somit größer und differenzierter. Der markierte Datenbereich kann dann animiert automatisch zum Zielort gezogen werden.

Eine weitere Idee wäre auch das "Nachspielen" des Ziehens, denn in einem Text mit großem Umfang kann man u.U. nicht mehr nachvollziehen, wo man seine Daten hergenommen hat und wo man sie fallengelassen hat. Eine animierte graphische Kennzeichnung beider Orte einschließlich des ganzen Ziehvorgangs auf dem Bildschirm würde helfen.

Eine zusätzliche Einfügehilfe (oder -marke) in Gestalt eines weiteren Pointers oder Cursors, der automatisch zu den diversen Zielorten springt, ist sinnvoll, wenn die Auswahl der Zielorte begrenzt ist (was bei Feldern einer Maske der Fall ist). Dies erleichtert die Ansteuerung des Zielortes (z.B. den Anfang von Feldern einer Maske).

Die Einfügemarke springt weiter, sobald der Drag-Maus-Cursor (ergonomisch: Pointer) über die Einfügemarke (Drop-Maus-Cursor) (bis zu einem definierten Bereich) hinausgezogen wurde.

Auch das Highlighting des Zielobjekts/Zielorts bildet eine wichtige Rückmeldung. Dies kann z.B. mit einer zusätzlichen Umrahmung realisiert werden, sobald man sich im definierten Bereich um das Objekt befindet.


GRAPHISCHE REALISATION

Die Orte, an denen die Daten fallengelassen werden können, sollten für den Benutzer visuell durch deren graphische Kennzeichnung (Farbe) oder logisch durch eine andere erwartungskonforme Gestaltung schon vor Erreichen des Zielortes (!) erkennbar sein. Eine zusätzliche Methode ist die Änderung des Cursors über verbotenen Feldern. Jedoch sollte es dem Benutzer nicht zugemutet werden, über jedes verbotene Feld zu ziehen, um herauszufinden, wo er denn seine Objekte fallenlassen kann.

Hier gibt es 5 Möglichkeiten:

Welche Rückmeldung letztendlich gewählt wird, hängt von den Systemresourcen, der erforderlichen Genauigkeit der Mauszeigoperation und der erwartungskonformen Gestaltung des Dialogs für den Benutzer ab. So dürfte Punkt 4 der ergonomischen Idealvorstellung am nächsten kommen. Es ist immer sinnvoll, eine graphisch veränderte Form der "zurückgebliebenen" markierten Objektstelle mit dem eigentlichen Objekt darzustellen. Dies kann auch bei den anderen Punkten berücksichtigt werden.

Die bereits weggezogenen Daten sollten in ihrer ursrünglichen Position angedeutet bleiben, um eine "Erinnerung" daran zu haben, wo sie sich befanden (noch befinden). Dies dient zur Indikation des Ausgangsorts.

Falls in einen anderen Bereich gezogen wird, d.h., bei weiten Ziehstrecken oder wenn die zurückgebliebenen Daten nicht mehr sichtbar sein sollten, dann wäre es einge gute Idee, in einem zusätzlichen Fenster die aktuelle Position (graphisch) und den gezogenen Weg visuell anzudeuten (z.B. unüblich durch eine Linie).

Der Ziehmodus, der durch das Drücken der Maustaste eingeschaltet wird, sollte dem Benutzer immer zurückgemeldet werden. Der Zeitbereich für das Einschalten sollte vom Benutzer frei definierbar sein.

Wenn man auf den markierten Bereich klickt, um diesen wegzuziehen, dann verändert der Maus-Cursor seine Form (zur Signalisierung der Ziehbereitschaft) und nimmt die Daten an der geklickten Stelle innerhalb der Markierung mit. In diesem Fall kann - wie oben schon besprochen - auch eine Einfügehilfe mit der Positionsanzeige der Dropstelle bereitgestellt werden, besonders wenn der Zielbereich grob aufgeteilt ist (z.B. der Anfang eines Feldes).

Der Einfügepunkt des Pointers (Hot Spot) kann, wenn das ganze Objekt mitgezogen wird, durch das selbige schwerer definiert werden (siehe das Solitär-Beispiel, in dem ganze Karten mitgezogen werden). Die Einfügehilfe ist dann "durch den markierten Bereich hindurch" sichtbar oder die Rasterung des Zielortbereichs ist groß und verknüpft mit einer Magnetfunktion (s. unten oder Solitär in Windows).

Je nach Datenoperation (Kopieren-Bewegen oder Bewegen) ändert der Maus-Cursor zudem seine Form zur Rückmeldung der Operationsart.


DIVERSES

Eine Undo-Funktion ist für das Drag&Drop wichtig, bei der zumindest der zuletzt gemachte Schritt (auch die Markierung gezogener Objekte) rückgängig gemacht und wiederhergestellt werden kann (Redo!).

Die Ebene der Dialogschritte für die Undo-Funktion ist zu überlegen, z.B. sollen Markierungsaktionen rückgängig gemacht werden können oder nur der ganze Verschiebe-/Kopierprozeß.

Die Markierung des gezogenen Objekts sollte nicht gleich nach dem Einfügen von Daten verschwinden (falls sie gleich nach dem Fallenlassen der Daten automatisch verschwindet, sollte sie wiederherstellbar sein), damit eine testweise Positionierung zu verschiedenen Zielorten und das Wiederaufnehmen des Objekts erleichtert wird.

Beim Drag&Drop von graphischen Objekten sollte eine bestimmte Folge von Operationen eingerichtet sein. Erst sollte das Objekt auswählbar sein, danach sollten Operationen wie Drucken/Löschen bestimmt werden können (z.B. durch das Ziehen auf einen Papierkorb oder einen Löschbutton), und drittens eventuelle Optionen (z.B. für eine Druckfunktion welcher Drucker, welche Qualität etc.) einstellbar sein.

Dies betrifft hauptsächlich andere zugeordnete Funktionen als Bewegen/Kopieren-Bewegen von Objekten.

Das Bewegen eines markierten Texts mit Hilfe der Tastatur sollte auch in graphischen Anwendungen möglich sein, um eine hohe Präzision der Zielortbestimmung und Plazierung der gezogenen Objekte zu erlauben. Nach Einschalten des Drag-Vorgangs sollte per Cursortasten ein Ansteuerung des Ziels möglich sein (entweder das Objekt selbst oder die Einfügemarke). Dies konnte mit VFP zu diesem Zeitpunkt noch ausprobiert werden. Auch ein Einschalten der Drag&Drop-Funktion via Tastatur wäre denkbar, um so nur noch die Maus ohne Tastendruck bewegen zu können.