Closed mtribone closed 7 months ago
I find the fluid layout to not be good for readability. Humans can read better in columns (up to about 85 characters) and well designed sites (e.g. https://mondaynote.com/apple-culture-after-ten-years-of-iphone-dbc65f4438aa) use this technique
@jcoyne Yeah I agree with you about line length and readability. I think that the fluid container better accommodates multiple columns and larger font sizes than the predefined break points from Bootstrap. We can tackle excessive reading lengths similarly to what Bootstrap does but based on the content and its functionality instead of canned break points.
Would like the @samvera/hyrax-ui-ux-advisors to sound off on this.
+1 to expected behavior of filling the viewport with reasonable side margins. Unnecessary white space as described in actual behavior can be distracting.
I assume that this doesn't pull us away from Bootstrap - that it has adequate support for fluid containers (class .container-fluid?) and that this proposed change may also make the pages more mobile-friendly and responsive. (Comment if those are bad assumptions.)
@ggeisler Thoughts on fluid containers?
@mjgiarlo: There are pros and cons to fluid vs. fixed and I'm not sure there is an obvious right answer here. @mtribone makes a reasonable argument for fluid and I'm sure we could do it without a ton of effort, especially if we're just focusing on the public pages.
On the other hand, I personally like the whitespace I see in the examples @mtribone posted (the homepage doesn't look good but that's just because it doesn't have any real content or design yet, and there are unnecessarily narrow columns in others like the Files page, but I think those will be improved with future page layout updates). I think the whitespace contributes to keeping the pages looking calm and less cluttered. But that's just an opinion and if enough others in the community like the idea of fluid (as @newmanld seems to above), and we agree there is a clear accessibility win in switching (I need more explanation to be convinced it's a clear general UX win), then I'd say that certainly matters more than my personal preference.
One thing that kind of concerns me about this, though, is Hyrax is based on Blacklight and Blacklight is not fluid. So if there are enough people in our community that prefer fluid layouts to cause us to switch in Hyrax, it seems like the switch ought to start in Blacklight (though obviously it doesn't need to, technically)?
@ggeisler - I think you make a case for being selective about which pages should switch to fluid and not making a general UX switch. The unnecessarily narrow columns in the Files page stood out the most to me in the examples above. I don't think this is a general enough UX concern though to cause major refactoring.
@ggeisler @newmanld 👍 for identifying specific pages where it makes sense. As @jcoyne and I were discussing we can have an issue with line length/readability with fluid containers. Also good point about Blacklight. And if we move to Blacklight pages?
This is not an issue that comes up using any accessibility evaluation tools (WAVE, axe, SiteImprove) so this seems to be more in line with user experience accessibility. We are still using Blacklight and have updated to Bootstrap 4 and Blacklight 7 so sticking with patterns from that community might point the way forward regarding this issue. I also checked the File Details View page (https://dev.nurax.samvera.org/concern/parent/wd375w54j/file_sets/zk51vh01g) and we seem to be calling up a "container-fluid" class now. That class isn't being used everywhere (the Contact Form does not have it) but we might be in better shape regarding this reported issue now.
Keeping with community standards to use Blacklight and Bootstrap will be how we address responsive and whitespace issues like this, so this issue is being closed.
Descriptive summary
In Hyrax 2.0.0alpha, the public facing pages like Work Show, File Set Show, Edit File Set, Static Pages, and Search Results use a fixed width
.container
class from Bootstrap that uses media queries to change content width based on predefined break points. Suggest using a fluid container instead for better user experience and accessibility.Rationale
Using a fluid container for the mainor content area allows for greater flexibility of viewport and font size for a range of users. If legibility of a fluid container is a concern based on long line lengths, we can increase the font size as the width of the viewport grows.
Expected behavior
I expect that the main content area fill the viewport width from left to right with reasonable side margins.
Actual behavior
The container is fixed based on predefined break points and leaves undesired white space on the left and right sides of the viewport.
Steps to reproduce the behavior
Related work
https://github.com/psu-stewardship/scholarsphere/pull/426