rackerlabs / canon

A front-end framework for fast & consistent development of Rackspace UIs.
http://rackerlabs.github.io/canon/
Other
30 stars 22 forks source link

Disabled Table State #137

Closed annwa closed 9 years ago

annwa commented 9 years ago

From Nathan House: I think it would be useful to others to have this added to upstream. I¹ve been using it along with the already existing rs-status-disabled to have better tabular readability etc.

.rs-table-status-disabled { background-color: #cccccc !important; }

Here I find the need to indicate most actions are disabled on this row while the information is still useful to the end user. I’m open to changing the color darker too as was just matching the background color of the existing rs-status-disabled class. The important tag was added for consistency with the other rs-table-status- classes etc.

disabled-tr

annwa commented 9 years ago

From Elizabeth Grothues: Something to think about… The white on gray text (Screen Shot 2015-01-06 at 12.23.56 PM[1].png) doesn’t meet minimum contrast standards and is hard to read. Black #000 on gray #ccc passes and white #fff on gray #707070 (which is pretty dark) passes.
http://webaim.org/resources/contrastchecker/ screen shot 2015-01-06 at 12 19 47 pm

annwa commented 9 years ago

Good catch Elizabeth. I agree that this is problematic. Fortunately Nathan is open to making it darker.

I am also concerned that we need to consider the styling of the row as a whole. If the goal is to indicate that actions are unavailable on the row, I would expect that the action cog would also change visually to indicate that it is disabled.

bradgignac commented 9 years ago

@naterh I'm pretty sure this already exists. Am I missing something?

https://github.com/rackerlabs/canon/blob/master/lib/stylesheets/patterns/_list-table.scss#L142

naterh commented 9 years ago

@bradgignac Good catch :+1: Seems my canon install is a bit dated.

@annwa There are other actions in my drop down that are still permitted such as reading details otherwise I would have used the disabled cog.

Thanks for the quick responses and I'll update things on my side :)

mazzifer commented 9 years ago

I know this conversation is specific to an inactive status indicator, but I am kind of confused by the way this pattern is being used here.

My questions:

Why is the cog active? If actions are disabled, the cog should be disabled too.

Why are there two status indicators on the table row? Usually we just have the leftmost rectangle and the remaining table rows are text only. Do the items in the "Action" column have their own status, separate from the rest of the row?

I think of an inactive table row as having visual changes that affect the entire row, rather than just a few elements. So in this example, the inactive table row might have grey text in all columns. The action cog would be disabled as well. I find this implementation a bit confusing, as some items are visually inactive, while others appear normal.

naterh commented 9 years ago

My case is that this this indicator dictates an immutable status of the record and actions such as viewing the full record is still available. The action column also dictates the classes to assign to the tr status indicator and the actions column data presenting that status indicator for readability.

The big differentiator with these table records is that the row does not reflect the whole record as there is a space constraint. The changes column is actually calculated based on the action that was performed and in the case of create/delete/update actions, compares/presents differences between 2 json objects. So, seeing the whole record is quite useful and can present additional info that might not exist until a specific action was performed(ie. revert) and is also why I am leaving the cog dropdown enabled for presenting a view details link etc.

Datatables was a bit tricky for enabling the cog dropdowns too as the datasource is loaded via ajax and is calculated after page load and on each request. I wasn't able to use the canon.js because of this and resorted to writing my own bits for presenting the dropdown.

In addition to these, I was also planning on updating the changes column with a span.rs-status-error to help dictate that that change no longer exists when reverted too. This is all for an internal tool and is not planned on being public facing.

I respect your opinion and understand the value of conforming to the adherence specified in the docs. I also appreciate the toolset and functionality canon has to offer. My person opinion for my case is that if everyone follows strict adherence outlined, collaborative change opportunities could be delayed or overlooked.

If the status indicator pallette was bigger, I would likely use more too as there is a bit of overlap and would rather stick to canon than bootstrap for such indicators.

annwa commented 9 years ago

Hey @naterh ! I read through some of your response and I was wondering if the action cog has only one item in it for disabled rows (I'm assuming that view details is the only item left) did you consider using just a "view details" link instead of the cog?

One of the big usability flaws with the cogs is that they render their contents somewhat difficult to discover. As a result, when there is only one action left in a cog, we generally try to expose the option instead of putting it behind a cog.

annwa commented 9 years ago

Closed since the problem already has a solution.

naterh commented 9 years ago

Hi @annwa , I remove and add various cog menu items based on action status and yes the view details is the only option presented when in a disabled state. I do have a link to the same view details on the id column but present it as its numeric id as that info could be useful when viewing too.

As is currently, I use a combination of Chameleon tal:condition calls along with custom js to present which cog menu options are available based on user level access and record action status. I could update my aoColumns.mRender to return the disabled cog html using a conditional on the row data along with updating the fnRowCallback to refresh the canon css for presenting using another conditional but would then rely on the id link for viewing details which isn't as clear to the end user.

Unless your implying presenting an alternative to the disabled cog maybe as a or appending the id link with the rs-icon-external which might work though I've been throwing around the idea of integrating scheduled workflows into reverted actions and so if additional row actions such as schedule action workflow to replicate the revert action performed on that record was needed, I'd need a way to present those options to admin role users.

I did just discover the heartbeat table row notifications in the docs too. Not sure if they were added recently but, what are some thoughts on adding these in addition to the apparent overzealous already implemented? My thought is that these could be used to indicate ajax action status and response. Right now I update to the processing indicators for both rs-status and rs-table-status and using a setTimeout to remain visual before either updating the datatable via ajax or refreshing the page depending on view and action while presenting a text #messages info div thats dismissible and also on a setTimeout to hide.

I don't want to over do the styling but alot of the data presented can be a bit confusing as is and I think the more visual it is the less confusing, more readable and usable it could be.

Here's a gist of my js datatables implementation for reference and if you wanted to see the current live implementation, feel free to ping me on sametime. - https://gist.github.com/naterh/5e420f86554ce4b5940d