Mobile First Responsive CSS Frameworks

Woah, that's a lot of buzzwords.

I know there's a ton of responsive grid frameworks, but all of those seem to be top-down, big screen to small screen. Are there any CSS grid frameworks that do the opposite and structure their CSS to be mobile-first?

Doug_S

Said it before, say it again: If you're using a CSS framework you're doing it wrong.

Frameworks change how you design. They change how you organize the content. They make you follow set paths. This is wrong. Your code should be bespoke, built for the content. Break points shouldn't be at, "this works on these devices." they should be when the design stops looking pretty with the content you've provided. That might mean 2 break points, that might mean 10.

When I build a site that's responsive, I expect a variance between 1400px wide to 320px wide. I start at one end and expand or contract from there. When the view starts looking bad I back it up a bit and put a change in. Then I move it a bit more until it starts looking bad and I put another. This isn't the same for every site so using a framework to do this doesn't help.

nternetinspired

@digitxpc check out Andy Clarke's 320 and up http://stuffandnonsense.co.uk/projects/320andup/ you only need to add a little grid logic, 1140grid being my preferred option. These two form the basis of my responsive, mobile-first Joomla boilerplate; OneWeb https://github.com/nternetinspired/OneWeb

missrachilli

I think it depends primarily on budget...if you have a client that has less money and time, then a framework might be the way to go. As @nternetinspired mentioned Andy Clarke's 320 and Up and 1140grid (www.cssgrid.net) are good options.

For me, I've found that working with both the previous frameworks is better when you have less time - but as @Doug_S said if you use a framework you are limited to the way they are built and structured.

Personally I've almost finished my new personal website design and have built it from the ground up, using only @csswizardy's fluid grid generator as a starting point (that even then, I've customised a fair bit). I suppose it's what you're most comfortable with that helps make your decision - if you're happy to use a framework, then go ahead and use it but be aware of the limitations that you may come across. If you instead decide to code from scratch, then you could end up building your own framework that you're happy to re-use across more of your projects (it's what I'm hoping to do!) :)

TimBaker

Personally I'm not a massive fan of design frameworks.

I'm developer more than a designer and I like to hand build each line of code in the websites I develop. Ok this might take more time initially but if you have your own library of code snippets and your own tried and tested methodology of working, then you should be able to build websites and web applications efficiently and to budget.

For designers who don't want to get caught up in the nitty gritty of development then Boilerplates and Frameworks are ideal. I would also recommend frameworks for people who are looking at creating an advanced prototype.

mattiman

As mentioned 320andup starts mobile first

Do agree with Dougs remark here. Frameworks are useful for quick prototyping work, to get handy snippets of code from or to learn from. I wouldn't use a complete framework (unless very minimal) for a real project. Whenever I tried that, I ended up undoing so much stuff that the resulting code base would become big and unmaintainable. And it would cost me just as much or more time then when I would have started with a blank slate.

What does work, is having a personal toolbox with reusable code snippets around. So when you build a site, those snippets can be cut and paste quickly. You don't want to reinvent that dropdown menu again and again for example.

About the grid frameworks specifically: I don't understand what is so attractive about them. Writing the CSS for the grid/layout of a site is very little work. Column to the left, column so much pixels to the right, a box so wide here, one there and you're done. Say I spend a day thinking about the design of a certain page (sketching, doing research, maybe some photoshop work, etc). Writing the CSS to implement that layout takes maybe 15 minutes (only talking about the layout, not the complete design). So there's almost nothing to gain there.
Maybe if you develop a huge website (say the BBC site) with many dozens of different pages, modules, etc, with a large team of developers, using some sort of standardized framework works. But even then I would expect that team to write their own specific library of reusable classes, specifically for that website, instead of using one of the existing frameworks.

arnauddelafosse

The new ver of Initializr seems to be a good start. It combines RWD and Mobile 1st approach:
http://verekia.com/initializr/responsive-template

boon

I tend to agree with the above and avoiding starting with a pre-defined grid from a framework. I think (if possible) this should be unique for each project, focused around the content. Otherwise you just try and shove everything into the same size boxes.

However I don't think there's anything wrong having a default starting-block for all your projects. I uploaded mine to Github yesterday - called Mobile Beginnings

As-per @digitxpc there's not much around which mobile-first so I went about creating my own. And as others have said, craft it yourself and understand it. Rather than use an off-the-shelf.

Mine pulls together ideas from a lot of other frameworks and all the things I would normally use, or a variation of. The fact that everything's there means it's much faster for me to customise per-project. One thing I do like is the way the stylesheets are set up which takes care of IE and print styles from the word go.

I guess for me it's easier to edit / delete than to add. 

Doug_S

Hmmm. I will say that a framework system can be rather handy for prototyping if you're familiar with it. But, with me at least, that starts to bleed over into my actual production work and I refuse to mess up my clean CSS with bloat.

linssen

I've just launched a new beta release for the Responsive grid generator Gridpak we built at Erskine. It's actually built with mobile first in mind: every time you create a break point you are creating a new media query with a min_width - so you technically start bottom up (if you want to.)

It lets you see how your grids will actually look in proportion, and you can drag the browser about to see it resizing.

The good thing is that it doesn't force you to use certain media query break points, or padding / gutter widths you can do it all yourself.

Hopefully you'll find it useful, and we'd love it a bit of feedback to make it more useful. Have a look and drop us a line to gridpak [at] erskinedesign or on Twitter @gridpak if you have anything to say.

ezekielbruni

I think that using a framework is not necessarily a limitation, but then, I'm almost always disagreeing with Doug. :)

I believe that a good framework, built on solid design principles, can in fact help designers to learn the rules of design, and then learn how and when to break them. A framework can only limit you if you allow it to do so.

A twelve-column grid serves my purpose for most cases. If you really want to make it different for each project, however, then try semantic.gs, or another LESS/SASS/SCSS/whatever-based framework. They usually provide you with a mechanism to create your own grid fairly quickly and easily.

Doug_S

Yes, it can help you learn the rules of design. It's rules. I see a lot of designers using pre-made grids and going, "That's how you do grids, right?" to which I keep saying no, it's not. That's just reusing a pre-made structure because it's easier. Doing grids properly requires a custom grid every time because the content is different every time.

And then, for people like me, who know these rules, know what grids are and how to use them, a framework gets in the way because it says, "You should do a 960 grid!" to which I might reply, "But 960 isn't equally divisible by 11!" "Too bad. Do it." "But most computers are 1280px wide or better!" "Too bad."

Which is why I go with option-B: Look at the content, the target devices, choose a grid that fits, code. Starting with a framework means you think with the framework. I know it's true because I do it with jQuery. I do it with Symphony. I have a hammer so everything is a nail. This is why I'm trying to move away from hammers, as it were.

mattiman

That's a good point about the hammers Doug (I know I'm guilty as well)

ezekielbruni

As usual, Doug raises a good point, but I believe that these are the failings of us as designers, not the failings of grid frameworks as tools. Now that I finally got SimpLESS to work on my Linux box, I can quickly and easily create grids to fit any situation with semantic.gs.

Now, to combine the best bits of Foundation and semantic.gs to create my very own super framework! I shall rule teh interwebz! Muahahahahaa!

But back to my point. You can choose to let a framework simply speed up your process, you can choose to let it limit your design, or you could even get stuck somewhere in between. I don't see it as a black and white issue. You shouldn't necessarily abandon hammers, just recognize that there are also screwdrivers, saws, planes, chisels, and more.

While going off and creating your own tools from scratch is definitely cool in its own way, it isn't always necessary.

mattiman

There are actually two separate issues with pre-made grid frameworks.

1- You are limited to using the grid values (for the number of columns, column width, gutter width, etc) from that framework. So if you just happen to need exactly the same measures, no problem. But if your content would be better fitted in slightly different sized grid, it would be better to write your own. I think this is the point Doug makes.

2 - Using a grid framework forces you to use non semantic classes inside your html to create the grid. Most grid systems I have seen use something like col-1, col-2, etc. There are pros and cons to this approach. So whether this is a good or bad thing depends on your situation/project. For most of my projects, adding extra classes to my HTML for solely styling the grid makes no sense. Most often I'll just use existing markup (like article, aside, footer) or use a class like maincol or sidecol and use those for hooks in my stylesheet. However, for big teams in bigger, more modular websites, I can imagine that adding classes like span-2, span-4, etc makes sense (forcing uniformity among developers and modules)

ezekielbruni

Does nobody ever listen to me when I say to check out semantic.gs? You're not limited to any set number of columns, and no, you don't have to use un-semantic classes.

Doug_S

We're busy, lazy people. Give us an example. :P

ezekielbruni

An example taken directly from their website:

<header>...</header>

<article>...</article>

<aside>...</aside>

@column-width: 60;

@gutter-width: 20;

@columns: 12;

header { .column(12); }

article { .column(9); }

aside { .column(3); }

@media (max-device-width: 960px) {

   article { .column(12); }

   aside { .column(12); }

}

ezekielbruni

Obviously, the previous example wasn't really "mobile-first", but that's left to the person doing the coding.

Doug_S

Not strictly the kind of framework we were talking about, I don't think. The 960 Grid, for example, has predefined grids. That is basically a new, easier syntax. Like Rails on top of Ruby.

ezekielbruni

No, semantic.gs is a lightweight customizable grid framework built on LESS (That's the "new syntax").

Doug_S

Personally, I'd say Less was the framework (since it is one) and Semantic.gs is an extension (which it is). But that's kind of splitting hairs at that point.

designerheadache

Seems to me that actually the debate is evolving in to something else, frameworks and how they constantly solve and fail all at once.

Allow me to elaborate,

As a designer/front end developer/code monkey, you will spend a lot of time building varied sites for clients. They all have different business requirements (not always of your choosing) sometimes you are building a mobile first ultra modern awesome site, and sometimes it's a fixed width (it still happens) low budget website for a smaller client, or anything in between.

The reality is the internet is messy and it's not likely to be less messy for quite a while as it matures. Frameworks are great, in so much that they solve the problem they are designed for. The issue is that a framework is a scaffold designed to help you achieve a particular given task quickly and easily.

Read that last bit again "achieve a particular given task".

Here is the rub, all our processes are different depending upon the agency you work for, your personal workflow or the particular site you are building and the business requirements at the time. People have tried to help by building frameworks to solve these tasks. But it isn't working, every time there is a new idea or problem a hundred frameworks pop up and when you try to build those ideas in to your own framework or augment someone else's it doesn't quite fit...so you write another framework to fix it and the circle perpetuates itself.

As you can probably tell I have thought about this issue a great deal.

To me the answer isn't frameworks at all, it's a toolkit

I have a series of problems solved in my custom LESS toolkit for various issues, different grid solutions and typographic solutions, and I cherry pick the given starting points for a particular project based on the user and customer requirements. From there I roll my own code for the rest. This has proven a much quicker, more robust system. When new thinking emerges or a different approach becomes common, I can just augment my existing approach, rather than start from scratch and zero useful code.

Toolkits allow you to design unconstrained and hassle free.

Frameworks tie you down and force you in to a rigid path.

digitxpc

Thanks for the great responses.

I use a framework usually because generally in my environment (high school) I'm dealing with high development speeds and (sometimes worryingly) low standards, so I can afford the insane technical debt.

Seeing this discussion, though, makes my CSS skills feel horribly inadequate for when I actually need to build a maintainable website. Time to hit the books.

To confirm my intuition, a non-grid CSS layout is normally just float-based with calculated widths and paddings, right?

Doug_S

That's one way of doing it. The fun thing about web design is there really is no "this is how you do it" for just about anything. There are "better" ways and "recommended" ways, but never "must" ways, if you take my meaning.

In the end it's all about doing as little HTML as you can and relying on CSS to do as much as possible. As long as it looks the way you want after that then you're doing just fine.

However... USE A GRID. There is no excuse for not. It's not a framework thing, it's a design thing. Use one. OK, so maybe there is a must: You must use a grid.