You can write todos to yourself in your scss by adding this line where you need to remind yourself of something:
This way you get a nice warning each time you compile, listing out all your warnings. You could also use @debug instead of @warn. The difference is basically that you can turn warnings off with the --quiet command-line option or the :quiet Sass option, and that the warnings look a bit different:
Usually it’s rather easy to tell if you are making a block, an element or a modifier, but one problem I’ve had again and again is a modifier on a modifier. Take this example:
We have these two buttons called .button--primary and .button--secondary coded like this:
..and looking like this:
This works great on the regular background, but as you can see we got a problem if we need to wrap the buttons in a red warning-box or similar. We still want the same look, but maybe not green on red?
A few solutions comes to mind:
We could add a modifier to .button--secondary. This just overrides the values that we need to change and we still need to add .button--secondary to the button. This feels a bit wrong and is very tiresome to write out. The code is however very logic to read and builds nicely on the BEM syntax.
We make a seperate modifier which is almost a duplicate of .button--secondary, just changing the colors that we need to change. This is also very nice to read, but feels very bloated since you are copying almost every style.
We create a .button--inverted class that changes .button--primary and .button--secondary if they have the .button--inverted class. Ex:
We could also nest the styling and say if .button--secondary is inside .box--notification we always want it to be white. This is probably the most dirty way to do it, but why not when you never want a green button inside a red box? The downside here is reusability and the location of the code. The big upside of BEM is the structure and that we from the name know the location of every class. If we suddenly start to nest classes we miss control.
I’m still not sure what is the best solution here. For now I’ve landed on alternative 3 mainly because the simplicity and readability. I’m eager to hear your thoughts and ideas. Give me a word on twitter or on mail about your thoughts.
Good design isn’t just how it looks, but also how it works. This is why code is an important part of our design process at Netlife Research. By coding we can control other important design aspects of our website like speed, animation and how the design “feels”. We can also test how the site behaves on different devices and browsers.
A much used effective design pattern is toggling. Toggling lets us hide parts of the content behind a button to make the content more easily scannable. The main problem with toggling is performance. Smaller devices have the most to gain from toggling, yet ironically, they also are the least capable of rendering it. We usually have two different methods for toggling of content:
Using jQuery's slideToggle. This is usually the best solution. The content slides in gradually and pushes the elements beneath it down. jQuery basically increases the height of the expanding element multiple times each second. On a fast desktop computer it looks like a nice animation, but on smartphones and tablets it can often become choppy and sluggish.
Turning a hide class on and off. We can achieve the same result by adding or removing a class with the display:none property. This works well on any device, but is very sudden. The element doesn’t expand: it’s either visible or hidden. This can at times feel confusing for the user, especially if you are expanding a lot of content.
Performance of transitions
Neither of these solutions are optimal in my opinion. Even though I’m not a developer, I understand that performance is an important part of the overall user experience. I therefore looked further into how we could have a toggle-solution that animates and works well on most mobile devices. With CSS3 we have the opportunity to animate and use transitions in CSS. We can use transitions to animate the height (or max-height) of the expanded element. But it would still perform badly since we don’t make use of the devices GPU (Graphic Processing Unit) for rendering the animation and moving the content underneath. The only CSS properties that invoke the GPU to make smooth animations on mobile are transform and opacity. The optimal solution would be to move the content away with the transform property. The problem with transform is that it just moves the content from it’s original position: it still takes up the same space as it did before, leaving us stuck with a big empty area. The same is true for all the GPU invoking techniques.
[quote]The more content the browser has to rewrite, the slower it renders.
Rewriting the content
Another important aspect of making smooth animations is that the more content the browser has to rewrite, the slower it renders. To avoid affecting other elements it’s therefore recommended that animated elements are position:absolute; or position:fixed;. After trying out a variety of different approaches I ended up fading the content in or out via opacity, and clever use of positioning combined with display:none; when the animation is finished. We still manage to push all the content underneath the element down, but with only one rewrite compared to a regular slideToggle tens of times each second. This performs nicely on mobile where the content fades in, and because it’s under the fold you won’t notice that the content is getting pushed down.
Example showing how a regular slideToggle works compared to the cssToggle-plugin
I’ve made my approach available as a jQuery plugin called cssToggle. In short the plugin checks if the element it’s called on is display:none; or not, then shows or hides the element via CSS opacity. When the animation is finished it sets the element to display:none; or display:block; based on it’s previous state. cssToggle also takes multiple options like position, speed, easing and firing functions after the animation is finished. This way you can easily tailor it to suit your needs. The plugin is about 1kb minified, and gracefully degrades on browsers that don’t support animations and just hides or shows the content with no fading. Grab the plugin on gitHub.
PS: If you would like a regular slideToggle(); on devices that can handle it, you could also use the excellent tool Modernizr and replace all your slideToggles with cssToggle when you detect touch-devices. While you’re at it I would also enable fastclick on these elements, to get rid of the 300ms wait before a click is registered.
When you are designing you get to a point where it suddenly says stop. You don’t know what to change or how to make it better. This is the moment I fire up Skitch and take a screenshot of what I’ve just made. I then start to annotate and draw on that. There it is. My magic trick. It might sound stupid. It might sound pointless. But the fact is that by doing this I take a step back from what I’ve done and evaluate it in a new way. Often I see things I’ve never seen before in the design. Sometimes it takes seconds to fill the canvas with notes. Other times it’s more a struggle to find anything. This is when you are getting close to something good, or when you probably need to take a break.
This might be a simple design-equivalent to Rubber duck debugging; to explain what you’ve done and your choices, and then hitting upon the solution in the process of explaining the problem. You’ve probably noticed it before when you’re talking to colleagues or writing a post on Basecamp about your design-choices. Suddenly you see your design in a different light and need to sketch out some new ideas. If you have a printer nearby printing it out and writing on that works the same way. Firing up Skitch and taking a screenshot facilitates that kind of thinking for me. Maybe you should give it a try as well?