Modern Enterprise UI-ontwerp - Deel 1: Tabellen

Gedachten, patronen en oplossingen.

Ontwerpen voor ondernemingen is moeilijk. Waarom? Omdat Enterprise-software over het algemeen ingewikkeld is. U moet enorme hoeveelheden gegevens weergeven, door de gebruiker configureerbare UI's, complexe workflows, geautomatiseerde taken en nog veel meer. Ontwerpen voor al deze dingen kan een beetje een uitdaging zijn .

Als gevolg hiervan bieden sommige Enterprise-applicaties een slechte gebruikerservaring en zien ze er, uiteindelijk, een beetje saai uit.

Typische bedrijfstoepassing

Over een aantal berichten ga ik enkele veel voorkomende UI-patronen, problemen en mogelijke oplossingen voor bedrijfstoepassingen uitsplitsen.

Het is de moeite waard om erop te wijzen dat er geen maat past. De hieronder genoemde patronen en oplossingen zijn dingen die ik heb gevonden te werken, via iteratie, gebruikersfeedback en testen. Oplossingen moeten uiteraard worden afgestemd op uw toepassing en nog belangrijker op uw gebruikers. Er gaat niets boven praten met uw gebruikers en kijken hoe ze uw software gebruiken.

Laten we beginnen met tabellen

Bedrijfstoepassingen hebben te maken met enorme hoeveelheden gegevens en aangezien er geen betere manier is om (nog) geen significante hoeveelheid gegevens weer te geven dan een tabel, laten we daar beginnen.

Hierboven is een typisch voorbeeld van een tabel in een bedrijfstoepassing. Heerlijk is het niet. Laten we eens kijken hoe we de ervaring van complexe tabellen kunnen verbeteren en waar we rekening mee moeten houden wanneer we dit doen.

Hier zijn enkele vragen waarmee we rekening moeten houden bij het ontwerpen en bouwen van een gegevenstabel:

  • Welke apparaten worden gebruikt om de tabel te bekijken?
  • Hebben we controle over de gegevens die worden weergegeven of kunnen deze door de gebruiker worden geconfigureerd?
  • Hoe kunnen we de tabelgegevens snel scannen? - Als de tabel veel gegevens bevat, hoe kunnen we het gebruikers dan gemakkelijk maken de gegevens te vinden die ze nodig hebben?
  • Zullen rijen gedeelde acties hebben, zoals bewerken of verwijderen?
  • Kunnen tabelcellen veel gegevens, adressen of zelfs alinea's tekst bevatten?

Vergeet vooral niet om met uw gebruikers te praten, ontdek hoe zij de tabel zullen gebruiken en de gegevens die deze zullen presenteren.

Opmerking: voor de rest van dit bericht ga ik ervan uit dat we werken aan een webgebaseerde applicatie, hoewel de meeste van de onderstaande punten van toepassing zijn op elke bedrijfstoepassing ongeacht het platform.

Basics eerst

We beginnen met een eenvoudige tabel zonder stijl met fictieve klantdetails:

Tafel zonder stijl

Laten we eerst enkele basisstijlen toevoegen die een duidelijke scheiding van rijen bieden, de leesbaarheid bevorderen en enkele standaardbrowserstijlen verwijderen.

Gestileerde tafel

Het spreekt voor zich dat de tabel voor alle gebruikers toegankelijk moet zijn. Het gebruik van de juiste semantische markup is een must, zodat gebruikers van screenreaders cel voor cel door de tabel kunnen navigeren en kolom- en rijkoppen kunnen horen. Kolomkoppen moeten beschrijvend en relevant zijn. Tafelstijlen moeten voldoen aan WCAG 2 AA-contrastrichtlijnen (of zelfs AAA, afhankelijk van het vereiste compliantieniveau).

Responsieve tabellen

Gebruikers kunnen onze applicatie op elk apparaat bekijken, dus we moeten ervoor zorgen dat onze tafel bruikbaar is, of deze nu op mobiel, tablet of desktop wordt weergegeven.

Onze tafel op 375 px x 667 px (iPhone 7)

Op dit moment reageert onze tafel niet, dus deze ziet er niet fantastisch uit op apparaten met kleinere schermen. Responsive table design is een enorm onderwerp dat buiten het bereik van dit bericht valt. Laten we voor nu twee gemeenschappelijke benaderingen bekijken:

Samenvallende kolommen

Kolommen die over de breedte van het scherm lopen, zijn verborgen

Met dit patroon zijn alle kolommen die niet op het scherm passen verborgen. Ze kunnen door de gebruiker worden geschakeld om de verborgen gegevens weer te geven. U kunt nog een stap verder gaan door te definiëren welke kolommen prioriteit moeten krijgen bij verschillende viewport-breedten, zodat kritische kolommen nog steeds zichtbaar zijn op kleinere schermen.

Horizontaal schuivende tabellen

Horizontaal schuivende tafel

Misschien moeten gebruikers snel meerdere rijen vergelijken zonder te hoeven rondspringen met dingen uitbreiden? Een veel voorkomend patroon is om de tabel horizontaal op kleinere schermen te laten scrollen, zodat er geen verborgen kolommen meer nodig zijn. Overweeg beide patronen te gebruiken en geef een optie om tussen de twee te schakelen.

Veel gegevens verwerken

Op dit moment ziet onze tafel er goed uit, maar er zijn enkele problemen met de bruikbaarheid. Stel je voor dat we 10.000 rijen hadden, het vinden van een bepaald record zou een uitdaging kunnen zijn.

Paginering

Paginering in actie

Door paginering toe te voegen, kunnen we het aantal rijen per pagina beperken, waardoor de gegevens een beetje gemakkelijker te verwerken zijn. Hierboven gebruiken we tien rijen per pagina.

Pagineren heeft veel voordelen. Het maakt het gemakkelijker voor gebruikers om handmatig in de lijst te zoeken, geeft hen een gevoel van controle (in tegenstelling tot oneindig scrollen) en stelt gebruikers in staat om een ​​mentale notitie te houden van een rijenlocatie. Bij het gebruik van paginering moeten we de gebruiker het aantal items per pagina laten kiezen (idealiter zijn keuze voor de toekomst bewaren) en ook het totale aantal items in de lijst weergeven, en hoeveel er in beeld zijn.

Door gebruiker te definiëren paginering

Als u de gebruiker toestaat het aantal items per "pagina" te wijzigen, kan het eenvoudiger zijn bij het vergelijken van meerdere rijen dan mogelijk 1 of meer pagina's beslaan.

Het is ook de moeite waard om na te denken over de hoeveelheid gegevens die de tabel moet pagineren. Als we bijvoorbeeld tot 10 items per pagina pagineren, maar er zijn slechts 11 items, moet een gebruiker op Volgende klikken om de laatste rij te bekijken. Waarom niet programmatisch controleren of er, zeg meer dan 20 zijn en zo ja paginering inschakelen.

Trage voortgang

Meer rijen laden op aanvraag

Een ander veel voorkomend patroon, hetzij door een knop "meer laden" onder de tabel of door extra gegevens te laden wanneer de gebruiker naar de onderkant van de tabel schuift. Ik zou paginering hiervoor aanbevelen, voornamelijk voor de hierboven genoemde voordelen. Oneindig scrollen verwijdert enkele aspecten van gebruikersbeheer (wanneer eindigen de gegevens? Hoeveel records heb ik bekeken?). Het is meer geschikt voor apps die zich richten op gebruikers die een gegevensstroom gebruiken in plaats van een lijst met gegevens waarvoor meer gebruikerscontrole nodig is.

Aan tafel zoeken

Live zoeken van tabelgegevens

Een andere oplossing zou zijn om de tabelgegevens te filteren op specifieke zoekcriteria.

Sorteren op kolommen

Sorteren op kolom

Door gegevens op kolommen te sorteren, kunnen gebruikers vergelijkbare gegevens op kolomwaarden groeperen.

Deze patronen werken prima samen, filteren de tabel om relevante gegevens te tonen, zoeken naar fijne resultaten en sorteren de resultaten vervolgens op waarde.

Een samenvatting van gegevens verstrekken

Een visuele samenvatting geeft een overzicht van de bijbehorende tabel

Door een visuele samenvatting boven de tabel toe te voegen, kan de gebruiker de gegevens snel analyseren.

Ontwerpen voor het onbekende

In veel toepassingen is het heel goed mogelijk dat de tabelstructuur en de gegevens ervan door de gebruiker worden gedefinieerd, dus u weet misschien helemaal niet welke gegevens de tabel zullen vullen. Een goed ontworpen tafel zou hiervoor geschikt moeten zijn. Meestal biedt dit een aantal extra uitdagingen.

Kan de tabel zeer lange URL's of alinea's met tekst bevatten (adresgegevens, door de gebruiker ingediende berichten, formulierveldwaarden)? We hebben hier een aantal opties:

Lange tekst afkappen

Moet de gebruiker alle potentieel lange tekst voor elke rij tegelijkertijd bekijken? Het is onwaarschijnlijk. Een oplossing zou zijn om tekst af te korten op een lengte die nuttig genoeg is om de gebruiker een overzicht van de gegevens te geven en een methode te bieden om meer te bekijken, hetzij door te linken naar een andere pagina, meer inhoud te tonen binnen een modale of op een andere manier (we komen hier later op terug).

Wikkel lange touwtjes

Lange URL's kunnen mogelijk de lay-out van een responsieve tabel verbreken. We moeten ervoor zorgen dat alle koppelingen (of lange ononderbroken tekenreeksen) binnen een tabelcel correct worden verbroken om de tabelindeling niet te verbreken.

Rij acties

Gemeenschappelijke rijacties moeten worden gegroepeerd. Als het mogelijk is om deze acties tegelijkertijd op meerdere rijen uit te voeren, moet de actie worden verwijderd en als optie elders op de pagina worden toegevoegd (dicht bij de tabel). Natuurlijk hebben we een manier nodig om meerdere rijen te selecteren.

Acties op meerdere rijen tegelijk uitvoeren.

Tabelacties

Gemeenschappelijke tabelacties omvatten:

Tabelgegevens afdrukken

Laat de gebruiker alleen de tabel afdrukken en niet de omringende gebruikersinterface. Gebruik afdrukgerichte stijlen om de tafelstijl voor afdrukken te optimaliseren. Verwijder paginering tijdens het afdrukken om ervoor te zorgen dat alle tabelgegevens worden afgedrukt.

Tabelgegevens downloaden

Bijna alle hoofdgebruikers zullen de tabelgegevens willen downloaden in een standaardformaat (CSV, JSON, enz.) Om datamanipulatie in andere software mogelijk te maken. Als het bestand waarschijnlijk groot is, kunt u overwegen een zip-archief te gebruiken. Als het archief niet onmiddellijk beschikbaar is, stelt u de gebruiker hiervan op de hoogte en stuurt u een e-mail wanneer het klaar is om te downloaden.

Menu met acties op tabelniveau

In dit voorbeeld hebben we een vervolgkeuzemenu 'acties' boven de tabel gebruikt om tabelspecifieke acties toe te staan

Extra rijgegevens bekijken

Afhankelijk van het gebruik moet een gebruiker mogelijk snel toegang hebben tot aanvullende informatie over elke rij terwijl hij in context blijft. Dit kan op verschillende manieren worden bereikt.

modals

Extra rijgegevens bekijken in een modaal

Met modals kan de gebruiker op dezelfde pagina blijven als de tabel, maar wordt meer aandacht besteed aan de aanvullende informatie en eventuele acties die kunnen worden uitgevoerd.

Detailpaneel

Extra rijgegevens bekijken in een paneel

Afhankelijk van de situatie kan het zijn dat een modaal misschien niet de ideale oplossing is als u de gegevens onder het modale zichtbaar wilt houden. Een detailvenster dat naar de pagina schuift, is mogelijk een betere oplossing wanneer u de context behoudt en de gegevens in de tabel zichtbaar moet houden.

Slotgedachten

Er is vaak meer aan de bescheiden tafel dan op het eerste gezicht lijkt. Hopelijk helpen sommige van de hierboven genoemde punten u de volgende keer dat u een tafel komt ontwerpen.

De bovenstaande UI's zijn gebouwd met het Pulsar-ontwerpsysteem dat het grootste deel van deze functionaliteit levert aan het Jadu Continuum-platform.

Update: Deel 2 waarin modale dialogen worden bekeken, is nu live!