Tabeller på interne flater

[Lilyngs]

Med utgangspunkt i tabellene som Eirik har publisert har vi sett på noen designtilpasninger for tabeller, da interne flater/ekspertsystemer har behov for mindre høyde. Har feks designet 2 varianter, én på 32px høyde og én på 40px høyde. Et par spørsmål:

Bør høyden justere seg etter komponentene som er plassert i "cellene". Eller kan man bruke faste høyder med inputfelter som er mindre.

Er det viktig at høyden er målt i de avstander vi har i systemet?

Jeg trenger innspill, og eller innsikt som allerede er gjort, om mulig :)

Foreløpige skisser: https://share.goabstract.com/90b8ee53-5dd5-40b6-bf06-fd903f5a1394

[Lillebo]

Som nevnt så vil høyden i tabell-celler/rader alltid tilpasse seg etter hvilket innhold de får. Det er nok mer hensiktsmessig å snakke om variabel intern padding i stedet for faste høyder her. Da vil det være en kombinasjon av intern celle-padding og høyden på elementene som skal bo i cellene som utgjør den totale høyden på radene.

Jeg lurer derfor på om dere ikke heller burde begynne å se på hvilke størrelser vi kan tillate på disse elementene som skal bo i tabell-radene først - da dette vil legge store føringer for hvor store tabell-radene også må bli.

Som vi har diskutert før så håper jeg det da tas med i disse betraktningene at det finnes gode retninglinjer og anbefalinger på hvor små slike elementer kan være. Ser f.eks. at du opererer med knapper helt ned i 16px:

Bør minne om at slike størrelser vil være et ganske stort steg unna de minimumsmålene som Google opererer med - for ikke å snakke om WCAG. For selv om 2.5.5 er et AAA-krav så er vi såklart ikke fritatt fra å gjøre slike hensyn overhodet. Som W3 sier:

The intent of this success criteria is to ensure that target sizes are large enough for users to easily activate them, even if the user is accessing content on a small handheld touch screen device, has limited dexterity, or has trouble activating small targets for other reasons. For instance, mice and similar pointing devices can be hard to use for these users, and a larger target will help them activate the target.

Om vi da skal vurdere å bryte med alle disse anbefalingene så mener jeg det bør foreligge omfattende og overveldende dokumentasjon på at det virkelig er nødvendig for å bygge gode internsystemer. Jeg må innrømme at jeg er litt skeptisk til det.

Forøvrig synes jeg det hadde vært veldig synd om vi tillater at det etableres en praksis hvor vi alltid legger tilgjengelighets-lista på det som er definert som minimum 😕

[Lilyngs]

Ikonene på 16px er hentet fra placeholder-størrelse vi har i sketch-biblioteket. Derfor de er brukt, men burde helt sikkert vært noe større. Om et ikon er 20x20px kan trykkflaten feks være større?

Ellers lurer jeg på inputfelt, idag har vi 40px. Kan de være mindre enn dette, som eks 30px eller 32px.

En tabell på en hovedstørrelse 32px høyde, vil regnestykket se slik ut: 8+22+7+1 = 32px (padding+tekst med line height + padding + border) 8+32+7+1 = 48px (padding+ inputfelt + padding + border)

Er dette størrelser vi kan tilpasse for saksbehandlersystemer, der plassen er viktig å designe "tettere", tror du :)

[Lillebo]

Aha, må innrømme jeg er litt usikker på hva som ligger i Sketch-biblioteket, og hvor mye av det som egentlig gjelder - men ser hva du mener. Litt usikker på hva som menes med "placeholder" her også, men jeg tror ikke disse er ment å skulle være klikkbar :thinking:

Uansett er det ikke nødvendigvis noe problem om selve ikonet er bare 16px stort, det er heller klikkflaten og den "synlige" knappen som er avgjørende her. Så hvis vi kan bli enige om at disse kan være litt større så hadde det vært fint 🙂

Jeg tenker også at 32px er et bra mål for "tette/trange" versjoner av input-feltene våre. Noe mindre enn det så blir vi nødt til å gå ned i font-størrelse - noe jeg veldig gjerne vil unngå. Denne størrelsen er også innenfor anbefalingene fra Google samtidig som det ikke er et alt for stort brudd med WCAG sine anbefalinger. Føler det er et greit nok kompromiss mellom tilgjengelighet og behovet for informasjonstetthet her.

I så fall bør vi også forsøke å begrense oss til samme minimum-størrelse på knapper, da disse elementene er ment å kunne alignes horisontalt:

Da unngår vi også å etablere så veldig mange forskjellige størrelser på disse elementene - som alle må vedlikeholdes.

Hvis vi da også lager en "tett/trang" versjon av tabell med halvparten så stort intern padding - slik du foreslår - så vil minimal høyde på tabell-radene i disse bli:

8 + 22 + 8 + 1 = 39px (tekst) 8 + 32 + 8 + 1 = 49px (inputs/knapper)

I motsetning til "stor/normal" versjon:

16 + 22 + 16 + 1 = 55px (tekst) 16 + 40 + 16 + 1 = 73px (inputs/knapper)

[Lilyngs]

Det ser fint ut Eirik. Jeg jobbet akkurat nå på én versjon som ligner. Men at man ender opp med 40px høyde og 48. Forskjellen er at border-streken kommer innenfor høyden. Dvs at teksten kommer 1px ned i celle-feltet. Ser IBM har gjort det slik. Og da kunne vi holdt oss innenfor avstandssystemet vårt?

[Lilyngs]

I forhold til ikoner må vi skille på Illustrerte ikoner og klikkbare ikoner. Og sikkert andre hensyn. Jeg kommer til å jobbe litt med retningslinjene der :) Men absolutt enig at de ikke må bli for små altså :)

[Lilyngs]

32 på inputfelt er supert. Ikke behov for å gjøre de mindre. Skulle man evt tilby en tabell som er mindre enn 40px i høyde. Kan det være en "lese-tabell" der man ikke bruker funksjonalitet som inputfelt eller annet. Noen ganger kan det være veldig effektivt å samle data på en mindre flate-plass.

[Lillebo]

Padding tabeller Skjønner hva du tenker, men tror ikke vi skal henge oss så mye opp i at tabell-radene må gå opp i avstandssystemet her. En tabell-rad med tekst som går over 2 eller flere linjer (22*N) vil likevel ikke gå opp i dette systemet da 2 linjer blir 44px, 3 = 66 osv. Det er nok mye ryddigere å bare bruke samme padding over og under - så slipper vi å risikere at innholdet fremstår litt "feiljustert" også.

Ikoner Ja, her snakker jeg kun om interaktive ikoner såklart 🙂 Viktig å være klar over at klikkbart ikon = knapp her.

Andre tabeller Ja, vi kan gjerne tilby flere typer tabeller 👍 Ser f.eks. at Altinn har en egen tabell-komponent for regnestykker som jeg liker veldig godt: https://altinn.github.io/designsystem-styleguide/komponenter/tabeller/

[Lilyngs]

Den var veldig fin fra Altinn!

Når det gjelder padding er jeg for så vidt enig, at man holder seg til lik avstand over og under, men vi er kun 1 pixel fra avtanssystemet, selv om den i noen tilfeller vil bryte når teksten går over 2 eller flere linjer.

Om vi skulle tilby celler uten understrek, som fungere godt til regnestykker, vil størrelsen bli annerledes enn den med strek. Ønsker at sketch komponentene skal fungere godt uavhengig om du bruker med eller uten border-bottom.

Et annet argument er at tabeller satt inntil andre komponenter vil lettere komme på linje i forhold til hverandre...? :)

[Lillebo]

Hehe, ja jeg skjønner. Men jeg tror kanskje du overvurderer hvor viktig/nyttig det er at tabellrader i trang versjon hvor cellene i hele raden bare innholder tekst og hvor ingen celler bryter over flere linjer aligner til 40px høyde, når ingen andre tilfeller aligner til dette avstandssystemet overhodet.

Da tenker jeg det bør være minst like viktig at intern-paddingen i disse tabell-cellene forholder seg til avstandssystemet, noe 7px ikke akkurat gjør. Det vil også være en mye ryddigere og enklere løsning, da vi kan forklare reglene med at "stor" versjon av tabellen har 1rem intern padding, mens "trang" versjon får halvparten (0.5rem).

[sergiohaisch]

Bare et par punkter her. Alt som er i bibliotekene i Sketch gjelder @Lillebo, noen av symbolene som er der finnes ikke i NAV front-end, som en 32px høy knapp f.eks (Som har blitt diskutert i mange anledninger og hvor vi egentlig bare venter på en PR fra noen som vil lage den). Akkurat tabeller er noe som ikke finnes i Sekcth, så om du har mulighet til å lage en branch på Designsystemet i Abstract vil vi gjerne ha de du har designet @Lilyngs. Når det gjelder størrelser og avstandsystemet: det er viktigere at elementene som står ved siden av hverandre er likestilt en vertikal avstand mellom elementene går perfekt inni avstand systemet. F.eks input felt med 32px i høyde står 8 eller 16 px horisontalt fra en knapp også med 32 piksel i høyde. Kan også hende at vi trenger en enda større versjon til eksterna flater, så jeg hadde vært litt forsiktig med navgivning når det jgeldr "stor" eller "liten"

[Lillebo]

Nja, det er vel flere ting i Sketch-biblioteket som ikke er helt slik det burde være. Vi har jo snakket om behovet for å rydde der tidligere.

Noen eksempler:

Aktiv tab skal vel ikke se slik ut?

Det er vel bare én av disse lenke-stilene som gjelder?

Og disse panelene skal vel ikke ha 3px+ border?

Men du har rett i at det er flere ting som enda ikke er blitt implementert i frontend-rammeverket. Andre ting har vi vel ikke diskutert eller vedtatt skikkelig enda heller.

[Lilyngs]

Tror det kan være veldig fornuftig å tilby tabeller med celler som ikke har en understrek, og da blir regnestykket uansett annerledes. Men likt om vi skulle gå for å inkludere border i den totale høyden.

@sergiohaisch Jeg jobber med fila "Bibliotek og komponenter interne flater" som ligger i Designsystem-området på Abstract. Fra denne lager jeg branches. Jeg kommer til å sette opp komponenter til biblioteket, og har allerede begynt. Akkurat nå i fila er det mange ulike varianter av celler, og ting er ennå ikke strukturert. Dvs når vi nå begynner å lande ting og se hva vi kan tilby av tabell-varianter, så gjør jeg dette klart i Sketch. Noen nevnte at det er vanskelig å lage tabeller i Sketch, men IBM og Carbon Design System har et godt eksempel på hvordan det løses, og jeg har lyst å gjøre noe tilsvarende.