RFC: 'Show details' column picker

Bloke · 2016-10-18 11:34:32

In 4.7.0 we’re considering dropping the ‘show details’ checkbox in favour of a mechanism to allow website admins to decide which columns to show on each list page. This would be a per-user feature so any user can pick which columns they see… up to a point… and have that remembered on a per-panel basis on that device so you can have different columns visible on mobile compared to your tablet or desktop. Hello local storage!

Doing this does, however, bring with it various challenges so we’d like some opinions. This is a two-pronged post. One is for the UI/UX side of things, the other is more technical. Please weigh in on whichever side you feel you can.

Firstly, presentation. We’re thinking initially of a dropdown list of checkboxes, like the new search widget, with one checkbox per available column. But how should it interact?

Should you pick the columns and then submit your changes, thus refreshing the whole page?
Should the columns be displayed/hidden immediately via jQuery/AJAX?

Both mechanisms would send the details of which columns were selected so that next time the page loads they could be omitted, but in the latter case that would mean we’d still have to download the entire data set in case you wanted to toggle a column back on. Makes for fatter page downloads. Alternatively, we fetch the just-checked column’s data and insert it via AJAX in the right place.

I’m leaning towards a whole-page refresh for simplicity but don’t exactly know how to present the UI in either case.

Further, there’s the option of whether we deem any columns “essential”, and which ones. Bear in mind this has landed us in hot water before (cf. Essential Forms). How do we handle this? Some columns (e.g. id/name) are ‘essential’ at the moment because they contain anchors that lead to the Edit step. Do we allow these to be toggled off and have a separate ‘edit’ link on each row? Does such an ‘Edit’ link only appear if an essential column that leads to an Edit step is removed? Or do we disallow (omit from the checkbox list) certain columns. If so, which ones per panel?

Toggling a column means that if the result table was previously sorted by that column, we need to pick another. How do we fall back, bearing in mind we might only have non-sortable columns remaining (unless we ensure that at least one essential column must remain, and it’s sortable)? And if we’re doing this via AJAX/immediate fetch, the list needs to be resorted somehow.

Similarly, what if a search is in progress? Try and continue to filter by it, or drop the column from the search dropdown column list too? Or do we just always clear any searches if you alter the selected columns?

I’m sure there are more gotchas. As you can see, this is a bit of a minefield so we need to determine if it’s worth trying to overcome them by implementing this feature, or if we simplify the scope of the feature (think: convention over configuration), or leave it as it is now.

Assuming it’s okay to proceed, this would be a golden opportunity to allow plugins to interact with the columns. Say your plugin has added a column to the txp_image table. Wouldn’t it be cool to be able to output it in the regular table and have it automatically picked up in the list of available columns to show/hide? And be sortable, without having to write your own admin page under Extensions?

We already permit plugins to alter the ‘where’ portion of the query that runs. But this would be on a whole new level, and there are many things to consider. Like how to tell core which extra column name(s) to extract. And in what order they should appear in the column list (unless we assume column order as defined in the DB). Would new columns be allowed to appear before any “essential” columns? How do we allow plugins to state whether a custom column is sortable, and what its label is. And so forth.

Presumably we’d introduce another callback. If so, where? Do we package up the existing column meta data and expose it to allow plugins to alter the list via a callback_ref or pluggable_ui? That would permit plugins to remove columns and/or replace them with their own.

Lots of scope. How far do we go? Do we go at all?

Questions, comments, ideas, please speak up.

Last edited by Bloke (2016-10-18 11:35:37)

colak · 2016-10-18 12:45:07

Hi Stef,

Excuse my confusion. What pages are you thinking about? The articles, plugins images? any others?

Bloke · 2016-10-18 12:59:35

colak wrote #302283:

What pages are you thinking about? The articles, plugins images? any others?

Anything with a table on it and a ‘Show more detail’ checkbox:

Content->Articles
Content->Images
Content->Files
Content->Links
Content->Comments
Presentation->Sections

We could extend this to Admin->Users (mmm, smd_bio reimagined) and Admin->Plugins but at the moment they don’t have any togglable extra details.

uli · 2016-10-18 13:00:32

Wow! Too much choices, my tiny memory puts its feet up!
Counterquestion: How much workload would implementing a script for sorting by columns and reordering columns take from both of you compared to the advantage your current plans bring? I’d be very content with such a script!

etc · 2016-10-18 13:09:58

If you want to invite plugins to the fiesta, I would delegate it all to client-side js show/hide atm. This allows for immediate column toggles, without any ajax refresh. Fatter page downloads is not a big issue as long as lists are reasonably paginated. We could even imagine automatic “select box” population from table headers.

On the other hand, I don’t see how we could automatically decide which columns to pick up on the server-side. Even some core data (say, Section titles) come from multiple tables.

Bloke · 2016-10-18 13:11:11

uli wrote #302286:

Wow! Too much choices, my tiny memory puts its feet up!

Yours and mine too :-)

How much workload would implementing a script for sorting by columns and reordering columns take from both of you compared to the advantage your current plans bring?

We can already sort by a column (a singular column) as long as it makes sense to do so. There’s a possibility of ditching PHP sorting, and doing it all client side with a jQuery plugin like datatables but I think it’s slow and (last time I tried it) a bit flaky. But it does allow sorting and multi-column filtering, which is nice.

We could probably do column drag ‘n drop easily enough so you could reorder columns. It’s probably just a few lines of jQuery. That solves one aspect of my OP, thanks for the reminder.

As far as enabling/disabling columns you do/don’t want to see, I’m not sure what other options we have in terms of UI/UX. Open to any reasonable suggestions.

uli · 2016-10-18 13:13:37

Bloke wrote #302285:

Anything with a table on it and a ‘Show more detail’ checkbox:

I’d also put the plugins table on the list: I almost never read the description but would like the “Active” column immediately beside the plugin name in order to not deactivate the wrong plugin (the reason for my proposal for re-orderable columns above).

Edit: Oh, Yiannis and Oleg already mentioned plugins, slipped my attention.

Last edited by uli (2016-10-18 13:27:40)

Bloke · 2016-10-18 13:19:51

etc wrote #302287:

I would delegate it all to client-side js show/hide atm. This allows for immediate column toggles, without any ajax refresh.

Doesn’t that run the risk of ‘flash of extra columns’ until the DOM has loaded? We’d have to hide everything until DOMready and it’s all been filtered, then show. Not insurmaountable.

Fatter page downloads is not a big issue as long as lists are reasonably paginated.

True. Slightly annoying for mobile devices to download and discard data, though.

We could even imagine automatic “select box” population from table headers.

Also true. Although some columns have special attributes (e.g. not sortable) and other columns in the DB we don’t want to display at all (e.g. the article’s Textfilter info). So we’d still need to be able to hold some kind of metadata about them, I reckon.

I don’t see how we could automatically decide which columns to pick up on the server-side. Even some core data (say, Section titles) come from multiple tables.

True. Some queries have joins that would get broken if we allowed columns to be removed. So maybe we don’t permit plugins to alter the list at all. Keep the query as-is, but allow (maybe) additional columns to be appended to the SELECT — only simple additions, no joins. If the entire result set is always downloaded, fat page stylie, and columns filtered/ordered client side by jQuery, nothing could break, right?

Bloke · 2016-10-18 13:21:38

uli wrote #302289:

I’d also put the plugins table on the list

Makes sense, with the proviso that plugins themselves will not be able to play, as they don’t run there.

etc · 2016-10-18 13:39:49

Bloke wrote #302290:

Doesn’t that run the risk of ‘flash of extra columns’ until the DOM has loaded?

IIRC we deliver the page hidden until all scripts have done their job, but it needs testing/confirmation. Anyway, it’s already the case for pane states, and I have not noticed anything dramatic.

So we’d still need to be able to hold some kind of metadata about them, I reckon.

Yes, especially for sortables.

So maybe we don’t permit plugins to alter the list at all. Keep the query as-is, but allow (maybe) additional columns to be appended to the SELECT — only simple additions, no joins.

IIRC we currently pass them WHERE clause that they can alter and return, right? We should probably give them a possibility to return also their array of retrieved data that will then be merged with core? Not clear atm…

If the entire result set is always downloaded, fat page stylie, and columns filtered/ordered client side by jQuery, nothing could break, right?

If by “entire” you mean “not paginated”, that could be fat… We need to do sorting server-side, I’m afraid.

Bloke · 2016-10-18 13:47:55

etc wrote #302292:

IIRC we deliver the page hidden until all scripts have done their job

Aye, probably. Haven’t checked for a while.

IIRC we currently pass them WHERE clause that they can alter and return, right?

Yes.

We should probably give them a possibility to return also their array of retrieved data that will then be merged with core? Not clear atm…

Interesting. We could do that as long as we’re sure that the number of rows in their result set is the same! The advantage to just adding simple columns to the core query is that the WHERE clause guarantees that. But it’s more flexible to allow their own results to be merged in as that would permit custom joins. Runs the risk of something going wonky when rendered if the number of rows differ. Could we guard against that somehow?

If by “entire” you mean “not paginated”, that could be fat…

No, I mean as it is now — paginated — but with every column represented so they can be manipulated client side. Sorry if I wasn’t clear.

etc · 2016-10-18 13:58:53

Bloke wrote #302293:

Interesting. We could do that as long as we’re sure that the number of rows in their result set is the same! The advantage to just adding simple columns to the core query is that the WHERE clause guarantees that. But it’s more flexible to allow their own results to be merged in as that would permit custom joins. Runs the risk of something going wonky when rendered if the number of rows differ. Could we guard against that somehow?

Very true, and I have no answer to this atm. Maybe altering SELECT is less risky…

No, I mean as it is now — paginated — but with every column represented so they can be manipulated client side. Sorry if I wasn’t clear.

That’s what I understood few seconds after replying, sorry :-) Yes, client side it’s just a table, whatever its source. The only problem is that locally stored column states will get out of sync if a column is deleted (with its plugin). I have no easy solution here, neither.

Textpattern CMS

Textpattern CMS support forum

#1 2016-10-18 11:34:32