it-swarm-eu.dev

Entwerfen eines fließenden Farbbands für eine CRUD-Anwendung

Ich arbeite daran, eine UX im Fluent-Stil ("Ribbon") für eine CRUD-Anwendung zu entwerfen, die über eine Datenbank arbeitet.

Es gibt viele Informationen zum Entwerfen eines Menübands für dokumentbasierte Anwendungen. Die Microsoft-Richtlinien geben sogar Standardregisterkarten und -gruppen an.

Diese Standardgruppen scheinen jedoch nicht gut für Situationen ohne Dokument geeignet zu sein. Der Befehl "Suchen" sollte sich beispielsweise in einer Gruppe "Bearbeiten" befinden:

alt text

Völlig relevant für die Suche innerhalb eines Dokuments, aber nicht für die Suche für einen Datensatz.

Welche Ressourcen und/oder Beispiele gibt es für die Verwendung des Menübands für Anwendungen ohne Dokument?

Aktualisiert 27/9 : Ja, ich bin sicher, dass ein Menüband für die von mir entwickelte Anwendung geeignet ist. Es ist nicht dokumentenorientiert, aber auch nicht rein CRUD - es ist eine komplexe Anwendung mit viel Geschäftsverhalten. Es wird für mich einfacher sein, einen Workshop zum Anordnen des Bandes durchzuführen, wenn ich im Voraus eine Anleitung geben kann. Ich hoffe daher auf einige Antworten auf meine ursprüngliche Frage zu Ressourcen und Beispielen.

14
Bevan

Ich denke, das beste Beispiel, das Sie sich ansehen können, ist MS Access. Alle CRUD-Befehle befinden sich in einer Records Gruppe und der Find-Befehl befindet sich in der Find Gruppe!

alt text

14
Tania Gobeil

Das Menüband wurde für Programme mit vielen Befehlen entwickelt. Die CRUD-Anwendung verfügt in der Regel nur über wenige Befehle. Daher ist das Menüband möglicherweise nicht die richtige Benutzeroberfläche.

Sie können das tun, was MS getan hat, als sie das Menüband entworfen haben. Nehmen Sie so viele Personen wie möglich (die das Feld kennen, vorzugsweise Kunden). Geben Sie dann eine Liste mit Registerkarten/Gruppen und einige Befehle und lassen Sie sie den logischsten Ort für das auswählen Befehl.

Und was am wichtigsten ist: Befolgen Sie die Richtlinien nicht blind (aber ignorieren Sie sie auch nicht ohne guten Grund) und verwechseln Sie Ihre persönlichen Vorlieben nicht mit dem, was die Benutzer intuitiv finden.

11
Nir

Ich bin fast in der gleichen Situation wie Sie mit meiner Anwendung und dem Entwerfen einer "Ribbon" -Schnittstelle. Ich habe eine Situation in Betracht gezogen, in der ich Befehle in der Multifunktionsleiste basierend auf dem Kernobjekt "Geschäft" gruppiere. Mit anderen Worten, wenn meine App es Benutzern ermöglicht, Clients und Anbieter zu verwalten, wäre es sinnvoll, eine Multifunktionsleistengruppe für Clients mit allen Befehlen zu haben, die Sie üblicherweise aufrufen, und dann eine weitere Multifunktionsleistengruppe für Anbieter mit den verschiedenen Befehlen Sinn, gegen diese Objekte\Datensätze zu laufen?

Als ich dies skizzierte, wurde (zumindest für mich) klar, dass die Bildschirmverwaltung mit diesem Stil sehr schwierig werden würde, wenn ich nur ein einziges Menüband bereitstellen würde und die Benutzer wahrscheinlich mehr frustrieren als helfen würde.

Die beste Benutzeroberfläche, auf die ich gestoßen bin und die sich zumindest tangential mit diesem Problem befasst, ist die Outlook 2010-Benutzeroberfläche. Outlook basiert auf einem separaten Navigationselement. Wenn Sie jedoch beispielsweise von Nachrichten zu Kontakten wechseln, wird die Multifunktionsleiste geändert, um die unterstützten Befehle für die Schnittstelle anzuzeigen, mit der Sie gerade arbeiten.

Wenn Sie es auf Ihr Beispiel zurückführen, scheint das Finden eines bestimmten Datensatzes zu bedeuten, dass der Benutzer den Typ des gesuchten Datensatzes kennt. Es kann sinnvoll sein, zuerst ein Navigationssystem einzurichten, damit der Benutzer zum Kernobjekt (z. B. Kundenansicht) navigieren und dann eine Reihe von Befehlen in der Multifunktionsleiste anzeigen kann, die sich ausschließlich auf Kunden beziehen. Die Suche befindet sich zwar in der Gruppe "Bearbeiten", ihr Kontext bezieht sich jedoch nur auf die Kundenansicht. Möglicherweise befindet sich in einer Bearbeitungsgruppe auch ein anderer Suchbefehl, der sich auf eine andere Entität in der Anwendung bezieht.

3
Tim Lentine

Ich habe auch darüber nachgedacht, und die Hauptidee, die ich mir ausgedacht habe, ähnelt der von Tim Lentine beschriebenen: Für jedes meiner Hauptgeschäftsobjekte eine Registerkarte zu haben. Ich habe beispielsweise die am häufigsten ausgeführten Befehle für dieses Objekt in die Registerkarte eingefügt, und das Objekt "Bestellen" verfügt möglicherweise über Befehle zum Ändern des Status (z. B. Stornieren, Versenden usw.), Abrechnen, Senden von Rechnungen usw.

Ich habe jedoch auch darüber nachgedacht, wie das Menüband in der Windows Live-Fotogalerie funktioniert. In gewisser Weise verwaltet es eine Datenbank (mit Fotos und Metadaten). Von besonderem Interesse waren die Registerkarten Start, Suchen und Anzeigen. Mir hat auch die Idee des Such-/Filterfelds gefallen, das angezeigt wird.

photo gallery ribbon

Das sind also die beiden Hauptideen für eine CRUD-Anwendung, über die ich nachgedacht habe. Ich habe aber noch nichts entschieden.

In Anlehnung an die Fotogalerie kann ich eine Registerkarte zum Abrufen einer bestimmten Liste von Daten und zum Löschen usw. erstellen (ich wollte, dass im Hauptfenster meines Fensters eine Liste von Objekten angezeigt wird). Möglicherweise habe ich eine andere zum Filtern/Gruppieren (ähnlich der Registerkarte "Ansicht" von WLPG). Ich hätte wahrscheinlich eine andere Registerkarte für Berichte. Ich kann auch kontextbezogene Registerkarten verwenden, um allgemeine Befehle für das ausgewählte Objekt auszuführen, wie im ersten Absatz beschrieben.

2
Benny Jobigan

Ich habe keine umfangreiche Erfahrung in einer CRUD-App mit einem Band, aber hier sind einige Ideen ...

Lesen - Lassen Sie eine oder mehrere Registerkarten den Standardmethoden zuordnen, mit denen ein Benutzer die bestimmten Objekte finden würde. Wenn es sich beispielsweise um eine College-Datenbank handelt, eine Registerkarte für Studenten/Fakultäten, eine für Klassen und eine für Gebäude. Gruppieren Sie die Objekte in den Registerkarten nach feineren Ebenen, z. B. eine für Schüler und eine für Mitarbeiter. Wenn es sich um eine einfache Feldabfrage handelt, können Sie das Nur-Text-Steuerelement direkt einfügen oder den komplexen Suchdialog öffnen.

Erstellen - nur eine Registerkarte zum Löschen haben oder in die gelesenen Registerkarten einfügen. Wenn Sie eine separate Registerkarte zum Erstellen erstellen, ordnen Sie die Gruppen den Registerkarten zu und fügen Sie Trennzeichen hinzu, um Minigruppen zu erstellen.

pdate - Ich würde ernsthaft kontextbezogene Registerkarten in Betracht ziehen. Ein Kontext pro Objekttyp. Wenn ein Formular mehrere Typen hat, müssen Sie den Kontext über den Tastaturfokus steuern. Nicht so viel Spaß. Möglicherweise möchten Sie diese Aktualisierungsaufgaben auch in den Formularen selbst, insbesondere wenn sie den Befehlsoptionen des Dialogfelds wie "Anwenden" und dergleichen gut zugeordnet sind.

Löschen - Im Befehl gut vergraben, nicht standardmäßig auf dem Menüband. Von der Zerstörung von Daten ist abzuraten. Ermutigen Sie den Benutzer stattdessen, Daten zu archivieren, zu verwerfen oder zu graduieren, damit sie nur in bestimmten Abfragen angezeigt werden. Und diese Aktionen sind im Allgemeinen objektspezifisch, sodass sie entweder in den Formularen oder in den Kontextregistern gespeichert werden. Lassen Sie die wöchentlichen Sicherungs-, Archivierungs- und Wartungsaufgaben löschen.

0
shemnon