-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
General discussion about UX #8
Comments
While testing user settings yesterday, I was quite concerned with an UX issue related to font size. AssumptionFont size will probably be a global setting i.e. when the users set a specific font size, they very likely want it to apply to all publications they’re reading. At least this is what happens with a lot of (existing) Reading Systems. IssueWe have quite a significant amount of samples for which the base font size is really small:
(Of course, sizes are relative since What’s worse is that, in that case, we’ve got useless settings (the smallest one), especially as there is a floor for As an aside, this is incredibly painful as a user (and bad practice as an author). I don’t have vision problems but ProposalMap every publication relative to our settings, which means for instance:
What happens for the user?This process would be completely transparent to the user. If level 3 is set, then all books will have a base font size of Counter-arguments
Alternative options
Technical detailsGetting the base font-size
Defining the type scale used by the authorTurns out we can get a pretty good average by checking the base In that case, getting the type scale is a one-two punch:
* Of course this is related to our specific CSS normalize. I’ve been able to retrieve a good-enough author’s type-scale for 90% of our samples. For other publications, we could still change the type-scale on a per-heading basis. |
Useful analysis, thanks! As a user, I would expect the "200%" option to result in the document's text (including interline spacing) to be proportionally scaled by a factor of 2, relative to the original publication's styles. I would also expect (or learn to tolerate) slight discrepancies in the visual output of different publications, because of text size variations in the original documents (as defined at authoring time by content creators via CSS). On the whole though, my user experience would be pretty consistent and satisfactory. There may be uncommon instances whereby scaled documents would look unreasonably smaller / larger (compared with the rest of my ebook library), in which case I would be forced to adjust the system-wide option (and restore my favourite setting when switching to other, more regular publications). I wouldn't expect reading systems to be particularly "smart" in this area (such as attempting to automatically detect unreasonable size discrepancies), because I would recognise that modern interactive multimedia publications ; just like gazillions of existing web pages ; can offer significant stylistic variations. However ; just like with web browsers ; as a user I might expect the reading system to provide a "enhance readability" mode that would present a minimalist and normalised view of rendered documents. Irrespective of how this special "reader mode" would operate under the hood, the "dumb" text sizing method based on a simple scale factor is in fact (based on previous implementation experience) not as easy to nail-down as it sounds. For instance, using CSS alone was not sufficient, and we had to programmatically walk the structure of loaded documents (HTML DOM) in order to apply the scale factor to individual nodes, based on their computed font-size (expressed in absolute points or pixels). |
Thanks for your thoughts, @danielweck, this indeed is a complex issue and I must admit I have mixed feelings about the proposal, especially because of edge cases. So, as usual, I've taken a look at other RSs—“In case of doubt, check interop.” iBooksFirst and foremost, authors can opt-in using the When this metadata is set to true, iBooks will respect:
set in the authors’ CSS. What’s interesting is their “FontsPresets.plist”. Basically, the authors’ explicit font-family is the first When the user sets another font, then they customize per font ( It’s also noteworthy that the user preferences for In other words, the user picking another font is the signal for some kind of normalization. KindleAccording to the guidelines, the following font fixes are applied during the upload process (KFX):
Source: Kindle Publishing Guidelines Version 2017.3, page 26. In other words, they automatically normalize for Enhanced Typesetting. There is neither an opt-in nor opt-out mechanism. But they can obviously do that during conversion. Play BooksEPUB files are processed, this is clearly visible when side loading a file in the app. Their pagination is quite different from iBooks/Kobo/Readium and at some point, you could find EPUB files were actually transformed into fragments (by using Android File Transfer for instance). Looks Like they’re managing If you take a look at this stylesheet, which is the one I can retrieve for one of my files, you can see Overdrive (online reader)The author’s CSS is a theme, with an extra checkbox the user can check to normalize font-sizes. Applying any other theme than the publisher’s automatically normalizes this text scale. Custom if for more targeted settings (font-family, line-height, etc.). KoboLooks like the setting is relative to the publication base In summaryWe don’t have the luxury of a specific metadata or the processing/conversion of EPUB files so we basically find ourselves in the Overdrive/Kobo situation. As far as I’m concerned, I still have mixed feelings about this issue: Overdrive’s approach seems the most sensible at first sight, iBooks mapping level 1 to 1em is probably a good idea as well (the |
And we must of course anticipate User Agent Properties ( It is my understanding that in iOS for instance, the UA prop is very likely to retrieve the value set in a11y settings: [Edit] As a clarification, I guess we’d better at least be in sync with the OS/UA setting e.g. if the user sets a bigger system font-size, it maps to our level automagically so that our settings are not relative to this global setting, especially as those properties will be exposed to authors. |
For the record, other styling related to
When the user Kindle Enhanced Typesetting is doing this already, I could manage most cases using CSS so it’s up to implementers. Would those normalizes be useful to you? |
We’ve been discussing IssueIf we don’t provide a base As a consequence I moved AssumptionIt would probably be a lot better to adjust So I explored dynamic leading, using a
“Algorithm”The
To sum things up, the
ResultsI can get pretty solid results for our font-stacks. Here is the I’ve checked our other font-stacks and the computed value @ 100% would probably be the one I could deem “optimal” for each typeface (in terms of typographic color). The major benefit is that it could help us avoid defining an optimal Caveats
@danielweck I know you managed that in Readium, can you see other benefits or points of failure and caveats? My quick and dirty test webpage is available as a gist if needed. |
After further testing (±150 typefaces), I can report this works well except for a handful of typefaces e.g. American Typewriter, Libre Baskerville, Bitter, Lexia, Roboto Slab, FF Tisa Pro, etc. In other words, mainly slabs with a large x-height, thick stroke and medium character width. We’ve got nothing in CSS to check the stroke for instance, so the only solution would be factoring in a thickness factor to make it perfect… I’m pretty sure this “algorithm” could be improved though, and I’d really like someone to review it because confirmation bias is a thing. |
very useful analytical approach, thanks! |
We had a quick (private) discussion about tables yesterday, before the call, and we didn't have time to talk about it so I guess it’s worth listing it in this UX issue since it isn’t entirely in Readium CSS scope. So, tables, the worst e-production nightmare nobody knows how to turn into a happy-end. @camill-a has encountered a really long table (4 “pages”) during user settings implementation in the iOS testing app and it’s just vain to try managing that in pure CSS. Tables are notoriously difficult to manage in a responsive context but well, publications can have a lot of them. For inspiration, here is a recap and listing of solutions by CSS-tricks. @HadrienGardeur and I agreed that limiting the table size (if needed) and opening it into an external view (like non-linear contents) wouldn’t necessarily be a bad option to improve readability. But there’s probably other options which can be discussed. As an author, I wouldn’t mind if the Reading System did that. To be honest, it would even suit me fine for various reasons*. Footnote* The major reason being that I’m often being forced to fit super complex tables for which there is no chance at all they will display correctly, even in a 27" screen. |
As always, how does a reading system know whether it is adequate to "take over" the presentation and interaction behaviours for table (or any other large / complex content fragment, likely to be problematic on smaller displays). For example, content creators may decide to include their own handling, like a clickable thumbnail preview which enlarges the full content in a "smart" / responsive way => how can the reading system interpret such cases as "leave me alone"? |
Jiminy, you created a fine prototype of "responsive tables" for the OECD this year, presented at the EPUB Summit. Would it be acceptable for authors to follow some design pattern promoted by the EPUB production community, based on this work? |
@danielweck Yeah I know, this is the main issue. At least I can say people expect iBooks to open the table in a modal (double-click/double-tap) so if there are scripts out there, they would probably hijack this event. @llemeurfr I doubt it if there is no “plug-n-play” script out there. And even if there were, you still have to deal with Reading Systems which don’t support javascript (per EPUB 3.1 spec, I saw that it would be expected only in scroll view by the way, not in paged view). And it gets even worse with ePub 2 backwards compatibility as overflow won’t work in a lot of devices and apps so you can’t even use that as a fallback. So, complex tables often end up being images, which was a Kindle recommendation at some point. I also hit performance issues pretty quickly with javascript at the time (tables have a lot of nodes) and it doesn’t scale at all, you have to create an html file for each table at some point. So I wouldn't hold my breath about someone finding a solution that can work everywhere, with stellar performance when JS kicks in—and nobody seems really interested in tackling this issue, at least that was the case when I did research for the OECD proto. |
Just recording a thought here, as I discussed this this morning: Once again, the main issue is we don’t know what the author is doing. On the other hand, if we don’t find I know this might be naïve reasoning but on the other hand, the more I’m looking at feedback, the more it feels like a significant part of authors are expecting the RS to do such stuff because they can’t find an interoperable solution anyway. |
Is this issue still useful considering we now have apps and the UX discussion should probably happened at the app level? Or can we close this issue? |
So let’s close this one since those things belong to apps. I re-read the discussion and only the handling of tables could be re-issued in the apps’ tracker i.e. we may not want to do a lot there but maybe at least open them in a dedicated web view on double-click/double-tap, as some apps have been doing for a while. This would also allow for So maybe let’s open a dedicated issue for each app if we did not reach consensus yet. @HadrienGardeur Can you recall reaching a consensus on this one, when we discussed |
Although I do think this repo might not be the best place to discuss User Experience—it’s more implementation-centric—, it is worth having a general issue imho. Indeed, we can’t have a clear separation of concerns there, the CSS design impacting UX and vice versa.
While discussing Readium CSS during the Readium 2 conference call yesterday, UX has been one of our major concerns. And I do believe @danielweck and @HadrienGardeur are right about that: defaults, themes, user settings are not just styles we add and remove, they are tools we offer to users. Now, one of our top priorities is building a good experience so that users can focus on, and enjoy reading electronic publications.
UX in general, and user research in particular, are by no means easy. They also require quite a budget—please note there has been some DIY tips and tricks lately though. Minimal (DIY) usability testing is I guess critical because very little user research on Reading Systems and ebooks has actually been published so far.
Anyways, Readium CSS design is pretty modular, with a lot of user settings. It doesn’t mean developers have to implement all those settings, obviously. What we want to offer is flexibility, so that implementers can do as they wish:
There are small details we must take into account. For instance, what we discussed yesterday:
px
orpt
and the user setting won’t work). Do we normalize as soon as the user sets a different font-size or do we ask them to opt-in via a checkbox?Of course, there are a lot of other UX issues we’ll have to deal with as we go along. So please feel free to use this issue to report and discuss them. We will then be able to make recommandations related to UX in docs.
The text was updated successfully, but these errors were encountered: