Reputation
Next privilege 125 Rep.
Vote down
Badges
1 7
Newest
 Scholar
Impact
~3k people reached

  • 0 posts edited
  • 0 helpful flags
  • 1 vote cast
Jun
26
comment When using tables - is it better to show a sort indicator by default or only after sorting?
This seems to be a very clear solution. The only disadvantage could be that there would be more "visual clutter" in the table header. And you are also not able to see if you changed the initial default sort order after opening the view (just in case you can't remember - although I'm still not sure if this "reminder indicator" can really be something a user needs, but just in case...)
Jun
26
awarded  Scholar
Jun
26
accepted When using tables - is it better to show a sort indicator by default or only after sorting?
Jun
26
comment When using tables - is it better to show a sort indicator by default or only after sorting?
I agree, for an immediate visual feedback that should be enough. I was thinking about the difference between the states "This is the default sort order" and "This is the sort order I changed manually" (maybe after the user got disrupted for a few minutes and continues his work now). It might be clearer to represent these states by "no visual indicator there" and "visual indicator there". But maybe this is just going too much into detail, I'm not sure...
Jun
26
asked When using tables - is it better to show a sort indicator by default or only after sorting?
May
5
awarded  Notable Question
Aug
18
awarded  Popular Question
Feb
12
awarded  Commentator
Feb
12
comment When client and server side validations occur, doesn't it make for a better UX to only do server validations?
Here are the results of a study about different forms of inline validation: alistapart.com/articles/inline-validation-in-web-forms And here's another interesting article about inline validation in general: uxdesign.smashingmagazine.com/2012/06/27/… Maybe it's helpful...
Feb
12
comment When client and server side validations occur, doesn't it make for a better UX to only do server validations?
For the user the best option would be validation on lost focus for every single input element - it doesn't matter whether this technically happens on the server or on the client side.
Jan
9
awarded  Supporter
Dec
7
comment placement of interaction elements on screen?
In our application we have actions that are related to the list or a single list item. So everything a user does has an effect on the current screen. And we have actions that are for navigation only and that lead to another screen. However, we also have actions that refer to a list item AND navigate to another screen (which means the user starts a new task based on the selected list item). I think it's important to differentiate (also visually) between actions that make the user stay in the current task and actions that lead to another task (=screen).
Dec
4
awarded  Nice Question
Dec
4
comment Should the order of add / edit / delete buttons be based on the frequency of their use?
Thanks for your answer - in this case it's not my intention to guide the user's behaviour (in terms of manipulating). It just needs to be very obvious what can be done on a screen, although the aims a user wants to achieve on a certain screen can vary depending on the current use case. (It's a software for doctors that need to use it everyday, so it's more about getting things done quickly.)
Dec
4
asked Should the order of add / edit / delete buttons be based on the frequency of their use?
Dec
3
revised placement of interaction elements on screen?
added 425 characters in body
Dec
3
comment placement of interaction elements on screen?
Also the possibility of multiple delete will depend on the kind of list. The group items are just tab items that open another list/view...
Dec
3
comment placement of interaction elements on screen?
If possible we will keep the options always visible, there will be some special lists where not all items are deletable, for these special items we will set the button disabled.
Dec
3
comment placement of interaction elements on screen?
The list could be a list of health insurance funds or a list of patients or a list of doctors or a list of users or a list of pharmaceuticals... Very different entities and for each entity the user needs to be able to perform very different actions...
Dec
3
comment placement of interaction elements on screen?
I agree, this solution would be very nice and clear if we had only 3 options (edit, delete, add). Problem is how to handle different tasks, e.g. 'create a new order for item1' which refer to a list item. There could be many of these tasks an i think that it wouldn't fit at all or at least look very crowded if we placed every option on each item in the list...