Bootstrap responsive-table

[Sam Ottenhoff]

Bootstrap 3 in Sakai 11 has a table-responsive wrapper "to make them scroll horizontally on small devices". This table-responsive wrapper also sets "nowrap" on the table cell contents. Does anyone understand the logic of applying "nowrap"? The effect of nowrap is that long cell contents (e.g., a 4 word announcement subject) means lots of scrolling right instead of scrolling down on a mobile device.

I have a pull request with images here:

  https://github.com/sakaiproject/sakai/pull/3848

Bootstrap 3 doc:

  http://getbootstrap.com/css/#tables-responsive

[Hendrik Steller]

My guess:
Someone had a (maybe leftmost) table cell with lots and lots of text and no
overly long words to create a "natural" min-width for that column.
With wrapping such a cell could have become high enough that its content
wasn't fitting vertically on a small screen and that you couldn't even tell
that there were more table rows; that might look bad, especially if your
other columns only contain a couple of words, i.e. if you then scroll
horizontally from that giant cell, you might not even see any top- or bottom-
aligned content in the other columns' cells without scrolling vertically,
too.

That being said, having to read such a long text on only one single line with
horizontal scrolling also doesn't seem fun to me. Maybe that's why its gone
again...



On Freitag, 3. Februar 2017 11:26:21 CET 'Sam Ottenhoff' via Sakai Development
wrote:

[Sam Ottenhoff]

I agree. I think the logic for nowrap was to protect the display of data tables. It looks pretty terrible on our tool tables in Assignments and Announcements though, and I think we should get rid of nowrap asap.

--Sam

--
You received this message because you are subscribed to the Google Groups "Sakai Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sakai-dev+unsubscribe@apereo.org.
To post to this group, send email to saka...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/sakai-dev/.

[Laura Gekeler]

From the UX/UI design perspective:

The nowrap is purposeful since more important than seeing the table integral on a small device would be the ability of users to get the info—i.e., to scroll sideways. It’s less elegant but in the end, they could certainly see the data and fundamental usability takes precedence in this case. To put it simply, this is a feature, not a bug, as it were. 

It’s always a trade-off. The UX community doesn’t entirely agree about this, but general consensus is that there will not be total parity between certain elements. For wbsites like Wells Fargo’s banking app, it absolutely has to have parity of features across any device. But WF have a raft of developers and security experts. For an OS solution like Sakai, we will likely have to settle for relying on Bootstrap’s responsive approach, where, even if it’s not the most elegant at times, it’s 80% on target for 80% of the people and the rest can get their info, though it may not be an optimal experience. My take, anyway. 

From Nielsen-Norman: https://www.nngroup.com/articles/mobile-vs-responsive/

Mobile-Dedicated vs. Responsive Sites

Here are some of the relative advantages and disadvantages of these two approaches.

• Responsive sites can support a variety of devices and screen sizes with a single implementation. Dedicated sites are device specific: companies must build separate sites for mobile and for desktop. In contrast, the same responsive site can work well on a range of devices and screen sizes, from smartphones to tablets to desktops.
• Responsive sites offer content and feature parity (at least to some extent). Unlike for mobile-dedicated sites, at least in theory, the same content and functionality is available on all versions of a responsive site. (We saw that in practice, some responsive sites do leave out content and functionality on mobile, but to a lesser extent than mobile-dedicated sites.) No more need to decide which features are important on mobile and which should be left out. Though you still need to prioritize features and decide on their placement on smaller screens.
• Responsive sites used to be easier to find with a search engine. Mobile sites have a different URL than desktop sites, and originally they did not always inherit a high search rank from their sister desktop site. As a result, mobile sites may have appeared lower on search-engine page results. And even if desktop sites detected mobile clients and redirected the users to the corresponding mobile site, the redirect could take extra time and impair the mobile user experience (plus, it could also affect SEO).
  Since a single URL corresponds to all versions of a responsive site, responsive sites did not have to worry about SEO or redirects.
  Nowadays, however, modern search engines have learned to deal with mobile-dedicated sites, and they do send users to the mobile version of the site if one is available.
• Responsive sites save content and feature maintenance. A single site and a single content repository are easier to maintain than several separate sites. However, any interface change must be tested across all devices.
• Responsive sites tend to be more expensive to develop. Our clients report that the process of building an entire responsive site from scratch can be more costly than just creating a separate mobile site. Also, the development skills required tend to be more advanced for responsive sites.
• Responsive sites tend to be slower. Although there are techniques for improving the performance of responsive sites, because the same content is delivered to all types of devices, loading a responsive page can take longer than loading a mobile-dedicated page.
• Responsive sites work less well for complex tasks and content. Complex tasks are hard to accommodate on all devices equally well. Complex spreadsheets, comparison tables, and visualizations are often difficult to rescale well on small mobile screens. Mobile-dedicated sites may often decide to leave out such content, especially since users tend to avoid doing complicated tasks on smartphones.
• Responsive sites do not integrate well with existing third party services. If you’re building a site that relies on a separate independent backend service (e.g., booking engine on a hotel site), it’s often hard to integrate the interface for that service into a responsive site.

cheers,
Randy
……

Randal Sean Harrison, Ph.D.
Emerging Technologies Librarian

University of Notre Dame
115a Hesburgh Library
Notre Dame, IN 46556

(574) 631-0312
rhar...@nd.edu

randalseanharrison.com

[Sam Ottenhoff]

The data is seeable with nowrap enabled or disabled. I would argue that scrolling vertically down a page is far more natural than scrolling horizontally so nowrap tables are a bad default decision for Sakai 11+. My screenshots show the difference well: https://github.com/sakaiproject/sakai/pull/3848