Own your grids

Treehouse pulled a smart one on frontend frameworks for april fools. While its funny, if you look at the grids documentation, you will soon realize where this is all headed. This project made it even more clearer to me that using presentational classes in your markup is not the right way to go.

New devices

What if there is a new device in the market and you suddenly have to support a different layout in it? Create a new grid, backtrack your markup and add in corresponding classes to make it behave? This approach is largely unscaleable. Also, this scenario is not much of a hypothetical situation.

When I wrote my last post, I was pretty convinced that using @extends for grids is a fantastic idea. It solved some major problems, namely

  1. Semantic class names
  2. Cleaner, readable markup
  3. Performant CSS

Performance, really?

Based on this question from Hugo, if you GZip your CSS files, it wouldn’t make much of a difference whether you use @extends or @includes. Ian Feather’s article has some numbers to this effect. Also, as Scott Kellum points out in that gist, using @includes is more predictable.

Don’t abuse @extends

@extends have always been problematic when using with @media. Apart from that, when I published my plan to use @extends with grids, it was met with some criticism from the community. After some digging into, I realized why. The screenshot below shows what an @extend could do for your debugging.

Debugging with @extends

See how all those styles are chained? Selector chaining = debugging nightmare.

Mixins for semantic grids

All frontend frameworks come loaded with mixins that enable you to create semantic grids. Defining custom breakpoints, custom semantic grid classes allow greater control over your grid behavior. I don’t like this approach however, because the coding is verbose and not very intuitive. It feels like too much work primarily because of the way breakpoints are designed in these frameworks. Of course, you could use something like breakpoint to get the desired behavior. I highly recommend it. You could also define your own mixins to make writing media queries easier.

Content is King

Some design options are tossed into the bin because the default grid does not support it. Your grid, your typography, the media query breakpoints that you define for a website are unique to that specific case. Anything generic is either too much or over simplified. You are either shipping code bloat or spending too much time overriding defaults. Grids are personal. As a designer, you should own the grid you create and put out there. Borrowing someone else’s grid and reverse engineering your design into it is counter productive. Base your design around your content and target audience.

Build your own grids

The initial idea was to have semantic grid classes. @extends didn’t work. @includes were too much work. Then I realized that default grids shipping with frameworks were restrictive to design. People suggested that I comment out the grid file and use a better system to create my own grids. Some of the options are

  1. Susy
  2. Singularity
  3. Jeet
  4. Zen
  5. Gridsetapp - paid product

Out of the above mentioned ones, singularity is my favorite. It enables you to do some crazy stuff with very little code. Results in semantic grid classes, no code bloat and a very powerful design process. I will expand on singularity in a separate post.

Build your own grid-systems

The biggest takeaway from my journey of analyzing grids is: The only system that will work for you is the one you create for yourself. Some grid frameworks seem too simple. Others take a while to wrap your head around. In effect, its all about creating meaningful numbers for grid columns that allow for visually appealing designs. What this doesn’t take into account is personality.

I see a lot of people moving away from generic frameworks and building custom solutions that fit their personality and their requirement. The invention of Sass and related technologies enable you to build your own frameworks. Grids should be part of this customization. Grids are personal. Own your grids.

Notes from Geek Night

  • Google’s App Script allows you to build on top of google docs/calendar and other applications and extend their features
  • Top Shop has a hangout app where you can drag & drop runway  items and create an outfit you desire
  • The only place on the internet where gmail’s API is open and available
  • Singularity Changelog is the best place to learn and use the latest version of the modern grid system 
  • You can do some crazy stuff with singularity and math - Singularity off canvas  and span 12.5
  • Hypervisor A piece of software/hardware that creates and runs virtual machines
  • Amazon app stream is a recent service that runs complex computing on the cloud and sends only the pixel painting work to the client’s browsers. This enables some demanding applications such as games to run even on low end mobile phones.
  • TideSDK - Create desktop applications for windows/mac/linux but develop code in HTML/CSS/Javascript
  • Core OS, built on top of a minimal  OS, enables massive server deployments
  • Docker helps you create pristine environments as sub processes for development. It takes advantage of such process isolation but tries to enable persistence of required data after the environment is destroyed. Its an exciting feature that allows providing for multiple parallel dev environments that are clean and without changes from other devs.

The internet and advertisements

I disagree when people say ads are annoying and “get in their way”. I dislike it that we are looking for ways to circumvent ads and consume content alone. Ads are annoying. And they are everywhere. You cannot read a blog post, watch a video or listen to music without being slapped in the face by an ad. Any consumption of quality content is accompanied by a proportionate amount of advertisements.

However, ads by themselves aren’t as bad as we tend to think. They help sustain a lot of these services and do some heavy lifting for us. This article is about why you should allow ads to exist and how it is part of the system. It is also about why using a plugin like readability or ad block plus is not in the best interests of the web ecosystem.

Creating software costs money

Even if you ignore the amount of expertise and person-hours put into the making of an app, it cost money to maintain it. They need cloud servers, backups, databases, disk space, hosting providers, domain names and a whole lot more. Someone has to bear these expenses. And if you get to use it for free, who will pay?

Ads run the internet

Take Gmail for example. Using gmail for free is a huge privilege. One of the best companies in the world has created a high quality email application that you get to use for free. I would gladly trade in a portion of my screen space, and tolerate a minor inconvenience in return for using gmail…for free.

We don’t realize how big a deal this is. Imagine if you had to pay for email or dropbox and there are no free plans. I doubt if we would be exposed to as many apps or learn so much, had content not been free.

Offline advertising

The internet is not any different from the various ads we see on television, billboards and other media. There are so many ads in radio, for example, but we have trained our brains to tune that out. We are used to circumventing the ad and consuming the content alone.

If you run an event, what’s one of the biggest things on your list? Sponsorship. Why? Because you want a nice venue, great speakers (who need to be well taken care of), good food. All of this costs money. Companies enable events like these. They pay you money so you can run your event that will benefit a lot of people. In exchange for what? A logo here and a mention there? If we are happy to take that advertising in the offline world, because it benefits us, we should be viewing ads online in the same light.

Business Sense

This is a tried and tested business model. A lot of businesses offer free services in exchange for ad placements. If you want an ad free experience, you pay for the “pro” version. Fair and square. If you don’t like ads, pay them so they can run their businesses successfully.

The probability of you clicking an internet ad is lesser than that of you surviving a plane crash.

Brad Frost jokingly mentions this random internet fact in his talk Death to bullshit. While this statement may not be statistically accurate, the probability of us clicking an ad is very low.

Yet, there are entire businesses based off of this model. They allow me to use their amazing software in exchange for a little bit of my screen space, which I can totally ignore. And they are okay with the abysmal probability of my clicking it. They really just want the comfort of having their ad there, even if it means very little to them. Right?

Quality Content

A lot of people produce quality content through their blogs or podcasts. While they reap some amount of reputation and marketing benefit out of this, its really intangible. They take hours out of their lives to experiment with cool technology, write posts, format it, upload code samples, explain, teach and share it with us. We get to learn so much for free. Can we not, in return, provide these authors the possibility of making money through that content?

I learn a lot from dev blogs and have immense respect for a lot of these authors. I wouldn’t voluntarily tip an author for every great blog post he wrote. But if my visiting his site or clicking on an ad that genuinely caught my attention is going to benefit the author, how can we have a problem with that? In fact, I strongly feel that every great blog article should be rewarded. The learning I gain from their writing far exceeds a trivial click that can help them sustain their channel. Even if some of this advertising was “in the way”.

Relevant Ads

These ads are not boring or dull. They are relevant. They are based on your browsing history. It does get annoying if you look up some search term by mistake and you start getting ads for tennis balls for the next week. But these are machines trying to learn and behave intelligently. They are building systems around this and it takes time to build intelligence. Once they do, these ads will be less boring and more interesting.

Ads within your content 

When everyone starts blocking ads, the creative minds behind ads will come up with better ideas. They will start promoting ads within content. That is the worst thing that can happen to us!

You will start having actors promote products within the movie. Or text links on blogs to products that aren’t really what they seem. We will be forcing them to promote sponsors without a clear demarcation of content vs promotion.

I prefer to keep my content and advertising separate. And I think that is a better way of consumption than constantly digressing within the context of reading or watching a movie.

Doing it right

I am not saying advertising is being done right today. They have a lot of growing up to do. But, before you start hating these ads for their existence, understand that you might not be able to access facebook, had it not been for ads. Or Google, for that matter.

Instead of building tools to avoid these ads, we need to build interfaces that allows content and advertisements to coexist, without intruding each other.

There are right ways of showing ads. Then there are the absolutely wrong, tricky and cunning ways of showing ads.

1. Fake links

When you click on download, it downloads an “installer” instead of the software you requested. Or, you are met with ten different buttons all saying download and the actual link is buried inside this maze. 

2. Signal to Noise Ratio

Actual content is 1/10th of the screen and there are ads everywhere else

3. Population explosion

If having one ad on the page doesn’t work, lets add ten ads. This mentality of certain publishers is the biggest problem facing the web today. This is the reason you stop using and they start losing.

These are just some of the wrong ways to do ads. Essentially, anything that comes in the way of your consuming content and breaks your experience is a bad way to do ads.

This doesn’t mean ads themselves are bad. Publishers play a major role in how ads are perceived. There are some services that do it right.

Facebook has ads. Imgur has ads. Gmail has ads. There are a lot of applications out there that require ads for their survival and manage to make them completely unintrusive.

Appreciate it when ads are done right

We should all feel grateful that these developers care enough about our experiences. Your using the application provides them no tangible benefit when compared to the  sponsor who is paying them actual money. Yet a majority of these applications focus more on the user than promoting sponsors. I believe we have failed to explicitly appreciate when ads are done right. It does reflect in our engagement with the application, which is a reward in itself for the producer. Still, I feel that we need to be more vocal in appreciating publishers when they care deeply for user experiences.

Vicious Cycle

Unless they make their ads unintrusive, people aren’t going to flock to these applications. However, once they have an unsustainable amount of traffic and not enough infrastructure to maintain that, how will they deal with additional costs of supporting users? It all eventually boils down to ads. Its only a matter of doing it right and respecting the user.

Instead of viewing ads as something that we need to block as a whole or not care about completely, we as designers and developers of the web need to take a more careful approach towards ads. Positioning ad containers with sufficient thought that it doesn’t break the overall UX that we have built into the product. Creating responsive ad solutions that helps build commerce on the internet.

Maturity

Ads themselves have a lot of growing up to do.

1. Responsiveness

Responsive ads are still a huge problem. Ad regulations have standard dimensions of fixed heights and widths to display ads. These could totally break a layout when viewed through different web enabled devices. Some might require special software to run and are broken on devices that don’t have them installed.

2. Mixing it up

If I search for item X, I don’t want to see item X all over the internet. Mixing it up is nice. Basing ads purely on browsing history is stupid. Its the corporate version of playing it safe. There needs to be a better discovery mechanism. That’s something the ad engines need to build with more insight.

3. Responsible advertising

This ad greets you with a game where you have three shots. The first two shots, you’re playing a game. The third shot takes you to a link. These gamified ads are tricking us into clicking on regions on the screen.

Instead of focusing so much on tricking and teasing users into clicking ads, there needs to be a more responsible and respectful advertising system in place. When the users mature and accept ads as part of the system, ads need to respect the user in return.

Further reading / References

Sustainability of an Ad-Centric Ecosystem
The Future of Advertising: ‘Pay-Per-Gaze’ Is Just the Beginning

 

Debounce and throttle

I just recently learned about debounce function. If you are polling for changes and there is a possibility that this event could be fired a gazillion times, like a resize, a user input box that listens to every keypress, you might want to debounce it.

Foundation framework has now provided us access to utilities that the core uses. One of those utilities is the debounce function. You now have access to use their debounce function and add it to events you are listening.

Foundation’s utils includes 2 types of functions

Throttle
Prevents a function from being executed more than once every n milliseconds. This way it doesn’t matter how many times you call the function, it will only execute once.

Debounce
Prevents you executing a function till you stop repeatedly calling it for n milliseconds
A screen resize will usually fire for repeatedly when you resize the screen. While fluid widths would handle most issues for you, if you are changing from tabs to accordions, for example, you really want it to only execute once you are done with the resizing.

Reference
http://remysharp.com/2010/07/21/throttling-function-calls/
http://davidwalsh.name/javascript-debounce-function
http://foundation.zurb.com/docs/javascript-utilities.html

OOSass, Foundation and Bootstrap

I was listening to episode 2 on Dale Sande on SassCast, where he talks about semantic classes vs presentational classes. Take a look at the below code

<div class="large-6 small-12 medium-8 columns large-centered medium-uncentered">Blah</div>

This is an object oriented approach to CSS, where classes are treat as objects that inherit properties. Using @extends, its possible to use OOCSS approach in your SASS files without bloating your CSS with all those classes. Its an awesome feature and its been in Sass since 3.2.

@extends in Sass

@extends have been around since Sass v3.2. I myself am guilty of not using it to reduce code bloat. Sure, I use it in a lot of places, but  I feel, as a community, we still haven’t pushed this one far enough to realize its full potential.

Separation of concerns

Not many of us are taking advantage of this feature. We still have new grid systems coming out that give 300 – 500 lines of grid classes alone. You don’t need all those classes in your CSS files, if you are using only a few.

If you’re like me, the presence of those many classes in the markup is bothering you. Something about having presentational behavior in the markup feels very wrong. Both bootstrap and foundation use this method for all their CSS components.

Code Bloat

Not many of us are taking advantage of this feature. We still have new grid systems coming out that give 300 – 500 lines of grid classes alone. You don’t need all those classes in your CSS files, if you are using only a few.

I like my markup clean and uncluttered. I would much rather have the same code as below

<div class="tab-container">Blah</div>

My markup is cleaner and I go into my SCSS and add the below code to achieve the same effect

.tab-container{
@extend %large-6;
@extend %medium-8;
@extend %small-12;
@extend %columns;
@extend %large-centered;
@extend %medium-centered;
}

Its readable and reduces code bloat in your markup.

@extend only grid classes bootstrap

Three months back I tried to redo the entire bootstrap sass port into an @extend only version. The source code for that is available hereMost grid classes are output as part of a mixin. This is true for bootstrap and foundation. In my @extend only port of bootstrap sass, I didn’t bother doing that because I had trouble convincing people to adopt this approach. Although every other component was @extend, the grid alone was being output in the CSS.

The problem is a lot of people are used to building apps and websites this way. This change is a shift in thinking. If you’re just prototyping, you don’t really care about things like these. You just want things to work and that’s why it makes sense for bootstrap to do this. But, if you are building a scalable application and want your CSS to be manageable, its not advisable to put your grid classes in your markup.

@extend only grid classes in foundation

I work a lot with foundation and I think it makes a lot of sense for them to implement this as a feature. Enable a switch that allows an @extend only grid classes. If you turn it on, grid CSS are never output but extendable like I did in the above example.

There’s currently a Pull Request in foundation that helps make this a possibility. It still needs work but its a great start. I made a codepen to see how we can achieve this. Line 71 is the main mixin and it works great.

Before we go ahead and code the entire grid of foundation including 5 media breakpoints into a similar loop, I would like to know if the community shares the feeling. If there are other developers out there, who use foundation, feel the necessity for this. I have opened a discussion on their forum for this and am eagerly awaiting what the community thinks.

Sass @imports v2

This is all temporary though. Good folks at Sass are working on revamping @imports. One of the things on their list is to import files but not output any CSS but be extendable. This is a killer feature. But until that comes, we don’t have much choice.

I’d really like to know from fellow developers if this makes sense to you and whether you would incorporate this into your workflow or find it one of those habits difficult to change or totally unnecessary.

References

OOCSS + Sass = The best way to CSS
SassCast

Automated Responsive visual diffs with Wraith

BBC’s team put up a neat plugin called Wraith to automate responsive visual diffs. Its helpful to include visual diff’s into your build system and workflow. The biggest advantage is, if you fiddling around code and there’re minuscule changes of 1px, its hard for the human eye to pick it up.

An example use case for working on a legacy applications. You’re editing CSS for a change in a particular screen. If you’re afraid this change might break things in other screens/pages, use wraith. These visual diff’s help by picking those and pointing them out to you. You still have to go through these images manually but its a whole lot easier to pick major differences. Especially, ones you did not intend to make.

The other major advantage using BBC’s Wraith is that it does responsive screenshots. Wraith checks your site in different viewport widths and compares it with production (or another URL you point it to). Its pretty neat and helps ensure you didn’t unintentionally break something.

The config yaml file is super simple and human readable that it took a jiffy to set this baby up and capture diffs. It uses phantom headless (webkit) to traverse pages, resize viewport and capture screenshots. It uses imagemagick to do the image processing.

What’s not mentioned in a lot of places is, once the diff capturing is done, it gives you a cool UI to browse these diff images. You have access to screenshots from both environments and the diff image. These are neatly categorized by the pages. Thrilling!

Below, I have documented my process of setting it up and getting it to work

1. Download and install Imagemagick
2. Download
PhantomJS and unzip it in the folder where you want to run wraith from. I put it in my root/tools/visualDiff folder
3. Then configure your YAML file. Its simple and readable.
a. I put in URLs for my int and production environments.
    b. Add paths you want to test
    c. Add responsive breakpoints at which you want to test.
4. Run the command

wraith capture config name

Issues faced:

1. I had placed phantomjs in a separate folder of its own at first but that didn’t work. So I put the executable phantomjs exe file at root and it worked

2. There was some weird file permission issue that didn’t allow wraith to create a shots folder. So I manually created it  and that worked fine. I still have issues when I run wraith, because it flushes that directory and deletes it. Then creates a new one with the same name. I am on a windows machine so maybe that’s a problem?

But that’s pretty much it. Its a sweet tool that I recommend you incorporate into your frontend tool pipeline. There’s also a neat grunt plugin if that’s your kind of thing 

I am currently figuring out how to use this and work around pages that require login or closing a modal.

Soon, we will also have the percentage of diffs available.

Documentation for Frameworks and APIs

I just filled out a developer survey form shared by smashing magazine’s facebook page. Its about documentation and what’s important for developers. I felt like expanding on some of the points.

  1. Real world examples
    The most important aspect of documentation for me is the use of real world examples. I want to use your plugin or framework in an application, in production. I think having more real world examples and use cases, helps me make my decision faster.
  2. Document all the options
    A lot of times, I notice that some of the plugins have an amazing amount of capability. However, the documentation reflects this very poorly. I understand that creating examples for all the cases might be crazy, however, listing all the options is an absolute must.
  3. Mobile phones
    I want to be able to view the documentation on mobile phones. I could be sitting in a train or at some other place away from my laptop or PC. I could just come up with a way to solve a problem. I want to be able to quickly login to the docs page and see if its possible. While most recent websites, especially open source docs powered by github are usually responsive, the code part isn’t. The easiest thing to do with code blocks on such pages is to add a horizontal toolbar.This works in a lot of cases but I have had usability problems with some of the websites, where I simply cannot scroll to the other end. Worse, I was able to replicate this on my desktop while shrinking the viewport. Horizontal scrolling was just useless. It has to be tested out. Please!
  4. Contributions.md
    I hate it when I see a plugin and I see a typo or a bug that I can resolve. I have the time to make that PR but finding out how to contribute is so complicated sometimes, that I give up. What’s worse than that is having a very banal and overly-generic contribution readme
  5. Links to Github
    I thought this was a no-brainer! You have an open source project, a free plugin. The source code for this plugin is on github. Being able to access that is important for me. I can look at what issues are reported, how often commits are made, how active the discussion is. I have recently been frustrated with one such jQuery plugin, that does not link to github on its page. I was totally lost!

If you are a developer, I urge you to take this survey, so we can get a consensus on what everyone feels.

Sass at Github by Ben Bleikamp

Live blogging from #SassConf My notes on session by Ben

Github has 133 Sass files and uses plain HTML ERB + View Models, Coffeescript

Github’s mobile styleguide https://github.com/styleguide/mobile is available here. It is meant mainly for people who would love to access github (notifications and updates mainly)

No, they are not building a code editor for mobile, because it does not make sense. But an ipad native app might not be ab ad idea

Tips for performance that were implemented by github

Contain CSS animations to prevent entire page redrawing

Amount of markup is proportional to speed

Fewer DOM matches, faster the site loads

CSS Performance enhancer ul#nav is bad, because it matches more DOM elements than #nav alone

Chaining selectors are bad. Replace them with a single class – .octicon.private is slower .octicon-private is faster

Use fuzzy matching selectors is bad for performance

http://josh.github.io/css-explain/ – Rate the performance of your selectors

Don’t use CSS animations for mobile, it makes it slow

If possible, rewrite the whole markup and CSS for mobile specifically, if performance is a big deal for your website/app

You can find the deck here
https://speakerdeck.com/bleikamp/sass-at-github