Currently, the contents of the header area of SuttaCentral respond to 3 different breakpoints or screen widths. This causes “jumpy” transitions when the screen size is adjusted and does not use the optimal space for various items, especially the search text box.
Additionally, the items are all placed with a position of ‘absolute’ which further complicates the code.
I have fixed some of this in my recent commit, but I think the ideal solution would be to refactor the HTML so that it is more of a typical item-list menu with the contents flowing as inline-blocks. This will maximize the space for the various items, make for a smoother response in changes to browser size and help with code maintenance going forward.
Let me know if this is something you think is worth pursuing.
I’ll check the recent commit, but in general, yes, I have wanted to refactor the header to use inline-block. It is a crucial part of the SC design, and deserves detailed attention. Best look at that rather than mess with hacking what’s there. It will probably affect the js for the dropdown menus, I’m guessing, but that’s okay.
And, BTW, I still haven’t seen a compelling argument for minimizing the number of break points in an app such as ours. It seems to me that we have today basically a continuous spectrum of screen sizes, from 1" watches up to, what 80" TVs or so. Okay, so no-ones going to be using SuttaCentral on a watch any time soon, but you get the idea.
Shouldn’t we simply make sure that it looks and works ideally at every size, rather than thinking that it has to fit into an arbitrary set of computer/tablet/phone? I don’t know that more break points is a bad thing; apart from devs, few people resize their screens looking for break points, they just want it to work at whatever size they have it.
And on a more practical note, remember that we also want to move the sidebar tab on the text pages into the header, so this needs to be borne in mind when refactoring.
And another specific detail: the search box should disappear at small sizes. Just have the search icon, have a drop down search field when clicked, similar to Discourse.
This is very common these days, in fact many sites like discourse, medium and so on do away with the default search box altogether; mobile-influenced design. But I think a nice big search box is good for us by default, as search is one of our killer features. Or should I say, most compassionate features? There are heaps of suttas, and finding the right one is a hard task. Anyway, its not as if our header is overcrowded.
Yes, exactly. Site design, for SuttaCentral, should be:
Mobile first - I have already converted existing Sass for this, but now needs to be implemented in other spots. The pattern of “Mobile First” design is really to make sure the design ‘flows’ properly at all sizes.
Breakpoints by layout, not device sizes - The header is actually done this way and will work fine once the proper HTML is in there. The idea with breakpoints by layout is that the breakpoints are set to values where something has to change (eg when the icon changes to the wheel), otherwise the design is just allowed to flow
The changes are very subtle. The spyglass icon is now properly placed within the search box at all screen size. The search textbox fills the space (somewhat) better than before at certain screen sizes. And most importantly of all, and cant be seen, is that things are now ready to switch the HTML over to an inline-block list and then everything will just fit into whatever space is available (with a possible max screen size for HUGE screens).
Good idea and I will add this when the HTML is refactored.
Agreed - and points out why the ‘breakpoints by layout’ discussed above is important (ie “In our design, at what width is there enough room to display a good-sized search box?”)
Yes, just the header right now. Today, I planned to integrate the side panel tab into the header as well. My assumption on that is that it will always (and only) be visible in the header, but I will leave in current location as well until I get confirmation from you.
The sidebar will tab will only be visible in the header, but not always. This is because it is only relevant (currently and for the foreseeable future) on the pages where there is actual text. This could conceivably change, but we have not discussed uses for it elsewhere. So not on the Home page, “template” pages (/about, etc.), not on “division” or “subdivision” pages, etc. But you need not worry about where it needs to be inserted, @blake will do that when it is ready. For now we just need the design, ensure it is working well, and that it will function nicely both with sidebar tab and without.
Glad you like it. As for the drop down not showing up, did you try this when the browser window width was very small (ie when the search box was gone)? Here is a video of what I see locally: https://youtu.be/e-eMUpzzoxI
I did indeed. But it is working now, must have been some issue with the version or cache or something. The basic idea is now working fine, thanks. But I’d like to tweak it a little, it is not easy to get these designs right.
The choice is between a “drop-down” box such as you’ve implemented, and an “expandable search”. Dropdowns are commonly used, here on Discourse, on https://medium.com/, theguardian.com, and so on. I have never felt 100% comfortable with the concept, though, it seems a little bits-and-piece-ish. You click on the search icon and the search is ready to go, but somewhere else.
But if it is to be used, there should be an animation and a visual connection between the original icon and the dropped-down search field. It should flow; and most of these designs don’t flow very well. Also the search box itself needs some visual identity to set it apart from the page, some padding and shadow usually, but it is not always easy to make this fit nicely with the rest of the menu.
The approach that I personally prefer is the “expandable search”, which is the standard material design approach for apps: Material Design
It just seems more well-organized, the search and menu stays nicely within the header. I can understand that it might seem confusing if you click on the search and the menu disappears, but a nice animation should solve this; and anyway, if it’s standard android design it can’t be too unfamiliar.
As for the floated elements, they are no longer used except in one (new) case. The code now uses an unordered list for the menu items and search area. The home page icon section, is a fixed width div and this is the one use of a float. It is a two column layout with a fixed width left column (the home page icon). This kind of layout is critical to use over all others since it allows the 2nd (fluid) column to have a width of 100% which can be precisely divided into chunks of % widths that exactly fit in the space (at any screen size). Other 2 column layouts can makes things ugly for calculating % widths - massively complicating the CSS code.
So, for example, to add in a new item to the header, it is a simple matter of changing the % widths of the items for the 3 breakpoints: 1) full header 2) #1 - “sutta central” 3) #2 - search box
Okay, that sounds fine, thanks for the explanation.
I like this approach better as well. It is easy to change the location of the search box to wherever we like. And then we can change the ‘home’ icon area to be a “←” which allow the user to ‘cancel’ out of the search more cleanly - I am guessing from our discussion about the side panel exit, you might have other ideas, but Google agrees with me on this one - let me know what you think and I can implement all of this.
Hmmm, wanted to upload a screen capture to show how I now have the ‘hamburger’ icon and the ‘home wheel’ icon positioned next to each other, but could not. I will upload to oDesk for you to view. My question is: On those pages where it needs to appear, is this approximately what you are looking for? Another option would be to eliminate the ‘wheel’ icon and make ‘SuttaCentral Home’ the first item in the menu. Your choice.
I have just checked in code that implements the following:
Header refactor is close to completion - just need review and comments (if any).
The ‘hamburger’ icon is now available in the header. It is fully functional and will activate the side panel, dim when it should not be available (disabled), etc.
Search box at small width is now (nearly) 100% of the available width and fixed at the top of the screen as we discussed (ie not offset down below the header). Much more difficult than it might appear due to rules of absolute positioning, forms, etc… but it seems to be working. I have left the ‘hamburger’ icon visible, but we can bury that too if desired (easy to do).
Refactored the media queries due to some strange behavior. The important result of this change is that all media overrides are now in one file (media-responsive.scss) rather than scattered throughout the various sass files. This is a point of contention in the blogoshpere as to which method is preferred, but I have found in my experience (and others concur) that when a project reaches a certain size, then the one file method is much better for a variety of reasons. SuttaCentral is definately big enough for this change and it solved numerous other issues (ie it really had to be done). I can give a LONG explanation if there is any interest.)
But I’ll leave it to you to decide what’s the best way to achieve this.
Looks great, very nice. I know well how tricky doing apparently simple things in CSS can be, which is why I’m getting you to do it! Again, a couple of details:
Can we leave both the hamburger and the Wheel visible? In other words, we only cover up the Menu? I like the idea that we leave the wheel there as a constant, somehwere you can always come home to. On the other hand, this is not standard behavior on Android, where the search bar takes over completely…
The movement when you click is not entirely smooth. I’d like to see an animation, the search bar growing over the menu (see below). More important, there is a slight shift in the position of the hamburger icon when you click to expand the search; can we make sure this isn’t happening?
This is possibly not necessary, but at VERY small sizes the menu items clash with the search icons. In particular look at how ABHIDHAMMA spills over and obscures the search. (Fans of Early Buddhism can take this as a metaphor if they like—don’t worry, in-joke!) This could be solved by making the text of ABHIDHAMMA a lower z-index so that it could not spill outside the menu-item box.
I’m sure that would be very interesting, but I am quite happy to take this on trust. I think I mentioned before, the SASS structure was done by a volunteer developer who is not with us at the moment, and while he did a good job, neither Blake nor I have been involved in it very much, so we don’t have any particularly strong ideas how the SASS should be organized. At least, I don’t think so, perhaps @blake has something to say.
Incidentally, the Aussie press is full of how Google is about to rejig their algorithm so that non-mobile friendly suites are dropped down, and people are saying this will make 50% of Aussie business sites disappear. Not SuttaCentral, though!
A final bug: there is some nastiness that is doing terrible things to the Pali text pages. Look at eg pi/dn2. When you open the page it is fine. Then for some reason big white gaps appear in the text. Somehow from our critical apparatus a table is being generated that is invisible but messing up the text. Check up <span class="var"> and <table class="deets">. I’ve never seen this before, so I guess something is interacting with your new code somehow. Probably a simple fix.
Finally, as this part of the header job is finished, I would like to look at a further detail: the animations. I’d like to make the whole header provide a fluid, consistent experience, which feels buttery and responsive across all devices. So we should carefully check things like how the search box expands, how the sidebar expands, how the different elements are layered in vertical space, and most important, how the menu expands.
Currently the menu behavior is great functionally, but it is jagged and inconsistent. Sometimes it scrolls, sometime it jumps, sometime it jumps down then scrolls back up. I understand that this is probably because of figuring out the layout of the menus, with different numbers of items and columns and so on. It’s not a trivial job, but one where we can do better, I think. @blake put a lot of work into this, so it would be a good idea to discuss with him how to proceed.
Here’s a list of details in the animations that need to be looked at, it will give you a better idea of what I am looking for:
The sidebar animation is nice, it slides out and back smoothly, fast to launch, slow to finish. One detail, though: it shows its shadow even when it is hidden, this would be better off gone.
Viewing at a normal-ish screen size, when I hit SUTTA the panel appears without animation. The dark background appears a little later, and it glitches unnaturally over the next/prev links (the round regions at the bottom of the text pages).
If, from a blank start, I hit Vinaya, it glitchily progresses down. Except sometimes it also appears fully-fledged, without scrolling. And sometimes it scrolls smoothly.
If I go from SUTTA to VINAYA, it scrolls down, and if I go from VINAYA to SUTTA it scrolls back up. Fine. But then if I am on VINAYA, close the menu, then open SUTTA, it leaps down to the place the VINAYA would have been and scrolls back from there.
There is a z-index glitch with the division/subdivision pages. (eg /dn). When you hit the menu it darkens some of the table rows, not others, depending on the zebra striping.
If the sidebar is open, and you hit the menu, it appears over the top of the sidebar, which is correct. However the darkening of the sidebar happens after the darkening on the main page.
We now have the header disappearing when you scroll down, and re-appearing when you scroll back up, which is correct. However, the behavior is erratic; it seems to take quite a strong scroll or upwards movement to bring back the header. It should happen with any upwards movement.
There is a minor glitch in the new search box: when you hover over it it expands slightly to the left. This happens both for the standard box and the new “expanded” one.
Also, the search box no longer plays nice with the auto-suggest dropdown.
I’ve been using Google Chrome’s device emulator to check it out on smaller screen sizes. I think @sujato mentioned it in part already, but at small screen sizes the header becomes too wide, which either results in the content being correctly sized, but the header extending past the side of the screen, or the header being correctly sized, but the content only taking up about 70% of the screen with a grey bar down the side.
Chrome’s device emulator also emulates touch, and it reminds me, we really should have swipe for pulling out the sidebar.
I agree with this move. I feel the dev who set up the SASS setup was a little too keen on splitting stuff up over dozens of files (but before then all css was in a single file!). As a rule as I worked with his setup, I tended to consolidate files.
Ah yes, the header menu. At the moment in the file static/js/header_menu.js, there is the function ‘adjustColumns’ which is responsible for making the columns properly fit the available space. A job I don’t think is possible with CSS alone.
I kind of get the feeling ‘More javascript’ might be the best solution! With more javascript we could make the lists tile better and minimize white space.
However if the current code is interfering with css, you can always stick a ‘return’ at the very start of ‘adjustColumns’ to disable the dynamic adjustment.
Definitely with the swipe, I should have mentioned this. We should in fact test thoroughly with touchscreens on tablets and phones. I still use my phone rarely, and tablets never, so hopefully @Moneycito has more experience with this.
Many of the items in the punch list mentioned above regarding the header are in progress or done. To properly finish it off, I will need to get the non-free fonts working locally. I am using the ‘free’ fonts and this accounts for a number of the issues that you are seeing that I am not (ie menu names overflowing, etc.).
@blake, maybe you can send me a paragraph on how to make this happen? Thanks ahead of time.
I also do not have elastic search working locally and this has not affected anything thus far, but we might want to do both at the same time if it requires a Skype session.
It would be a good idea to install elasticsearch; in addition to the dropdown, the search results pages will also need some attention, responsively speaking. We have instructions on our wiki:
As for the fonts, try setting your local.conf to
nonfree_fonts: True
I’m not sure if anything else is required. We set these off by default so as not to spread the proprietary fonts (Skolar and Lumen) around too much. Just remember they are not to be shared, but are for development use only.
- let me know what you think and I can implement all of this.