Refactoring of Sass and optimization for multiple screen sizes

Here is a short video showing some of the changes thus far. Not much yet, as most of the work has been on refactoring chunks of the Sass code (colors in particular).

Here is the video:

Ta david.

Just a couple of points, i’ll reply in more detail later.

  1. Can you give an explanation of the principles behind the color rejig. Also, have you checked the CSS to ensure that all colors are SASS-ified?
  2. Is it possible to deploy this as a fork of SC so I can try changes live?
  3. The changes to the search box and sidebar icon aren’t really what i was looking for, but we can look at this in more detail later.
  4. there are some typography issues, I’m guessing you haven’t installed the SC fonts locally? (They don’t install by default because of licencing)
  5. re the popup, the crucial thing is that you must be able to over over the popup and click the headword. It’s not easy to get this right.

Hi Sujato,

Responses to your points and questions…

  1. The changes to to the color variables was brought about by a number of issues and goals:
    1. Consolidate all color definitions into one file.
      1. A few colors were defined locally in certain files, which is “ok”, but then these same vars were used in other files which made it very difficult to maintain as things would depend on the include order being correct, etc.
      2. In general, I have found it better to have colors all defined in one file, broken down into palettes if needed. It is a good idea to define Sass vars locally if you are positive they will not be used elsewhere, but colors should always be thought of as ‘global’ as you never know when someone else might want to use your pretty color in the future - in a different file (which would be bad).
      3. Note that I move these scattered colors into their own palette called ‘$palette-name-space-colors’.
    2. Create palettes using Sass maps (instead of pseudo classes in var names).
      1. The practice of having the name space incorporated into the variable name can quickly get out of control. So, instead of something like $saturated-dirty-yellow, we now have a ‘saturated’ palette (in the form of a Sass map) with the color ‘dirty-yellow’ in the palette. The ‘pastel’ palette also has a ‘dirty-yellow’ color, and we can create any number of palettes with their own flavor of ‘dirty-yellow’.
    3. Use functions instead of mixins to obtain useful debug info.
      1. The use of Sass functions is a powerful way to add debugging to the color code. You could also add in special processing of colors within the function if needed.
  2. The branch exists in git, but I have not deployed it - and would need assistance from Blake to make sure that goes as expected. Here is a link to the branch
  3. Understood. That is up to you of course. When using the site, I found it confusing to close the panel once opened. And even more confusing that a click on the page would close it. As for the change in roundness of the search box, I felt that most of the site is very ‘square’, and so the search box looked out of place with it’s oval shape.
  4. You are correct, the non-free fonts are not installed locally.
  5. Try the pop-ups out. I think it works better. I was actually having a hard time hovering over words while going up and down the page and that is why I tweaked it.

Currently (and not checked in yet), I am working on some changes to the @media handling and then will proceed to some of the individual points on that punch list we did a while back.

I hope you are doing well,

Thanks for that, your rationale for use of colors is good. i am aware that sometimes I’ve been inconsistent in how i wrote the CSS, so it’s nice to have a sane system for the whole thing.

Sure. We normally deploy to staging.suttacentral for this, but I’m not sure if Blake is currently using that for something else, so best wait.

That’s fine, it’s just that I wanted to do more with this. I think I discussed this previously: I want to move the green tab to the header. So if you want to work on it, let’s do that rather than messing around with it as is.

I like the round search, and precisely because it’s different!

Just so you know, according to Blake, I tend to be sometimes too vague and visionary (“Just make it how i imagine it!”) and sometimes too pedantic. Most of the details of the design I did myself, so you’ll find i’m very attached to them! (I’m working on it…)

What I do want is to make the search box behave itself a little better in responsive settings.

Hey, how about that, I just started your version on my local setup. It’s just like magic! I don’t understand git, but I love it!

So I tried out the popups, and as i suspected, I mostly can’t get my mouse to hover over the popup.

To be clear: when you hover over a word in the text, it creates a popup. You can then hover over the popup, and the headword of the dictionary entry is a link. This takes you to a fuller dictionary definition. This works reasonably well on the current site, but I can hardly do it at all on your version.

A minor problem here is that the link is for an external site, which is in any case broken. We have more recently implemented the dictionary on SC, so we should link internally. I just fixed this in sc_functions.js.

Oval is back!

Will work on this in the future.

I worked at Apple when Steve Jobs came back after being in exile from his company. He was all of the above and obviously had some very good results. I am guessing you have a much nicer balance of these qualities!

Will do.

Ahhh!! Now I get, but of course this leads me to the question: Why did a new user such as myself, an ‘expert’ in UX/UI, not ‘get it’? I added an underline to the dictionary word that shows up on hover. A subtle clue that the word is clickable. I put back the old location of the pop-up as well.

I’m glad you recognize this, I have often thought that I’d be better at IT design than Steve Jobs. :wink:

Yes, something that applies to a lot of the SC features. Taking a cue from, as it happens, people like Jobs or indeed Google, we strive to present the user with an interface that is as minimal as possible. I think i have mentioned this before, but it bears repeating.

The whole design strategy is to provide a reader with a clean, safe, beautiful space, where they feel comfortable and reassured, and can simply go ahead to read the suttas. To this end we put a a lot of effort into beautiful typography and removing clutter from the interface. I’d rather a reader not know something is there, then be pleasantly surprised when thy find it, than have then have to work out lots of UI features before they begin reading.

The downside of this is, as here, discoverability. So one UI thing that you might consider as you go is, how can we improve discoverability without compromising clarity? Obviously even the great IT designers struggle with the same issue, and there is no single solution; how many people know all the things you can do with a Google search box?

One idea I have thought of is to have once-only popups to draw attention to features, such as the sidebar. So when someone opens a text page a popup point to the sidebar and explains what it is for. But it is kind of clunky, and can itself be confusing, when someone just wants to read a text. Discourse does a pretty good job of using “just-in-time” notifications, on the principle that a user tends to respond well if they are reminded at the time they are using something.

We do have an introduction on the Home page, which is not bad if someone looks at it. Perhaps an explanation video for Youtube, like the one you shared with me, would be helpful as well.

Anyway, this all falls into the vague “just make it happen” side of things, for which see above!

Actually, I tell you what, this all misses the most obvious thing: get user feedback. How about I just ask the good folks here on Discourse what they think?