[Webdesign/UX] Hierarchische dropdowns visualiseren

[egonolieux]

Ik heb 2 dropdowns waarbij de 2e afhankelijk is van de geselecteerde optie van de eerste. De eerste dropdown bevat een lijst met "types" en 2e bevat een lijst met talen. Bij het veranderen van het type verandert de lijst met talen die beschikbaar zijn voor het geselecteerde type.

Het datamodel is dus als volgt voor te stellen:

code:

{
    "typeA": [
        "English",
        "French",
        "German"
    ],
    "typeB": [
        "English",
        "Dutch"
    ],
    "TypeC": [
        "French",
        "German"
    ]
}

Mijn huidige implementatie ziet er als volgt uit, waarbij ik gebruik maak van een pijl om de ondergeschiktheid van de 2e dropdown aan te tonen, maar hier ben ik niet echt tevreden mee:



De box met de getallen in verhouding op het einde is niet echt relevant voor deze vraag en wordt gebruikt om de som van de aantallen van de number spinners per type/taal aan te duiden.

Hoe kan dit visueel verbeterd worden?

[Cubix]

Het ziet er wat technisch uit zo, wie is je doelgroep?

Valt me ook op dat je dropdowns geen labels hebben. Heb je de ruimte (verticaal) om het wat ruimer op te zetten?

[egonolieux]

Het is een applicatie om kaartverzamelingen te beheren, dus ik verwacht niet dat de gebruikers technisch aangelegd zijn. Dit is mijn huidige beste poging qua design en weet momenteel niet echt hoe dit verder te vereenvoudigen.

Ik zou de dropdowns labels kunnen geven, maar binnen de context waarin deze gegevens getoond worden is er niet echt verwarring mogelijk, dus laat ik ze liever weg.

[Cubix]

Als er labels zijn kan je met getallen de volgordelijkheid duidelijk maken. Stuk minder technisch op het oog:

[ Voor 11% gewijzigd door Cubix op 11-08-2018 16:47 ]

[egonolieux]

Daar had ik inderdaad niet aan gedacht. Verder wil ik er nog bij vermelden dat deze gegevens telkens in een modal/dialog getoond worden. Met de labels er bij ziet het er wat druk uit, zeker voor mobiel:



Met de labels er tussen heb ik ook het gevoel dat de number spinners niet genoeg gescheiden worden van de dropdowns.

[Cubix]

Je zou het proces kunnen splitsen door de modal in een soort wizardvorm met twee stappen te gieten. Daardoor creëer je meer focus op elke afzonderlijke stap. Dus model stap 1: 2 dropdowns, en stap 2: die aantallen. De oranje button onderin zou dan zijn "Next step >"

Over die aantallen gesproken (mint etc): dat rijtje verdient ook wel een label voor de duidelijkheid. Wat zou je daar voor tekst kiezen? En wat zou de title van de modal zijn? Als je die geeft kan ik een alternatief schetsen.

[egonolieux]

De modal in kwestie dient om een specifieke kaart te beheren; zijnde de aantallen in je verzameling als combinatie van een variant van de kaart (card variant type), de taal en de staat/conditie waarin de kaart zich bevindt (Mint, Near Mint, ...). De gebruiker krijgt telkens een lijst met kaartcondities te zien die hij kan invullen a.d.h.v de geselecteerde card variant type/card language combinatie.

Het is de bedoeling dat de gebruiker op eender welk moment de card variant type of card language kan aanpassen (dropdown), waardoor hij de relevante lijst met aantallen per kaartconditie te zien krijgt en kan bewerken. Het is niet de bedoeling dat dit proces in meerdere stappen opgesplitst wordt, dus een wizard lijkt me hier ongepast.

De titel van de modal is momenteel een placeholder, maar moet dus de naam van de kaart worden.

[Cubix]

Ah, dus als de gebruiker eerst bij dropdown 2 een taal kiest (bijvoorbeeld Engels) en dan de aantallen gaat opgeven per staat kan hij daarna weer een andere taal kiezen (bijvoorbeeld Duits) en dan voor de kaarten van die taal de aantallen opgeven. Dus de aantallen voor Engels blijven dan ook bewaard?

[egonolieux]

Dat klopt, alles wordt onthouden en op het einde kan je dan gewoon save changes doen om het in de database op te slaan. Je kan ook card variant type op dezelfde manier veranderen, en als de card variant type in kwestie de huidig geselecteerde taal niet heeft, toont hij gewoon de eerste taal uit de lijst.

[ Voor 45% gewijzigd door egonolieux op 11-08-2018 17:34 ]

[Cubix]

Dat was mij dan niet/minder duidelijk in je interface. Het lijkt erop dat je de dropdowns maar 1x kiest en bij die keuze alleen de aantallen opgeeft. Want dat is een gebruikelijk patroon bij dat soort inputs.

Omdat je met de dropdowns een andere subselectie kan beheren zoals je beschrijft lijkt het me duidelijker als die subselecties (de verschillende talen) in beeld blijven. Bij een dropdown verdwijnen ze.

Pittige case!

[egonolieux]

Het is inderdaad nogal lastig dit degelijk te visualiseren

De lijst met kaartcondities voor alle talen tegelijk visualiseren lijkt me niet echt doenbaar omdat er mogelijks 10 talen zijn. Dat wordt dan echt wel een lange onoverzichtelijke lijst. Daarbij is het vanuit het perspectief van het datamodel logisch de types en talen in dropdowns te steken, omdat een card variant type en een card language tesamen een card variant vormen. De condities maken niet echt deel uit van het datamodel en worden slechts bijgevoegd bij het opslaan van de verzameling van de gebruiker.

Beter verwoord is de essentie van mijn vraag dus eigenlijk het duidelijk maken aan de gebruiker dat die 2 dropdowns dienen om een specifieke card variant te selecteren, en dat de card language altijd afhankelijk is van de card variant type.

[ Voor 20% gewijzigd door egonolieux op 11-08-2018 17:52 ]

[Foxl]

En tabs, eventueel met enkel het vlaggetje van de taal als het anders niet past? Lijkt me in dit geval de meest gebruiksvriendelijke en logische oplossing.

[DJMaze]

@egonolieux wat nou als je het omdraait: kies eerst de taal en dan een kaart.

Eventuele mogelijkheid met 1 select: <optgroup>

[Cubix]

Even wat geprobeerd. Blijft moeilijk om er niet gelijk een database editor van te maken.



De type-tabs bovenin zijn te swipen, of met het pijltje haal je de volgende 3 tevoorschijn. Denk dat ik dat nog beter duidelijk zou moeten kunnen maken.

• Dat de uitklap per taal de condition gaat tonen is initieel niet duidelijk. Misschien toch nog ergens een label erbij.
• Ook is de kans groot dat je binnen de modal moet gaan scrollen. Dan weet je al dat een modal waarschijnlijk niet meer de juiste oplossing is.
• Verder twijfel ik zelf nog over de pijltjes per aantal. Die zijn waarschijnlijk te klein voor op mobiel om fijn te kunnen raken. (grotere hitbox)

[Klaasvaak]

Kan je het niet met een derde label verduidelijken? Stock for {name} {variant} {language}.

[egonolieux]

@Cubix Dat ziet er al een heel stuk beter uit!

Betreffende jouw probleempunten:

Zou het niet handig zijn altijd 1 "panel" opengeklapt te houden van de card conditions? Zo ziet de gebruiker meteen waarover het gaat en moet hij 1 actie minder uitvoeren. Ik weet in de meeste gevallen welk type/taal de gebruiker wil zien vanuit overzichtsniveau.

Het is hoofdzakelijk de bedoeling dat deze info getoond wordt buiten het hoofdvenster dus ik zie niet echt een beter alternatief dan een modal; scrollen lijkt me onvermijdelijk. Het enige waar ik aan kan denken is een soort "fullscreen drawer", maar dat is dan weer niet consistent met dezelfde versie van dit venster (ik heb een lager abonnement waar enkel het card variant type gebruikt wordt):



Wat de pijltjes betreft, heb ik de hitbox reeds groter dan het icoon zelf ingesteld. Ik denk dat dit groot genoeg moet zijn voor mobiel:



Is er trouwens een reden waarom je de pijltjes in jouw voorbeeld aan de rechterkant zet? Is dit zodat je op mobiel met je rechterhand er beter aan kan?

@DJMaze

Ik weet niet of ik goed snap wat je bedoelt. Een taal is altijd ondergeschikt aan een type.
Alles in een dropdown met optgroups gooien kan een oplossing zijn, maar dan wordt de lijst wel lang en onoverzichtelijk. Dan verkies ik eerder de oplossing die @Cubix geeft.

[Cubix]

egonolieux schreef op zondag 12 augustus 2018 @ 11:40:
@Cubix Dat ziet er alleszins al een heel stuk beter uit!

Betreffende jouw probleempunten:

Zou het niet handig zijn altijd 1 "panel" opengeklapt te houden van de card conditions? Zo ziet de gebruiker meteen waarover het gaat en moet hij 1 actie minder uitvoeren. Ik weet in de meeste gevallen welk type/taal de gebruiker wil zien vanuit overzichtsniveau.

Dat is geen gek idee, zeker als je inderdaad kan voorspellen wat ze het meest zullen gaan gebruiken.

Het is hoofdzakelijk de bedoeling dat deze info getoond wordt buiten het hoofdvenster dus ik zie niet echt een beter alternatief dan een modal; scrollen lijkt me onvermijdelijk. Het enige waar ik aan kan denken is een soort "fullscreen drawer", maar dat is dan weer niet consistent met dezelfde versie van dit venster (ik heb een lager abonnement waar enkel het card variant type gebruikt wordt):

Ipv een drawer kan het naar mijn idee best een losse (detail)pagina zijn. Dan werkt de history-back knop van de browser direct zoals verwacht als de gebruiker toch terug wil. Maar snap dat consistentie ook wel prettig is. Overlay's/modals met ingewikkelde functionaliteit kunnen trouwens moeilijk zijn om te developen.

Wat de pijltjes betreft, heb ik de hitbox reeds groter dan het icoon zelf ingesteld. Ik denk dat dit groot genoeg moet zijn voor mobiel:

[afbeelding]

Nog steeds wat klein denk ik. Android gebruikt als minimum bijvoorbeeld 48 bij 48 punten. iOS ook zoiets.

Is er trouwens een reden waarom je de pijltjes in jouw voorbeeld aan de rechterkant zet? Is dit zodat je op mobiel met je rechterhand er beter aan kan?

Ik had er geen reden voor. Andersom zoals jij doet leest prettiger omdat het label dichter op het getal zit.

[DJMaze]

egonolieux schreef op zondag 12 augustus 2018 @ 11:40:
Ik weet niet of ik goed snap wat je bedoelt. Een taal is altijd ondergeschikt aan een type.

In jouw datamodel. Maar hoe is dat voor de gebruiker?

Neem bijvoorbeeld een website DB waarbij pagina X in meerdere talen is.
Het datamodel is: pagina -> taal
Echter ziet de gebruiker: /taal/pagina (dus precies andersom)

Je moet gescheiden denken:
- wat is handig voor je datamodel?
- wat is handig voor de gebruiker?

[ Voor 4% gewijzigd door DJMaze op 12-08-2018 16:43 ]

[egonolieux]

@DJMaze Met datamodel bedoel ik niet de databasestructuur, maar hoe het "domein" in elkaar zit. De talen zijn altijd ondergeschikt aan een type. In de database is de "variant" tabel een combinatie van een type en een taal (ze staan op gelijk niveau), maar naar de gebruiker toe horen talen altijd gegroepeerd te zijn per type.

Ipv een drawer kan het naar mijn idee best een losse (detail)pagina zijn. Dan werkt de history-back knop van de browser direct zoals verwacht als de gebruiker toch terug wil. Maar snap dat consistentie ook wel prettig is. Overlay's/modals met ingewikkelde functionaliteit kunnen trouwens moeilijk zijn om te developen.

Is een fullscreen drawer niet praktisch hetzelfde als een aparte pagina qua gebruik? Beiden hebben de gehele schermruimte ter beschikking. Ik ga het in ieder geval proberen implementeren met een modal en zie wel wat het eindresultaat zegt.

Nog even een algemene bedenking/vraag; is het algemeen zo dat bij dropdowns een eenmalige selectie verwacht wordt en dat bij tabs "verspringbaarheid" verwacht wordt?

[ Voor 8% gewijzigd door egonolieux op 13-08-2018 00:01 ]

[Cubix]

Nog even een algemene bedenking/vraag; is het algemeen zo dat bij dropdowns een eenmalige selectie verwacht wordt en dat bij tabs "verspringbaarheid" verwacht wordt?

Als het ik het bekijk qua vaak voorkomende patronen online, maar ook hoe ik gebruikers in ux tests die ik heb afgenomen er mee omgaan ga ik daar wel vanuit.

Maar daarmee is niet gezegd dat er geen situaties bestaan in een bepaalde context waar iets anders wordt verwacht van deze patronen.

[egonolieux]

De voornaamste reden dat ik die vraag stel is dat de types van een kaart bijna nooit in zijn geheel te zien zijn met de tabs (het zijn er meestal meer dan 3). Bij een dropdown kan je meer opties tegelijk tonen en het bespaart plaats t.o.v. tabs (belangrijk in een modal).

Ik zou de tabs desnoods kunnen laten wrappen zoals hier:



Maar dan is er natuurlijk nog meer plaats verloren.

Mijn vraag is in essentie of je denkt dat een dropdown te riskeren valt binnen deze context aangezien het meestal gezien wordt als een "eenmalige keuze". Misschien is dit iets dat ik door de gebruikers zelf moet laten testen?

[DJMaze]

Als er zoveel in zit zou ik eerder kiezen voor een foldable tree en een input filter.
Op mobiel/tablet zijn dropdowns gewoon niet handig.

[ Voor 28% gewijzigd door DJMaze op 14-08-2018 12:38 ]

[Cubix]

egonolieux schreef op dinsdag 14 augustus 2018 @ 12:11:
De voornaamste reden dat ik die vraag stel is dat de types van een kaart bijna nooit in zijn geheel te zien zijn met de tabs (het zijn er meestal meer dan 3). Bij een dropdown kan je meer opties tegelijk tonen en het bespaart plaats t.o.v. tabs (belangrijk in een modal).

Ik zou de tabs desnoods kunnen laten wrappen zoals hier:

[afbeelding]

Maar dan is er natuurlijk nog meer plaats verloren.

Mijn vraag is in essentie of je denkt dat een dropdown te riskeren valt binnen deze context aangezien het meestal gezien wordt als een "eenmalige keuze". Misschien is dit iets dat ik door de gebruikers zelf moet laten testen?

Gebruikerstesten! Hoe low key dan ook: altijd doen!


Omdat het waarschijnlijk meer dan 3 tabs zullen gaan worden had ik in m'n ontwerp die pijl gezet naast de tabs. Swypen door de tabs op mobiel. Op dekstop heb je de ruimte om er veel meer te tonen. Dat patroon heb ik al vaker gezien, maar ik ben er zelf nog niet van overtuigd dat alle gebruikers snappen dat je de tabs kan scrollen.

Een dropdown maakt in alle gevallen alle items niet direct leesbaar.


Ik weet natuurlijk niet hoe je 'main' scherm eruit ziet, maar wat ook zou kunnen: laat gebruikers voor het editen van cards de flow per card variant type doorlopen. Dus laat ze eerst in de modal kiezen voor welke card variant ze een wijziging wil doorvoeren of wil inzien, en dan pas de dieper liggende details. Wanneer een gebruiker dan toevallig twee varianten wil zien/editen doorloopt hij de flow gewoon 2x. Hierdoor ga je heel bovenstaande issue uit de weg.

[egonolieux]

Als er zoveel in zit zou ik eerder kiezen voor een foldable tree en een input filter.
Op mobiel/tablet zijn dropdowns gewoon niet handig.

Je bedoelt geneste panelen die je kan openklappen?

Ik weet natuurlijk niet hoe je 'main' scherm eruit ziet, maar wat ook zou kunnen: laat gebruikers voor het editen van cards de flow per card variant type doorlopen. Dus laat ze eerst in de modal kiezen voor welke card variant ze een wijziging wil doorvoeren of wil inzien, en dan pas de dieper liggende details. Wanneer een gebruiker dan toevallig twee varianten wil zien/editen doorloopt hij de flow gewoon 2x. Hierdoor ga je heel bovenstaande issue uit de weg.

Dus je bedoelt eerst een overzicht van card variant types tonen in de modal met knoppen bijvoorbeeld?
Bij het klikken/touch op de knop krijg je dan het overzicht met talen met een back knop bovenaan. Begrijp ik dit correct?

[DJMaze]

egonolieux schreef op dinsdag 14 augustus 2018 @ 20:36:
Je bedoelt geneste panelen die je kan openklappen?

Even snel:

HTML:

Find: <input oninput="functionThatMakesDetailElementsHidden"/>

<details>
    <summary>Unlimited</summary>
    <details>
        <summary>English</summary>
        <div>Mint <input type="number" step="1" min="0"/></div>
        <div>Near mint <input type="number" step="1" min="0"/></div>
    </details>
    <details>
        <summary>French</summary>
        <div>Mint <input type="number" step="1" min="0"/></div>
        <div>Near mint <input type="number" step="1" min="0"/></div>
    </details>
</details>

https://www.w3schools.com/tags/tag_details.asp

[egonolieux]

Ik denk dat voor deze toepassing het filteren door middel van typen/toetsenbord niet echt de gewenste oplossing is. Bovendien zit je ook initieel met een lange lijst (voor je begint te filteren).

Om verder te gaan op het voorstel van @Cubix, bedoel je zoiets?



(paint ftw)

[Cubix]

Ja idd, als eerste stap. Om de actie duidelijk te maken een titeltje er boven als "Choose a card variant to view and edit:".

Na het kiezen van het type waarmee je de flow verder gaat komt stap 2 met de rest van de interacties.

Gezien dit pas stap 1 is zou de "save all" knop hier nog geen zin hebben. Die kan weg of inactief (grijs) zijn.

[botwood]

Wellicht een idee om eens te kijken naar een soort van card grid. Dan kan je alles ook beter visualiseren met iconen e.d.
Ik had ook nog een kleine mockup gemaakt. Misschien dat je er wat aan hebt (o.b.v. een card grid)
Je kan er altijd voor kiezen om de eerste opties nog boven de talen te zetten. Dat scheelt weer 2 klikken voor de gebruiker.