UX design beste manier van formatting?

[Verwijderd]

Momenteel werken wij aan een intranet waarbij ik verantwoordelijk ben voor front-end / design. Na enkele ontwerprondes om de look en feel te bepalen beginnen er nu discussies te komen over formatting van getallen en data. Hierbij hebben we nu 3 discussiepunten:


1. Tegoed van verlofuren
Is het beter overal een gelijk aantal decimalen te gebruiken ? Zo komt alles wel netjes onder elkaar, maar het interpreteren duurt langer.

	uren	dagen
tot 2017	8	1
tot 2018	8,5	1,075

OF

	uren	dagen
tot 2017	8,000	1,000
tot 2018	8,500	1,075

2. Datumnotatie bij berichten op timeline
Gebruik je beter absolute datums of relatieve datums :
1-1-2016 17:00 , 8-2-2016 11:15 OF 3 uur geleden, gisteren etc.

3. Datumnotatie bij evenementenkalender
Evenement op 1 maart 2016 OF Evenement op 01-03-2016.


Wat is/zijn de beste manieren om te gebruiken?

[MAX3400]

De vraag is even wat de opdrachtgever ervan vindt. Als in; is er een functioneel nut (zoals facturering) om een bepaald iets met 3 cijfers achter de komma op te leveren?

Ik wil mijn uren uitbetalen. In jouw voorbeeld heb ik 1,075 dagen tegoed. Ik verdien 22.31Euro per uur. De salarisafdeling moet dan eerst bedenken hoeveel uren er in een dag zitten (ik neem aan 8 uren) en ik verwacht dus bruto (8 x 1.075 x 22.31) = 191.866 uitbetaald te krijgen.

Imho zijn er geen beste manieren; de ene persoon is anaal gefixeerd op tijd en wil dus in de tijdslijn zien "Maandag 01-01-2016 om 08:24:51 geplaatst".

Aangezien je zelf aangeeft dat je betrokken bent bij het front-end/design (wat ik vreemd vind), zal de uiteindelijke klap voor getallen/datums/etc. toch echt van de opdrachtgever komen (waarschijnlijk marketing of HR ofzo).

[Shivs]

Voor punt twee kan je ook beide combineren, bijvoorbeeld:

Geplaatst 22-03-2016 om 09:30 (10 minuten geleden)

Of:
Geplaatst 10 minuten geleden (22-03-2016 9:30)


Je zou ook nog kunnen kiezen voor de laatste en dan de volledige datum verstoppen onder een hover.

[joint_me]

Als gebruiker vind ik tabel 1 duidelijker.

[Caelorum]

joint_me schreef op dinsdag 22 maart 2016 @ 10:02:
Als gebruiker vind ik tabel 1 duidelijker.

In zo'n kleine tabel wellicht wel. Bij een grotere tabel (zeg meer dan half scherm lang) ligt het helemaal aan hoe vaak het voorkomt dat er drie cijfers achter de komma komen te staan. Als dat in 90% van de gevallen zo is, wordt het heel erg storend om die paar te zien "inspringen" van de rechterkant gezien. Aan de andere kant is dat wellicht ook wel goed, als je daar de nadruk op wilt leggen. Kortom: we kunnen er niet zoveel over zeggen op dit moment, zonder meer context te weten.
Overigens is de tabel zoals hier afgebeeld sowieso vervelend om naar te kijken ivm. kleuren.

[emnich]

Er valt inderdaad niet zo veel over te zeggen zonder de details te kennen.

Zoals Caelorum al aangeeft, hangt het voor een groot deel af van wat het meeste voor komt. Ook speel mee wie de gebruiker is en wat die precies met die informatie moet doen. Voor een gewone werknemer die wil zien hoeveel dagen hij nog heeft, lijkt me 3 cijfers achter de komma wat overdreven.

Tot slot, je kan het natuurlijk ook nog kunnen laten instellen door de gebruiker.

[kaassouffle]

Gebruikersonderzoekje ?

[Caelorum]

Dat is altijd handig, maar kan al snel in de kosten lopen. De vraag is of zo'n op het oog klein detail het waard is, maar ook dat is iets wat alleen Ruudje87 en zijn collega's kunnen bepalen. Zonder veel meer context kunnen wij in ieder geval niet zo veel zinnigs gaan zeggen.

[DJMaze]

Bij het zien van "8,5" dacht ik eerst aan 8:50 en dat ik dus nog bijna 9 uur zou hebben.
Toen bedacht ik mij dat "uren" daar niet uitgedrukt wordt in tijd, maar in het decimale talstelsel.
Ik zou graag "8:30u" zien.

Mijn werktijd is 7 uur per dag. De waarde "1" klopt dan niet voor mij. Ik heb nog "1,14" dagen.

Hoe lossen jullie dat op?
Want iemand anders is er ook druk mee Verlofsysteem vraag

[ Voor 3% gewijzigd door DJMaze op 23-03-2016 16:27 ]

[Misha]

Er zijn geen ultieme antwoorden, gezien alles in een bepaalde context moet worden afgewogen. Echter denk ik dat je met geen van de drie echte grote UX bottlenecks hebt waardoor geen gebruiker er niks meer van snapt en er niks mee kan. :-) Gewoon een keuze maken en goan met die handel

1. Als de drie decimalen vaak voorkomen, dan zou ik zeker voor een standaard weergave van drie decimalen gaan. Dat is consistent en oogt rustiger
2. Absolute datums. Voor relatieve datums moet je meer gaan nadenken, en dat doen we liever niet
3. Als je de ruimte hebt, dan prefereer ik volledig uitgeschreven datums, domweg omdat dat lekkerder leest en je een eventueel conflict voorkomt met mensen die een andere datumnotatie gewent zijn (is 02-03-2016 nou 2 maart of 3 februari? Uuurgh, de waanzin)

Over bovenstaande zaken zijn aardig wat artikelen te vinden. Van nr 2 heb ik zelfs meerdere onderzoekjes gelezen. Die spraken elkaar allemaal tegen

[Nvidiot]

Qua datums heb ik een sterke voorkeur voor: 2016-12-31 15:12:51. Dit heeft als grote voordeel dat je zonder conversie kan sorteren en er geen twijfel is over wat de dag en wat de maand is.

[Giesber]

1. Ik vind de notatie zonder decimalen duidelijker, ook omdat het hier om verlofuren gaat. Tenzij het merendeel van de data 3 decimalen heeft, in dat geval zou ik voor de 3 decimalen gaan.
2. Ik vind de relatieve datums wel iets hebben, tenzij je 2 dagen of verder teruggaat. Als er weinig berichten zijn is het misschien niet de moeite om er tijd in te investeren, maar daar zal je zelf een beter zicht op hebbem.
3. Tenzij het om een lijstje gaat, vind ik de volledig uitgeschreven datums gemakkelijker om te lezen.

Als er teveel discussie is kan je misschien nog voorstellen om een keuzeoptie maken voor de datumnotaties. Het hangt allemaal heel erg van persoon tot persoon en bedrijf tot bedrijf af.

Nvidiot schreef op woensdag 23 maart 2016 @ 21:24:
Qua datums heb ik een sterke voorkeur voor: 2016-12-31 15:12:51. Dit heeft als grote voordeel dat je zonder conversie kan sorteren en er geen twijfel is over wat de dag en wat de maand is.

Sorteren doe je toch op een datum, en niet op een geformatteerde datum ?

[Nvidiot]

Giesber schreef op donderdag 24 maart 2016 @ 09:45:
[...]
Sorteren doe je toch op een datum, en niet op een geformatteerde datum ?

Ideaal gezien wel, maar soms wil bijv. Excel niet goed zien of het een datum is als je het daarheen copy/paste (of het gaat mis bij maand vs dag). Met deze notatie weet je zeker dat er geen discussie is over maand vs dag, kun je als ascii sorteren en gaat copy/paste naar Excel ook altijd goed.

[Edwin88]

Simpel: Maak een formatting tool die van de data van de backend op verschillende manier de data kan weergeven. Zo kan je via settings (en dus wensen van de klant) dit snel en zonder extra code aanpassen.

Zo hoef je alleen je data die op verschillende manieren kan worden weergegeven door een parser te halen, en zet je niks hard-coded vast in je code. Maakt veel mensen uiteindelijk blij.

Mocht de tool dan uiteindelijk populair worden of iets moeten veranderen, kan je dit zelfs via een knopje de gebruiker zelf laten bepalen. Maar hou je data en je weergaveinstelling zoveel mogelijk apart en uitbreidbaar!

[ Voor 22% gewijzigd door Edwin88 op 24-03-2016 17:57 ]

[Verwijderd]

thanks voor de reply's we gaan eerst de relatieve weergave proberen. Wanneer we veel gebruikers klachten krijgen of juist niet zal ik een update geven voor de geïnteresseerden.

[n8n]

Het is allemaal context zoals gezegd, maar tabulaire getallen worden meestal vaak rechts uitgelijnd met fixed-width cijfers, om het zo uit te lijnen onder elkaar. Het is in dat geval wel handig om een gelijk aantal cijfers achter de komma te hebben.

Voor de relatieve tijd, ik zou zelf een kleine range relatief doen; 2 minuten geleden, een uur geleden, etc.. maar alles ouder dan een x-tijd met dag, datum en tijd weergeven. De verhouding moet je zelf afwegen, maar er is een punt waar X dagen/weken geleden betekenisloos wordt. Wat je nog kan onderzoeken, is de weergave te wijzigen (relatief/fixed) door er op te klikken (bijvoorbeeld).

[ Voor 46% gewijzigd door n8n op 16-04-2016 14:54 ]