The idea is that as a user moves through the site or a text, the navigation reflects the place they are at.
Currently this would not be much use with the ToC on SC, as they are inline at the top of the page, a layout that is optimized for mobile. But perhaps they could be made into a sticky sidebar on wide screens?
A similar pattern can be applied in a sidebar:
So these are just some random ideas. Is there anything you’d like to see? Are there examples of sidebar or ToC navigation that your like and we can maybe learn from?
I believe this is a great idea. I see some readily available real estate in the current UI/UX that shouldn’t require too much rework.
The words/placeholders at the top could be clickable and take you to that section of the website. This would allow people to see where they are, and allow them to more easily navigate back to areas where they just came from.
For Mobile, you can have it show a small portion i.e show Sutta| Samyutta Nikaya -> and have a scroll bar with a -> or a <- on either side to let you move over to the hyperlinks that you can no longer see, since mobile shrinks it.
The only reason I recommend not using the side bar option above(while it is cool and makes sense) is because you cant really see your place on mobile that way. When reading a Sutta and having the placeholder sidebar. The sidebar being open would take up most of the screen.
Please see below for a crude low fidelity example for PC.
The animation video does not appear to show anything…?
Navigation enhancement would be awesome. It’d be better to have alternatives to and more information than can easily be obtained by reading the URL, pulling down the current non context sensitive sidebar, flipping to another browser page to check a map… On a mobile screen, it’s currently easy to bounce yourself out to somewhere else.
Something like that. But maybe enhancing what is already there rather than a whole new thing? On the other hand, maybe also a whole new thing!
Okay, interesting, so you’re proposing we essentially use the top app bar as a breadcrumb menu. Hmm, interesting.
This means we lose the current content of the top bar, i.e. the sutta title and author. We could maybe add it as another filed in the top header. FYI, we are already planning a second row in the header, this will include the things covered currently in the three icons at the top of the page.
I alluded to this in the OP, but our current plan is that the “supertitles” (which in your mockup are “linked Discourses 12 // 1. The Buddhas”) will be linkified and can click to take you to that section.
The reason for favoring this over a traditional breadcrumb is essentially horizontal space. Basically, on mobiles, horizontal space is always at a premium so arranging things vertically is always easier. The navigation indicating your position is dynamic and unpredictable, and as your example shows, a context like the Samyutta Nikaya requires a good many sections!
None of which is to say this can’t work, just considering implications.
This is very true. The only thing you could do is, at least on mobile you could open the sidebar and see your place, I guess that’s something.
Yes, something like that.
It works for me. If the Codepen doesn’t work, try opening it in a new tab, or click over to the reference pages.
To me it doesn’t look overly crowded in this example. Rather nice! But like ERose, I am not primarily a mobile user. I do use it on mobile, though.
I know people who have never ever looked into the left sidebar on SC. Seeing the top line in the header in this way, even those may get a feeling for how the canon is structured, just by seeing it many times.
I like this mockup Bhante. It would definitely work for PC and tablet. Just need to have it scrollable somehow for mobile e.g having a floating larger < or > on the far sides to allow the user to access hidden breadcrumbs.
And I know it’s just a mock up. But you might want to consider making the breadcrumbs look actionable/clickable. Such as showing them in a different color like the traditional hyperlink blue with an underline, for example.
I tend to know where I am since I get to places by searching for them. Therefore I am always “in the sutta I searched for”.
What I would like is a suggestion about where to go next…
For example, if I see “root of suffering” in a segment and hover over it, I should see a link that takes me to all the suttas that use that key phrase. This would allow me to get lost in the suttas, immersed and happily studying for hours on end.
I think this is an excellent point, however that’s not related to the conversation here, is it?
For some users, they really do want to know where in the canon they are. Or more importantly, they want to be able to look around at close by suttas. With the current site, if you want to poke around nearby suttas (other than moving to next and previous) you have to start at zero.
I would expect a breadcrumb trail to be at the top of the document, not in the header. There’s no need for the breadcrumb trail unless you are leaving the document, is there? Wouldn’t opening up the sidebar be the way to tell where you were while you were reading the sutta, assuming it started to represent your location?
There is some logic to the trail ending and the next thing on the page is the title of the sutta you are reading. An added benefit is that on mobile, the breadcrumb trail would just wrap onto a new line.
Should there be some user stories to justify how the navigation would work? For me personally I take it as a given that I want to know where I am in the canon and I’m always surprised to be reminded that if I didn’t navigate to a sutta through the left sidebar, then the left sidebar does not tell me where I am. But I wonder how important this is for other users? Getting back to @karl_lew 's point, knowing where you are in the canon isn’t important for all users.
I think the sidebar really needs & actually eats a lot of screen real estate, and seemingly, it simply can’t live without it [always demanding ample amount of white space at its disposal], a kind of behaviour which is in stark contrast to “well content, … easily satisfied” as mentioned in the metta sutta
I don’t know and I am not trying to say whether it is a good or bad thing to increase “functionality” of the interface by reducing the white space because, imo, un-clutterness is also an important factor.
For example: I think the following screenshot is Ok, eventho’ there’s lots and lots of white space.
Browser magnification should never be used to magnify text on the page (if this is needed, it signals a bad website design).
In your example above (the Discourse forum software) you can control the text size independent from the rest of the page elements by user settings—preferences—interface—text size, and can even make it permanent across devices.
If you let the browser scale things up it will always break the page design.
What I would like to see on the SuttaCentral site is a button to scale the sutta text larger, while retaining the current width of the borders (to an apparent page width of a book at arm’s lenght).
Or some magic—to always display the exact same apparent size and width of a text, based on the device (a mobile screen is usually twice as close to my eyes as a tablet, and four times as close as a computer screen, roughly)—whichever you prefer
Also, the current number of character per line at 80+ is not optimal for reading on my tablet (mobile has it’s own challenges, but the text flows better, even at ~35 characters per line).
Text should ideally always be presented to the user at the exact same apparent size, regardless of the form factor of the device, taking into account the viewing distance.
Whitespace on wider screens is a result of the fact that there is an optimal number of characters per line for a given typeface (anything more than this number and the text becomes very difficult to read).
I mean, I have a 28’ 4k screen, and I resize every website I visit, so. My eyes are only really clear at about arm’s length away, so the screen has to be that far, and the size adjusted accordingly.
The line length was deliberately chosen to be at around the maximum of good practice, with the understanding that it is always possible to narrow the column, but not to broaden it. Readability studies show maximum speed and comprehension at up to 95 cpl:
Having said which, I haven’t really used tablets all that much so maybe it’s a different set of constraints there.
Ideally, but that’s a lot of variables right there: font size, screen width, column width, screen resolution, color contrast, personal preference, eyesight, sitting posture, ambient light. You can go crazy trying to cater for every situation and end up with something super-complicated and fragile. Currently, the way the sizing and so on is set up basically follows the methods used by Google for Polymer, we tried to stay close to defaults as much as we could. One thing I did change was to increase the default font size a little.
It’d be worth revising this at some point, look at the latest best practices for resizing things.
Personally I’m not thrilled about a text-resize widget, as I believe it breaks Sujato’s first law of website design:
Thou shalt not implement in thy website that which is already present in thy browser.
However, it seems as if from what you say, maybe this doesn’t apply in the case of tablets. But I’m not sure how much of an issue this is: is it a crippling issue for tablets? Given that tablets are a small percentage of users, does this affect a large percentage of tablet users?
My apology, Bhante. By sidebar, I mean the “post-choosing slider”.
No, Bhante. it’s not much of an issue for my tablet, because I don’t normally increase the font size. I just accidentally found out by some monkeying around. But, may have some effects on some who need a larger font size, and yet not techie enough to delve into the settings’ font customization options.
Percentage may be small, but it may surely represent a large population.
Edited: (tablet users screen-shot added) those who use at least once per-month.
What I’m trying to say is that, On increasing the font size, above some threshold, the sidebar treats the tablet screen as that of a small phone, by minimizing the sidebar while there is much space in the margin.
It is actually treating it as a desktop with a tiny display, and this is exactly why it is not intended to be used in this way (responsive design tries to adapt to a smaller viewport created by magnifying the browser display, but it reaches its limit sooner or later and then breaks miserably).
Responsive web design by itself is not panacea for all form factors (but it should enable the web site to adapt to the constraints within the different sizes of a single form factor).
Discourse has a separate layout especially for mobile, where space for navigational elements is scarce and needs to be handled differently (and there is a whole lot of magic behind it, because it is needed for this type of an interactive app, while others can do with just a single responsive design for all form factors).
You can select mobile view on tablet or desktop, but it is neither intended nor well adapted for this form factor, because now most of the screen real estate is underutilized (e.g. only one user icon next to the topic, the post navigation tool covers the text, edit pane preview window is hidden,…)
But that doesn’t resize the chrome, just the content, right. The tabs and navigational elements of the browser itself are absolutely tiny on large monitors.
I have encountered many users with diminishing eyesight arguing for a larger screen to help them see better, only to end up with a scaled down physical resolution (which looks horrible on LCDs), because the screen was larger, but so was the native resolution that made every element on screen microscopic.
I firmly believe that this is an OS’s job, to scale the entire display to fit the size, resolution and viewing distance to the same apparent size for the user (and offer the user an option to scale the entire display).
And therefore I see the browser magnification tool as just a crutch for badly written web sites that don’t scale well or at all (I’m horrified when I see people reading such sites on mobile, and two-finger resize all the time just to be able to see anything).
Interesting article, and the responses even more so. But the main feature for me is not the reading speed but the overall feeling of immersiveness. Much like as with the book designs, where you just feel when it is perfect—when there is no more book, nor page, margin, text or font left—just the experience of reading itself.
I use tablets and mobiles exclusively, and the current layout at 80+ characters per line, with the current font size doesn’t really work for me on a tablet (it’s difficult to put it into a metric, it just doesn’t feel right).
But it works surprisingly well on a mobile that has ~35 characters per line, which is on the low side. Perhaps the portrait orientation works better with shorter lines than landscape does with longer ones?
Sorry, we are speaking at cross-purposes: I was discussing the SuttaCentral site, not Discourse.
For Discourse, we basically just use the defaults with some minor tweaks. Given the complexity of the app, I’d recommend bringing up such issues with the Discourse community, they are very responsive to suggestions. We shouldn’t try to change anything drastic without understanding first why things are the way they are.