Improve responsiveness of backend elements

[ghost]

Going to show two quick examples but I feel the problem extends to all the other backend elements.

Example 1 - Buttons

I'm pretty suprised with even basic buttons in the backend are not responsive at all, see example:

Here we can see the search box cover the buttons. In a responsive world the buttons should be moved down a row automatically.

Example 2 - Tables

This follows carries on from the github issue: https://github.com/octobercms/october/issues/4618

Not sure why it was closed? But there is still no solution to this issue.

In fact it gets worse when you start investigating this issue with tables and soon realize that many plugins use partial files with the list widget and all these tables are completely hanging out of the screen when testing October V460 (that's not been released yet).

Right now the lists widget seems to use a very old school method with css media queries and will turn on the responsive table when the screen is a certain width. Maybe the orginal design thought this would be good for mobile phones?

However, when testing tablets we have large table data hanging out of the screen and no way to scroll the data back in to view with the lists widget.

On Mobile phone devices it gets even worse and half way through the screen widths we have a css media query removing the left sidebar and then there is a huge block of screen width where you can't scroll the table at all.

Most developers will say well I use October CMS with desktop computers so who cares? Well when you create a list widget with lots of data and a few columns. I reduce the screen size down from 8K to 1920 x 1080 and the list widget data is hanging out of the screen. I only have 6 columns to see this issue. Meaning I can use the list widget for 4K and 8K computer screens and desktop screens with lower resolutuion - the data starts hanging out of the screen view and no way to pull the table data into view.

This is no good at all right now with the list widget and worse when you use a list widget in a partial file to create a secondary layer.

Modern day solution

1. Buttons - Should not have a overflow: hidden function and get covered up.

2. Tables - Should be responsive when the data goes out of the screen view and not use a css media query to try and second guess things!

The list widget gets worse when a developer adds more columns in the table, because the list widget table will hang out of the screen at a higher screen resolution causing a bigger gap of no functionability at all.

The list widget has major issues when you start creating a second layer of data in a partial or more deeper layers. The responsive feature just goes out of the window at that point.

Basically the current setup makes a lot of features totally useless in most screen sizes.

Out of the box

I can adjust my plugins, but these kind of features should be out of the box and applied to evereything in the backend as standard.

[Samuell1]

You see that arrow on right side ? It means you can drag scroll buttons on mobile.

[ghost]

@Samuell1

You see that arrow on right side ? It means you can drag scroll buttons on mobile.

Yah it shows when the screen size hits a certain screen width and not when the table is hanging out of the screen.

Plus it's being applied to a div container several parents up in the dom which is not helping to force the functionality on partial list widget setups.

class="list-widget list-scrollable-container scroll-after"

Also the setup is kind of useless when I have 100 rows in my table. I have to scroll to the top of the screen just to move it to the right and scroll back down to my selected row.

[ghost]

Possible Solution: https://github.com/filamentgroup/tablesaw

[ghost]

Possible button fix:

modules/system/assets/ui/storm.css Code line: 3076

Old:

.control-toolbar .toolbar-item .btn, .control-toolbar .toolbar-item .btn-group, .control-toolbar .toolbar-item .dropdown {
    white-space: nowrap;
    float: none;
    display: inline-block;
    margin-right: 10px;
}

New:

.control-toolbar .toolbar-item .btn, .control-toolbar .toolbar-item .btn-group, .control-toolbar .toolbar-item .dropdown {
    white-space: nowrap;
    float: left;
    display: block;
    margin-right: 10px;
    overflow: visible;
    width: fit-content;
    margin: 0 10px 10px 0;
}

Disclaimer: Probably will throw out some error's here and there. Haven't tested it through out the cms, just wrote down some code from top of my head.

Yah as I thought issue would be old browsers not understanding modern css, e.g. https://www.caniuse.com/#feat=mdn-css_properties_width_fit-content

p.s. width: fit-content; is for people creating anchor link ajax buttons.

[Samuell1]

@ayumihamasaki2019 I told you you can drag buttons there is no need to add anything its already responsive.

Maybe you can somehow make dragging available for full table not only for column names.

[ghost]

@Samuell1

I told you you can drag buttons there is no need to add anything its already responsive.

Sorry my bad, I thought you were talking about the table not the buttons.

p.s. What you saying doesn't work my side though ???

I just decided to inject some flexbox into my plugins to over write things for now:

Above is a list widget - I just removed the table below in the dom as the plugin is not finished yet.

As for the HTML table, it's kind of bugging me. Want to spend some time creating a nice solution that we can roll out in October to make table's better responsive and touch screen dragable.

[drmzio]

I think October could use a new UI. I'm thinking about bringing TailwindCSS to the backend and replacing the old Bootstrap + table layout css hacks. Simply using Flexbox would solve many of these issues. On a side note, also using Vuejs to replace the monster of the jQuery library.

[bennothommo]

@drmzio There's been quite a few people that have suggested doing the same. The issue with Flexbox is that it's not quite supported fully by IE11, which we still do support. It also has been reported in the past that flexbox introduces performance issues, although that may not be as much of a concern now as it was back then.

If you wanted to make a proof of concept though, you could take a look at https://octobercms.com/plugin/cyd293-backendskin which provides a way to define backend customisations in an October CMS theme.

[amdad]

Nor bootstrap, nor tailwind. We don't need any framework. Custom patterns we can write for our use cases. Really modern CSS have solutions that resolve most problems. For that IE crap. It just a matter of time it will be blown away with wind. If someone really want support for it, can write hacks, polyfills or something to load just when IE is detected and fix what need to be fixed just for IE.

The issue with Flexbox is that it's not quite supported fully by IE11

Benno, with all respect, that not how developers thinks. Not just devs, That's not rational at all. IE is already dead product. Closed by Microsoft, replaced by Edge which also drop their engine for Chromium (early versions already available). No future with that backwards way of thinking. Flexbox is standard already and is here to stay as long as CSS. Not using it for any reasons at this moment is pure nonsense. We will not drop standard 97% users just for users that still doesn't updated their browsers because sooner or later they will. We can fix it to act properly even without additional files for old browsers nor special JS. Since, all flexbox, css grid and all the rest is ignored when not recognized in old browser. Then older ways of dealing with things works without any tricks. So you can user normal floats and older techniques for old browsers. In my opinion even this is wrong now. Since all modern browsers fully support css grid and flexbox, we should not even waste time fro writing fallbacks. Just because some elements will look bad on crappy browser it's still ok as long it do not break functional parts of system. As long user can read/write/save data and get things done. It doesn't matter if layout doesn't keep shape in zombie browser.

BTW. Current backend theme is not going anywhere soon I bet. So, time will dissolve other issues.

[ghost]

I don't want to get involved in this conversation 😆

• Tailwinds uses SASS and October uses LESS - so means a complete rewrite, this was my reason for creating a post on making October version 2.

• IE10 has been dropped beginning of 2020 and IE11 is still being used by Windows, bennothommo has given me the info many times, see his comment here: https://github.com/octobercms/october/pull/4632#issuecomment-534380648

• Flexbox has several ongoing bugs with IE11, however most issues are because many dev's are not using the correct css prefixes which correct 98% of all issues in IE.

• One way to sort out IE in October could dump a ton of polyfills in the dom for people still using IE. I'm not talking about modernizr but I was thinking more of polyfills.io

Lastly, I don't want to submit a button fix right now because I think it would require a deep test and I worry about breaking some people's plugins. But I'm happy to try and sort something out with these stupid HTML tables and make nested tables repsonsive. Looking at people's fixes on the internet they all suck and I really see responsive sliders as the answer.

If anyone feels they want to submit fixes to make any elements in the backend responsive, please go ahead.

[Samuell1]

This is how buttons panel works on mobile. @ayumihamasaki2019

[bennothommo]

@amdad the fatal flaw in your argument is assuming that just developers use the backend of all installations of October.

[LukeTowers]

Anyone is free to develop their own backend themes completely custom at any point. Just ask @LarBearrr how far you can take October's extensibility when it comes to the backend skin, he's done some truly amazing work and hasn't had to hack the core at all to do so. He could probably write a series of blog articles about developing custom backend skins at this point 😄

[ghost]

@Samuell1 Thanks for gif will have to dig deeper and try to find out why that's not working my side, thanks for the info 👍

[amdad]

@amdad the fatal flaw in your argument is assuming that just developers use the backend of all installations of October.

Sorry, but I didn't said this at all. You need to read again. I even add scenarios to cover all human users. Even those who have still zombie browser. IE11 is not so old. It's just dead. But as ayauminagasaki said, with proper treatment it is not so broken as many would think. Even it so, there are Polyfills and other tricks are for that matter! What I was said it's only matter of time, user will need to switch to modern browsers anyway. Because Microsoft itself will kill own bastard as they did before with IE6 IE7 and so on. Remember when whole internet wants to kill that basilisk cockatrice? No one today don't even remember this. And not one sane person would say today. Hey, we need to support this IE7 thing. IE is DEAD. As Netscape, as Opera browser (when they switch to Chromium and drop Presto engine) etc. No one cares about products when even authors saying: Don't touch it, it's dead. dead as dead. end of story.

No one ask me if I want to throw away my computer. Windows just update itself and hibernate my old machine forever (needed to reset bios each time to run system) because even if it was still good hardware. It was too old for Windows to drive it. No one cares that micro percentage of users that doesn't want to update. If you care, do your work. Do not stop 98% of people from going further because someone is fan of trash metal.

You do not write web for 3% of usecases and then try to make it also ok for 97%. Oh man oh man.

You use latest and greatest already standards and then think about adding temporary needed bridge for old people. Because once people walk through on right side, bridge won't be needed anymore. Do not use flexbox or css grid was a question 3 to 4 years ago. Not today. If you want to live the past build your own time machine and good luck.

And most of it all. backend is not fronted. It;s not like 1 site admin cannot be asked: 'Hey, switch your browser mr. site owner'. We didn't ask all website visitors to do that. Just ask your client to install Brave browser for a sake of his sane.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days. If this issue is still relevant or you would like to see action on it, please respond and we will get the ball rolling.