Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avatar-component (NLDS-issue) #363

Open
ryanvvalkenhoef opened this issue Dec 7, 2023 · 13 comments
Open

Avatar-component (NLDS-issue) #363

ryanvvalkenhoef opened this issue Dec 7, 2023 · 13 comments

Comments

@ryanvvalkenhoef
Copy link
Contributor

ryanvvalkenhoef commented Dec 7, 2023

Design-onderzoek voor nieuw avatar-component

Avatar-componenten van andere websites:
▾ github.com
Screenshot 2023-12-08 at 17 37 34

▾ google.com
Screenshot 2023-12-08 at 17 39 26

▾ atlassian.design
Screenshot 2024-02-12 at 14 14 00

De avatar-componenten van de design systems bestaan enkel uit een avatar-symbool.

Probleemstelling
Er bestaat nog geen adequaat design of wensvoorstelling van wat een avatar-component is en waaruit deze is opgebouwd.

Analyse
Op basis van de definitie van wat een avatar inhoud, namelijk een visuele representatie van een identiteit of entiteit, kunnen we stellen dat het een component is die alleen verschijnt als er is ingelogd (wanneer er normaliter persoonsgegevens verschijnen) en een component alleen een avatar te noemen is, als:

  • Het een rond, vierkant of geronde container is of bevat met initialen van de ingelogde gebruiker
  • Het een rond, vierkant of gerond profielplaatje is of bevat die de gebruiker heeft ingesteld, ervan uitgaande dat het een visuele representatie is van een identiteit of enkele andere entiteit.
  • Het een rond, vierkant of gerond standaard avatar-symbooltje is of bevat met een contextuele voorstelling, voor zowel een particulier als bedrijfsprofiel, voor als er nog geen naam is ingegeven waar initialen uit te halen zijn.

Daarnaast is een container met SVG (standaard avatar-symbooltje) of een initiaal-tekst erin het meest voorkomend en technisch het meest wenselijk, omdat het eenvoudiger is dan het gebruik van een afbeelding-genereer-functie en bevorderlijker is voor de toegankelijkheid, omdat het aanpasbaar is op high-contrast- of dark-mode.

Verder rest nog de overweging of de naam van de gebruiker ook onderdeel is van het component, of dat deze vanwege gebruikersconflicten voortkomend uit gebruikersonderzoek of expertise vanuit overheidsdesigners beter achterwege kan blijven. En zo niet, of deze beter volledig kan voorkomen of in de vorm van voorletter en achternaam.

De avatar in initiaal- en standaardstatus mogen voorzien zijn van twee gerandomiseerde kleuren, maar de vraag is of dit wenselijk is, omdat overheidswebsites rust en betrouwbaarheid moeten uitstralen en een rode avatar, om maar een dwarsstraat te noemen, hier niet aan bijdraagt als dit niet de hoofdelijk gebruikte kleur is. Dus conclusie hiervoor is dat het gebruik van de themakleur voor dit component beter uitkomt.

Conclusie o.b.v. feedback van designers/gebruikersonderzoek

Samenvatting feedback van designer
Een avatar kan ruimtebesparend werken, maar als er geen privacy concerns zijn dat de naam wordt getoond, en er genoeg ruimte is, zou je zelfs kunnen stellen dat eerder de avatar dan de naam weggelaten kan worden. Ook kan een avatar puur decoratief zijn, maar het is vaker een button (om een non-modal dialog te openen met een menu) of een link (bijvoorbeeld om je naar de profielpagina van die persoon te leiden). Een avatar kan ook een status weergeven, bijvoorbeeld of iemand on- of offline is en een begeleidend label hebben. Dit is vaak de (deels) uitgeschreven naam. De avatar en het label zijn dan als geheel interactief.

Conclusie
Omdat een avatar-component juist gaat om de avatar zelf en het anders geen avatar te noemen is, is het vanzelfsprekend om deze er in te houden. Voor het vierkante, cirkelvormige of geronde element kan de themakleur gebruikt worden. De Avatar kan een child worden van een button of een link, op dezelfde manier als een icon. De avatar hoeft dan zelf geen begeleidende tekst te ondersteunen. De avatar zal een container zijn met een initiaal-tekst, icoon of image-element. De classes die aan het component zullen hangen die hier verantwoordelijk voor zijn, zullen 'state--text' en 'state--image' worden.

@Robbert
Copy link
Member

Robbert commented Dec 11, 2023

Goeie analyse @ryanvvalkenhoef! Heb je nu voldoende info om een checklist (definition of done) te maken voor de component?

@ryanvvalkenhoef
Copy link
Contributor Author

Dankjewel! Het onderzoek gaat eerst naar Jeffrey om de designkeuzes vast te stellen. Maar daarna ga ik het component inderdaad opbreken in losse issues.

@Robbert
Copy link
Member

Robbert commented Dec 11, 2023

@ryanvvalkenhoef Dit is een link naar de Avatar component in Figma, daar kun je zien welke design tokens handig zijn om te maken.

@jeffreylauwers
Copy link
Collaborator

jeffreylauwers commented Dec 11, 2023

Hey Ryan, mooie breakdown zeg!

Ik moet zeggen dat ik de eerste paar screenshots niet onder het Avatar component zou plaatsen. Dit lijken mij eerder links of buttons met een user of chevron icon. Ik sluit me dan ook aan bij wat je onder Analyse schrijft. In mijn optiek is een Avatar enkel dat cirkel, soms ander-vormige, element. Soms bevat het 1 a 2 initialen, soms een foto maar soms ook een user icon of een gegenereerd afwijkende vorm of grappig bedoelde illustratie. Google, Github, je vond ze daar al. Maar ook Figma, Slack, MS Teams of Whatsapp maken er veel gebruik van op verschillende plekken.

Om snel verschillende vormen van een component te bekijken kijk ik vaak bij de Component Gallery. Zo hebben ze daar ook de avatar https://component.gallery/components/avatar/

Een paar dingen die verder in mij opkomen:

  • Een avatar kan ruimte besparend werken. Om die reden zie je ze, naast de rechterbovenhoek van een Page Header ook in cards en tabellen of in de buurt van comments of chats. Maar als er geen privacy concerns zijn dat de naam wordt getoond, en er genoeg ruimte is, zou je zelfs kunnen stellen dat eerder de avatar dan de naam weggelaten kan worden.
  • Een avatar kan puur decoratief zijn, maar is vaker een button (om een non-modal dialog te openen met een menu) of een link (bijvoorbeeld om je naar de profielpagina van die persoon te leiden).
  • Een avatar kan ook een status weergeven, iemand is bijvoorbeeld on- of offline.
  • Een avatar kan ook een begeleidend label hebben. Dit is vaak de (deels) uitgeschreven naam. De avatar en het label zijn dan als geheel interactief.

En wat goed dat je rekening houdt met high-contrast- of dark-mode. En kleurcombinaties die juist niet goed kunnen uitpakken!

Helpt dit? Laat het vooral weten als ik nog ergens over mee kan denken. Zo kan ik me voorstellen dat je ook tokens nodig hebt voor interactie states voor wanneer een avatar interactief is. Daar kan ik bij helpen.

@ryanvvalkenhoef
Copy link
Contributor Author

ryanvvalkenhoef commented Dec 12, 2023

Hoi @jeffreylauwers, Dank voor je compliment en dank voor het uiteenzetten van je commentaar. Ik ga je input vandaag opnemen in de conclusie van mijn onderzoek. Ik denk namelijk dat je belangrijke aspecten aanstipt, waar ik zelf nog niet over had nagedacht.

Ik denk zelf dat de tokens zoals ze nu in de Figma staan voldoende zouden moeten zijn, omdat je voor de interactie states een class zou kunnen bijhouden. Alleen, of de non-modal dialog onderdeel is van het component ben ik niet zeker van?

Hoe dan ook bedankt, en als ik ergens niet uitkom hoor je snel weer van mij.

@jeffreylauwers
Copy link
Collaborator

Is goed.

Voor de zekerheid, het non-modal dialog zie ik als ander 'los' component.

Succes, Jeff

@Robbert
Copy link
Member

Robbert commented Dec 13, 2023

Daarnaast zal een in- en uit te schakelen begeleidend label worden toegevoegd met de uitgeschreven naam van de ingelogde particulier/bedrijf.

en standaard een 'name-label--hide', die veranderd kan worden naar 'name-label--show'.

Ik denk dat de Avatar misschien een child kan zijn van een button of een link, op dezelfde manier als een icon. De avatar hoeft dan zelf geen begeleidende tekst te ondersteunen.

De classes die aan het component zullen hangen die hier verantwoordelijk voor zijn, zullen 'state--initials', 'state--picture', 'state--private' of 'state--company' worden.

Ik denk dat --initials en --picture goede states zijn. Om naamgeving meer in lijn te brengen met bestaande APIs, zou ik ze bijvoorbeeld --text en --image noemen.

De --text versie is misschien voldoende om ook een icon te ondersteunen. Misschien moet --text gewoon de default zijn, en niet expliciet text.

Ook hangt er een 'deselected' (na klikken 'selected') class aan

Selected en deselected lijkt mij meer onderdeel van de button (pressed)

een 'dark' of 'light' class

Goed idee om donkere kleuren te ondersteunen, misschien kun je naast de standaard avatar een --forced-colors versie te hebben (die currentColor gebruikt bijvoorbeeld), waarmee de gebruiker zelf kan kiezen of de kleuren dark of light zijn.

@ryanvvalkenhoef
Copy link
Contributor Author

ryanvvalkenhoef commented Feb 9, 2024

Voordat ik de design-tokens ga inbouwen in het Avatar-component is het goed om af te wegen of we ze willen behouden en waarom. De onderbouwingen zijn gebaseerd op de voorbeelden uit het design-onderzoek. Aanvullingen en op-/aanmerkingen zijn welkom. Laten we deze commentsectie gebruiken als validatieverwerving voor dit ontwikkelingsproject. 🙏

Design token Behouden? Toelichting
kernteam.avatar.background-color Ja Een background-color is gebruikelijk voor een avatar.
kernteam.avatar.border-color Nee Een border-color is niet gebruikelijk voor een avatar.
kernteam.avatar.border-radius Ja Een border-radius is gebruikelijk voor een avatar.
kernteam.avatar.border-width Nee Een border-width is niet gebruikelijk voor een avatar.
kernteam.avatar.color Nee De kleur is standaard wit of de achtergrondkleur (als dark-mode is ingeschakeld).
kernteam.avatar.size Ja Een size is wenselijk in een gebruikersomgeving waar er accountgegevens kunnen worden beheerd en de avatar groter wordt weergegeven.
kernteam.avatar.icon.icon-size Ja In geval van aanpassing van de size, moet ook de font-size mee geschaald kunnen worden.
kernteam.avatar.text.font-family Ja Een lettertype is per thema verschillend en de Avatar moet gestyled kunnen worden op basis van het gewenste thema.
kernteam.avatar.text.font-size Ja In geval van aanpassing van de size, moet ook de font-size mee geschaald kunnen worden.
kernteam.avatar.text.font-weight Nee De font-weight wordt ingebouwd met een onveranderlijke waarde (bold), omdat deze consistent moet zijn voor elke gemeente.
kernteam.avatar.text.line-height Nee Een line-height is niet van toepassing omdat de tekst verticaal en horizontaal gecentreerd wordt in het midden.
kernteam.avatar.text-transform Nee De text-transform wordt ingebouwd met een onveranderlijke waarde, omdat initialen altijd uppercased zijn.

@ryanvvalkenhoef ryanvvalkenhoef pinned this issue Feb 15, 2024
@Yolijn
Copy link
Member

Yolijn commented Feb 16, 2024

Ik zou wel een border-color en border-width design token verwachten voor als de avatar met plaatje op een gekleurde achtergrond wordt geplaatst Bijvoorbeeld hier bij testimonials https://mdbootstrap.com/docs/standard/extended/avatar/

@Yolijn
Copy link
Member

Yolijn commented Feb 16, 2024

Ook de color design token moet beschikbaar gemaakt worden als er een background-color wordt gezet. Bij NL Design System is de afspraak dat die twee altijd als koppel beschikbaar zijn of niet.

@Yolijn
Copy link
Member

Yolijn commented Feb 16, 2024

Ik denk ook dat font-weight ingesteld moet kunnen worden omdat afhankelijk van het gekozen font de weight nogal kan verschillen

@ryanvvalkenhoef
Copy link
Contributor Author

Dankjewel @Yolijn!
Ik kan me helemaal vinden in je commentaar. Er zijn scenario's denkbaar waar je deze design-tokens beschikbaar wilt hebben. Ik vraag me alleen af of een color voor de avatar wenselijk is, omdat partijen de plank kunnen misslaan als het aankomt op contrast tussen kleuren.
De rest zal ik in ieder geval vast meenemen in de ontwikkeling. 😊

@Yolijn
Copy link
Member

Yolijn commented Feb 16, 2024

Conventie bij NL Design System is juist altijd pairs beschikbaar te stellen met het oog op tooling die deze combinatie later op toegankelijkheid kan checken.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants