Usability of grid actions

Asked

Viewed 116 times

0

When we talk about usability, we have N parameters.

When we have records and the same may be numerous actions.

What is the best way to treat these actions?

Place actions on the grid line? with dropdown for multiple actions...

Leave the buttons uncoupled from the grid and make it select the record(line) of the grid and click on the desired action button?

Or make him go to the register details And there do all the actions of that record

Taking into account the following case:

Receivables

Let’s see, I can:

Edit/Delete/Print boleto/send boleto by email/set as received/set as not received

  • Common actions, already leave the button/link on the grid line. And the rest, on the [Edit] detail screen of the record.

  • Thanks for the @Tony reply, I didn’t even know if this was the right place, you say leave in the basic command line itself "Edit/Delete" and in the Details other actions on buttons outside, right? And buttons like "New" left on top right? I think it gets a good usability...

  • It would make it easier to get a response if you specify which "actions" can be performed on a record (and especially if the user can do only one or more actions on a particular record). Based on your current question, one could imagine that the method of making "Bulk" of actions for marked records is ideal, but your last sentence ("[...] do there all the actions of that record") gives room for other possibilities...

  • I edited, there will be several actions Luiz

1 answer

4

Your question is not very clear and perhaps some images with the options you imagine would have been useful. To try to help I am considering that in your system (Accounts Receivable) you have a list of records (i.e., billets or accounts arranged in a "collapsible" table), and that your question is about the best (from the point of view of usability) how to allow the user to apply the following actions to the records:

  • Edit
  • Delete
  • Print boleto
  • Send boleto by email
  • Set as received
  • Set to not received

Considering that there may be numerous records that the user wishes to delete, print or send by email, it seems to make sense to allow him to select the desired records and perform the action once (perhaps by means of a button, as you yourself suggested). This alternative (as opposed to making the user perform the action for each record) is more efficient, and therefore potentially better for usability. In this case, as the action is immediate (the records are simply deleted!), it also makes sense to confirm such interactions before executing them (also according to the principle of security and prevention of errors of Usability).

Editing is something that seems to make more sense of being done individually, because while editing an account the user keeps his context picture in memory (that is, all of his limited awareness is focused on that account). So it probably makes more sense to put the option that gives access to this function on the record line.

Maybe this also holds for the account definition as received or not, especially if it’s a matter of just switching (toggle) a graphic field such as a check-box. If, on the other hand, the definition as received or has no major consequences (for example, once an account is marked as not received, to be marked as received it will need to be properly processed by entering data into other systems - maybe a tax module? ), the principle of security and error prevention applies, and in that case it may be better to treat this action just as the actions of deleting, printing and sending by email (i.e., allowing the selection and execution at "bulk" (in Bulk).

It should be easy to see that you have some important "Ses" in the previous paragraphs. The fact is that these "tips" are heuristics (understand as best practice rules) that you can employ to build and evaluate your interface yourself. By the way, if you look at similar systems (email records are the most classic example), you will see that these problems are usually dealt with in ways similar to the ones I exemplified.

But it makes a lot of sense for you to test prototypes with your potential users. Thus, you will be able to understand which design goals are most important for each action (performance, security, memorization? ) and thus define properly what to treat as "best" in your problem domain (it is no wonder that I used italics in that word there in the first paragraph). :)

Browser other questions tagged

You are not signed in. Login or sign up in order to post.