Optimize table space in the admin lists

[fjorba]

There are plenty of lists of records (personal, institutional, places, sources, etc.), in Muscat, created via the ActiveAdmin Rails gem. Some of them would benefit to have more information (columns), but sometimes there is not much space left.

We can discuss different options, from the easiest to the more complex. I'm not specialist on front end user interfaces, my knowledge of CSS and Javascript is precarious, and I'm aware that we have to work on ActiveAdmin constraints, so take my proposals as ideas, as the concrete implementations may be different.

1. Shorten long column headers

Some tables suffer the fact that its headers are too wide, or at least much wider than the values.

One clear example is the life dates in the personal names list. As there is no obvious information in the translation yaml files, in some languages the translation is specially long, for example:

config/locales/ca.yml:  filter_life_dates: "Dates"
config/locales/de.yml:  filter_life_dates: "Lebensdaten"
config/locales/en.yml:  filter_life_dates: "Life dates"
config/locales/es.yml:  filter_life_dates: "Fechas de nacimiento y muerte"
config/locales/fr.yml:  filter_life_dates: "Dates de vie"
config/locales/it.yml:  filter_life_dates: "Date di nascita e di morte"
config/locales/pl.yml:  filter_life_dates: Daty urodzenia i śmierci
config/locales/pt.yml:  filter_life_dates: "Datas de nascimento e morte"

Another example are those with values or counters, where a title like "Secondary literature" is excessive for the values it helds. Currently it is seen in the /admin/places list.

My proposal here would be add a _max_XX to those translation strings, when they are column headers, to help the translators to know how long the text should be. For example, as most of the times this value would be 9 (ex: 1841-1922), I would propose to change filter_life_dates to filter_life_dates_max_9. Of course, this is not a hard limit, and the best solution will depend on the language and the translator (in the Catalan case, we discussed internally at UAB and I proposed just 'Dates' because I knew that it will be used for this column, and the context would complete the meaning). And of course there are cases where the values are longer than 9, but html and the browsers will take care of this; the issue is that if we, as translators, can influence on the header, let's do it.

Being consistent with the _max_ convention would make those strings easy to spot.

This proposal may cause the creation of new translation strings if some of them are used both for column headers and in other places, but I don't exepect to be too many (for example, filter_life_dates is used only as colum header), and the cost would be worthwhile.

2. Change the 'show' link on the right with a link of the main field

Each of the columns without a link has the potential to be a link and replace one of the right. One obvious is the show in the right column. Of the columns on the left, I think that the main one (the 'name' field) can be used for this purpose. In this video there is a concrete example using ActiveAdmin:

https://youtu.be/_XUdbOFrDRQ?t=561

3. Replace the 'edit' and 'delete' colums with icons

There are well known icons for edit (like a pencil) or delete (like a trash can), even with colors (like orange and red) than can be used for this purpose. They can be smaller than the current texts.

4. Truncate long values

The visualization of excessively long values can be truncated (and maybe adding the ... elipsis), and the full value could be shown moving the mouse over the value (using the classic html title attribute, or triggering an onMouseOver).

5. Choose the date format more useful for each case

Some times the full date and time is not needed, and maybe with with the date is enough (the table showing older version records has the weekday; it may be useful sometimes, but having it always there occupies precious space).

6. Hide the sidebar when not needed, or move it

Having the sidebar on the right also occupies space. Googling around, I've found a couple of interesting ideas, always linked to ActiveAdmin:

• One would be to hide it when not needed: https://medium.com/@mekdigital/activeadmin-add-a-button-toggle-the-sidebars-visibility-to-save-real-restate-708d89cb5972
• The other would be to move it at the top: https://stackoverflow.com/questions/45185615/how-to-put-sidebar-filters-on-top-of-the-activeadmin-index-list

[fjorba]

I have learned later that much of the html used by ActiveAdmin is created in the arbre gem:

https://activeadmin.info/12-arbre-components.html

One of the trivial things that can be easily done is to define the column widths. I'm unsure if this would be always the best solution, but it is nice to know that we have it at hand.

https://activeadmin.info/12-arbre-components.html#custom-column-widths

[fjorba]

During the last months we have experimenting with different options here at UAB. Our current proposal is this one:

• From the three standard links at the right (View, Edit, Delete), remove Delete. We can hardly imagine to delete a record without taking a closer look at it.
• Reuse the other two as links in the field list. We think that the one that is used most is view, and so, it will be linked to the "name" field of the corresponing field list. From the view (show) record, there is also a link to the edit action.
• However, having a direct edit link is very welcome. We have decided to link it to the Id column.

As long as those links are consistent, we think that it is quite practical. Moreover, there is more space left to important information. I'm attaching a couple of screen captures.

Institutions list, with the current layout:

Institutions list, our proposal:

Users list, with the current layout:

Users list, our proposal:

If you agree with this proposal I'm willing to work on the many lists and provide patches to adapt them, starting with minimal patches. We thing that some of them would benefit with a different field list, but I understand that that would be another proposal (our institution screenshot has some changes that would not be part our minimal patches.

[jenniferward]

Thanks @fjorba for bringing this up again (in #1612) as I missed this the first time around. The screenshots help. Your points are well taken, and I appreciate your perspective with fresh eyes.

You raise a good point regarding the Delete button. I think I generally only delete from the View mode, so I would agree with removing it from the list, but my other coworkers need to take a look because they have different workflows. I'll bring this up at the next staff meeting (unless they comment here), but this might take a couple weeks due to vacations.

I agree that linking to "Name" makes the most sense to view something, and in terms of workflow, it works for me (I usually want to click on something because of the name).

Editing through the ID also makes sense, but we have many users who only occasionally log into Muscat, and if they didn't see a clear Edit link then I'm afraid they would be completely lost. I have my doubts that we can adopt this for Muscat, but I would like more feedback from others. Would icons for View and Edit help save some space? In terms of instruction and helping our majority occasional users, having a single column for both actions helps.

Regarding your other proposals: I think shorter column headings would be appropriate in some cases. Library siglum could easily be Siglum for example. We generally select labels/translations with the editing mode in mind, not the tables, so we can re-think our terms for the different purposes. And I think Dates (and equivalents) gets the point across in all languages without needing to match exactly with the field name.

[fjorba]

I'm glad, @jenniferward , that you see reasonable our policy about Delete and Show buttons. Regarding the Edit one, it is a matter of getting used to. For those that use Muscat only occasionally, probably their workflow would be first inspect and then edit, and so, clicking on the name or title, that is, the full view, and then the edit button. You can "sell" the link to the id as an edit action as a shortcut for those that have to do this action very often, like yourself. Anyway, probably a "hint" or floating text (html "title" attribute) would help in both cases. I'll try to contribute it in the next few hours (done in 84896f1).

Now we'd prefer not to create icons, because one of the problems would be the same: they are far away from the object you'd like to see or edit. We think that the link should be as close as possible to it.

I've sent the reorganization of the users table first, because it probably used for less people and not so often so you can test it in your test server to check it out, without disturbing Muscat normal use, and then improve whatever could be refined before sending the other ones.

[ahankinson]

For what it's worth, I'm 👎 for removing View and Edit and replacing their functionality with different behaviours for clicking the ID or the title. This is "Mystery Meat" navigation -- the user doesn't know what the link will do until after they click it.

[xhero]

I too think edit and view should have explicit links, maybe we can have an icon which is smaller?

[fjorba]

Removing the View link and replacing with a link in the title or name is no mystery at all. This is how the web works, and it is well established.

I concede that the linking the id to the edit action may be a little bit magical, but with the last 84896f1 patch, now there is information in the link, ex:

Moreover, in our team, many people just click on the full record and after they click on the Edit link at the right. When I tell them that they have a shortcut, they often prefer to edit it after seeing the full record.

[ahankinson]

I encourage you to read the Wikipedia article I posted, where they explicitly define rollovers as part of the UI problem that I am talking about.

Clicking on one thing does one action, and clicking on another does a different action, with no way of knowing, prior to clicking, what they will do. This is not an intrinsic behaviour.

[fjorba]

I've read it, thanks, and I agree about it regarding the Edit button. I hope that from this discussion we discover better ideas.

[xhero]

I personally find it quite confusing and arbitrary. How should a new user discover this funcionality?

[fjorba]

Which link is confusing? The Edit or both the View and the Edit? I sincerely think that the View is the normal web behaviour. The Edit is discovered with the practice; it is a shortcut.

The main objective of this redistribution, that we have discussed quite a but at UAB, and we all agree that it has been a real improvement regarding Muscat usage, is to have more useful information and less redundant links (View, Edit, Delete are repeated dozens of times in each screen) in the same space.

[ahankinson]

They're not really redundant, though, are they? Each one has an action for a different record. It would only be redundant if each one had the same action.

[fjorba]

Ok, I agree. What is redundant is the text, not the behaviour, you are right. But other webs are able to achieve the same functionality without a repeated "View, Edit, Delete" links for each record, and that's why we propose this enhancement. We have it in our three local instances, and we are happy with it. If RISM Muscat users think that it is useful and an improvement regarding current layout, I'm willing to contribute to it upstream. If not, we'll keep it as local patches.

[xhero]

I'm a bit confused what harm does having an explicit "edit" action, which clearly indicates to click there to... edit the record

[fjorba]

No, an explicit Edit button is no problem. I agree that linking it to the id is arbitrary, but consistent (all lists have an id column). But again, most of the people here at UAB that have been working with our test instances, usually prefer to edit from the full record. So, for them, removing the Edit link from the list would be no harm. But some appreciate having a shortcut, call it an explicit "Edit" link or a magical link in the id column.

[fjorba]

So, trying to make some consensus out of this discussion, let's take the controversial magic Edit link in the id column out of the equation for the time being. I'd like to know if there is an agreement about two of the other standard ActiveAdmin action links:

1. removing Delete link from the list; deleting must be done from the full record.
2. replacing the View with a link to the name or title from the list, like any other web application.

If we can get rid of those columns, we gain some space that can be used by other information. Thanks.

[jenniferward]

We discussed your proposals, @fjorba, in our staff meeting today (just the Editorial Center) and a couple of my coworkers indeed use the Delete link directly from the table views, so we have to keep it and the column.

We are still open to testing out icons, however. Essentially we already have them available from the View page: pencil, trash can, eye.

[fjorba]

Thanks for your feedback, @jenniferward. If any of your coworkers indeed use those direct links, it is obviously better to keep them. Regarding icons, if they are not both smaller and clearer that the current text (a difficult combination), I'm unsure that the change is worthwhile.

Looking back, probably shorter column headers (like people's life dates example above) may produce good results with minimal hassle.