Sign up |
That's an interesting issue. What would you like it to do instead? Have the content wrap inside the column cell and make it taller?
I think the scrolling table is the only way to go, as everyone has different requirements here and the standard bootstrap answer is to do this.
We could start wrapping content, or adding additional variables to each column - but it would get messy very quickly.
Maybe at certain breakpoints we could have the action column display as the first column? Simply have the first column with .visible-xs so it's easier to action?
Not sure what the best solution would be Dave, but it does seem as if the type gets smaller to accommodate the labels, just not the data.. I'd be happy with the type getting smaller for the data as well, so that it always fits the screen it's displayed on. Especially since you can always make the type bigger with <Ctrl>/<cmd> +.
I've had a number of not so savvy sub administrators complaining that the 'modify' command didn't exist for them even though it was only a scroll away.
I (obviously wrongly) thought that the viewport command took care of fitting existing content to a screen.
Maybe some more visible indicator that there was more data to the right, maybe putting the operators, like modify and save, etc, on the left side of the screen.
Just a few thoughts,
Check out these 3 options: https://elvery.net/demo/responsive-tables/
I'm liking the "No More Tables" approach for small screens. Or many something that hides extra columns when the table is too narrow and then has a "+" or "more >>" link that shows the extra fields on mouseover.
I also like this approach (toggleView):
Basic Columns/Large Columns
...and Detail View (...):
When I originally posted, I wasn’t even thinking of small screens. I was dealing with clients using large desktop screens who thought that the ‘modify’ button was missing. (I know, but it has happened too often to be ignored.)
Both ‘No More Tables’ and ‘Toggle View’ are interesting approaches, but I kind of tend towards the automatic approach. And in my specific case, I’d still like to see the operational links (like modify, etc.) on the left rather than on the right so that they never disappeared off the screen. Then maybe the 'SCROLL FOR MORE' notice would be unnecessary.
I guess I’m old school, but I can’t see doing much more than casual back end site management on a smart phone or even tablet sized screen. And for front end users, using responsive report/form pages for information viewing and user input on their various sized devices.
This is somewhat related, although off the topic, but I’ve always felt, as have others along the way, that both the strictly linear, vertical field approach to record design and the strictly horizontal list page fields approach, either take up much too much screen real estate, leave too much white space, or result in too much vertical scrolling to get to specific fields on complex records.
I’m sure that it would take a huge amount of programing, and might upset the balance between overly simple and overly complex, but it would be interesting to be able to optionally:
1) display some fields next to each other in a record view (think a series of check boxes or pull downs that were related, or last name middle initial first name, etc.), and,
2) have some field groups (think address blocks or check boxes ) nested above each other in record list, list page fields (like the toggle view when toggled), while other fields were shown next to each other.
Would it be possible to incorporate the use of anchor tags to navigate around a record with a large number of fields. Or to have collapsible field groups the way menu groups work.
While I’m on a roll, when designing records, easily variable initial text sizes, fonts and colors for individual fields would be nice too, as well as some drag and drop capability.
Nuff for one post...
If you are interested, you can use the extention mobile:
Or for another approach :
Best for the season.