Learn Responsive Design

Hi. Trying to learn responsive web design. Built a website for a church years ago And now trying to convert it to a mobile format. But it's been long since I've developed a website and would like to learn some new techniques. Been hearing about bootstrap and w3.css. But don't know where to start. So any information would be greatly appreciated. I know about w3schools.com but don't know if their info is up to date. But as i said any info would be helpful. Thanks. P.S. tried searching this forum but saw a lot of responses about web response times

 

You should use responsive frameworks. My prefer is Bootstrap. The documentation is very explanatory. Simply read documentation and try it. Firsty you have to learn grid system.

 

Ok, not to contradict the first-responder, but anyone telling you to use a 'framework' doesn't know enough about HTML, CSS or accessibility to be flapping their gums on the topic. Idiotic halfwit code-bloat bull that pisses all over the markup with presentational asshattery like bootstrap does is the road to failure, and anyone telling you otherwise needs a quadruple helping of sierra tango foxtrot uniform! There's a reason it's jokingly called bootcrap, and if you've fallen for its scam artist bull and utter and complete ignorance of accessibility, my advice is to go find a stick to scrape it off with before you track it all over your websites carpets.

The same goes for buggy, broken DUMBASS nonsense like grids. Arbitrary interval measurements amount to designs that are little more than shoe-horning content into those measurements instead of creating fluid elements that adjust to the content. Just as completely back-assward as other bits of ignorant halfwit nonsense like dicking around in Photoshop before you have content, semantic markup of the content or a coded working layout.

Simple fact is responsive layout is simply the latest in a long line of stepping stones to accessible design -- following in the footsteps of dynamic fonts, elastic layout, semi-fluid layout, separation of presentation from content, semantic markup, and a host of other things that many people in the industry STILL feign ignorance of or come up with lame excuses about in an attempt to justify their scam artist snake oil or make themselves feel better about how stupid they are.

These "frameworks" universally involve throwing extra DIV in the markup whether they are actually needed or not, slapping dozens of PRESENTATIONAL classes on those div, slapping even more classes on elements that should be inheriting off the parent's selector instead, resulting in fat bloated markup that they then have to write even MORE CSS to give the appearance they want... So you start out with three times the CSS an entire SITE needs before you even write a line of your own code, then write twice the markup and the same amount of CSS as if you didn't bother with the framework in the first place -- and people consider this "easier"?!? Just what the **** are these people smoking? That esé put dust in the weed

When I call responsive the latest stepping stone to accessibility, that's no joke. There's a process to sane and rational development based on the reason HTML even exists, why CSS exists, guidelines like the WCAG, and decades of usability research. I post this process all the time -- I really should just copy/paste but I know it by heart so...

1) Take your content or a reasonable facsimile of future content, and organize it in a flat text editor as if HTML doesn't even exist so that it makes sense.

2) Apply semantic markup (A sick euphemism for "using HTML properly") to say what things ARE, NOT what they look like. If you are choosing your tags based on their default appearance you are choosing all the wrong tags for all the wrong reasons! This means that a H1 is the heading under which EVERYTHING on the page is a subsection (typically the site title goes here), a H2 indicates the start of a subsection of the h1, H3 are the start of subsections of the H2 preceding it, and so forth down the line, with a HR meaning a change in topic/section where heading text is unwanted / unwarranted. (this ability to break the page into sections is why HTML 5's garbage SECTION, HEADER, FOOTER, ARTICLE and ASIDE tags are pointless redundancies, particularly when not one single user agent does anything useful with them apart from treating them like a DIV). This means paragraphs around grammatical paragraphs and not just around anything that happens to have text; it means lists around short bullet point lists; it means tables around tabular data not just because you happen to want columns. At this point you do NOT add DIV or SPAN since those are "semantically neutral" -- they do NOT change the meaning of what they are wrapping. (neither does an anchor actually! -- People seem to forget that).

... and keep in mind that even tags like <small>, <b>, and <i> have semantic meanings based on their usage in professional writing, separate from their visual appearance! When you present a book title in italics or a company name in bold you are NOT emphasizing them. Those tags may seem presentational but represent what things WOULD BE in a professionally written document grammatically and/or structurally, NOT that they have to be presented in that manner. (Hell when HTML was created that was something it was there to address -- that many devices couldn't even show such concepts in the first place!)

3) Bend that HTML to your will with CSS to create your layoutS -- YES, PLURAL! This is the point at which DIV or SPAN can be added, but only once you've expended what you can do with the existing semantic tags; see the pointless DIV people slap around a menu UL when said list is a perfectly good block-level container unto itself. I like to start with the lowest common denominator -- a lot of people say that's mobile, but you can target mobile with modern commands like media queries (the core of responsive design) so my starting place is desktop layout for older browsers. A good starting layout should have dynamic fonts on flow text and major headings (aka declared in % or EM so it auto-adjusts to the user preferences), elastic layout (widths, paddings, margins, etc, declared in EM's), fluid height (avoid declaring a fixed height on ANYTHING!), semi-fluid widths (setting a max-width so long paragraphs aren't hard to follow). If you do all that, and use techniques that allow you to re-arrange the layout using just CSS, taking it responsive is just the final step. Hence those extra "layouts" just involve using media queries to say "well, the layout breaks when we go this narrow, so re-arrange it!"

4) then and ONLY then do I suggest one start playing with colours and backgrounds. I may apply some light greyscales earlier on just so I can see the various containers and widths, but that's placeholder appearance while waiting for this step, basically a paintover. Things like rounded corners and textures get added at this stage -- if needed. Thankfully CSS3 is increasingly making dicking around in photoshop for design elements a thing of the past whilst making sites faster and easier to develop.

5) Finally if desired further enhance the page with scripting, keeping in mind the unwritten rule of JavaScript: "If you can't make a fully functioning and useful page without scripting FIRST, you likely have no business adding scripting to it!" -- a lesson that seems lost on todays scripttards with their pointless bloated slow jQuery bull that just makes websites harder to use.

The whole process is called "progressive enhancement" and it means that should the fancy bits of tech like images, CSS, scripting, media queries, even HTML itself -- fail to function, be blocked, or simply not apply to the user-agent in question, the user is guaranteed to at least get something useable. That ability to stay working no matter what's missing for tech is called "graceful degradation" and is the cornerstone on which every other bit of site accessibility is based!

The end result is cleaner, faster, leaner, more useful and more accessible sites! You vary from this formula, and you are pissing off large swaths of users no matter what the artsy fartsy types dicking around in Photoshop, mouth-breathing halfwits screwing around with "frameworks", SEOtards with their hoodoo-voodoo, or endless hordes of scripttards might claim!!!

 

If your comfortable coding fixed with websites than the transition should be pretty easy. Basically you'll be using a lot of %'s, em's, and max-width's. This post is a bit dated now, but here's what got me started:

http://webdesignerwall.com/tutorials/responsive-design-in-3-steps

I generally don't like using %'s for spacing between columns. I generally space my columns and stuff with techniques like this:

http://sitechop.com/front-end/fluid-responsive-columns-equal-constant-spacing

Definitely don't go straight to bootstrap. Learn to code responsive sites from scratch and after you get that down you can try bootstrap and see if it makes life easier. You'll probably end up fighting against it though, i never use frameworks.

 

Wow @davidmillernyc, I've rarely seen so many terms from the subject used without actually saying anything of value. Much of it feels more akin to a word jumble than intentional writing; almost as if it were random copypasta from a website where they obviously have no clue what accessibility is.

If you're going to spam a thread with copypasta, at least credit it -- even if it's yours... but seriously, great way to blow through a bunch of buzzwords without actually saying anything of value... made all the more fun by the several instances of Engrish moist goodry.

 

Thanks for all the info guys. Lots of great answers. I have another quick question. Should I just create a separate style sheet or website for mobile devices or should I just create a liquid/ semi-liquid layout that I can use for both mobile and web

 

By the way, when you get it all responsive, make sure you check it out on all mobile devices. I use http://quirktools.com/screenfly/ to do that.

 

The entire point of responsive design is that it's one markup for all targets -- to that end you should really only have one CSS file per media target group -- and just put the media queries and changes for that group (screen, print, etc) at the end of a monolithic stylesheet.

If nothing else, always remember that the more separate files you use, the slower the site is going to be. Since browsers load ALL stylesheets even when they aren't currently in use (something some people often forget) the less files you use the better, as that too means a faster site.

It's why concepts like CSS sprites came into existence as well; reducing the number of separate image files used for presentation to reduce the number of handshakes to the server. REAL WORLD with a page's first-load every file past the first eight averages a fifth of a second, and while if you are sitting on top of the server that could be as low as a twentieth of a second worst case scenario can be a full-on second or more PER FILE. Hence why broken tools with magical connections like pingdom might report a page built from 108 files as taking 6 seconds to load, other tools and local connections real world will say anywhere from 20 seconds to a minute and a half!

More separate files == BAD when it comes to speed, it's that simple.

I also suggest practicing "size targets" -- there are certain limits that if you cannot bring the page under, you're probably doing something WRONG. Be it bloated pointless images, failed image optimization, or just plain broken methodology like "JS for nothing" or "framework asshattery".

Generally, a starting HTML+CSS template for me -- that's HTML + CSS + JavaScript + presentational images, but NOT counting content images -- should come in at under 72k in a dozen files (UNCOMPRESSED!). If you can't do that, you're doing something stupid... like using frameworks that by themselves throw it over that KB limit and/or use up a good chunk of that file allotment.

There is LITERALLY NO REASON for an entire website -- like a forum software -- to "need" more than 48k of CSS apart from developer ineptitude or ignorance. Same goes for scripting if you don't count social media plugins (which are poorly written crap that you generally need these days, but have no control over their code) -- local scripting if you can't bring it in under 32k, you're probably just pissing on the page with scripttardery that's just going to piss off visitors to the site.

Even with content images in the mix, there are VERY few legitimate reasons for an entire page to break 256k in two dozen files. The only real exceptions I can think of to that are galleries -- which typically should try to limit themselves to two dozen content images (thumbnails) to a page... since 2*2*3 makes the overflow at different widths easier to manage. Shame 2*2*3*5 at 60 images is too many separate files; MATH: the ancient Sumerians had it right!

... yet laughably, 90%+ of the scripttards, "designers" and other mouth-breathing halfwits in the industry right now would balk at "restrictions" like that -- when they are generally speaking DOUBLE what I'd be using real-world. Again why designers and people leaning heavily on scripting generally don't know enough about HTML, CSS, much less accessibility to be designing or coding ANYTHING for ANYONE!

It ends up a bit like the joke about the structural engineer on trial:
http://www.sputoandlammert.com/AFewGoodEngineers.htm

Hence why a lot of so called "professionals" out there lack the aptitude, inclination or even basic qualifications to be developing a blasted thing in terms of web technologies. They use flashy "gee ain't it neat bullshit" and manufactured statistics to dupe the ignorant fools with open checkbooks into forking over cash for steaming piles of failure; then run for the hills before that failure blows up in the clients face. Speed? Accessibility? Functionality? Sustainability? All taking a back seat to an apathy that finds it's roots in comfort, blindness, and wishful thinking.

 

If you are not a professional web designer so please do not try developing your website mobile friendly because it's very hard work. So provide work web developer.