• # May 14, 2013 at 9:15 am

    Trying to wrap my poor mind around what to do and where to start ………..

    Basically, in a nutshell, my fixed width (rather simple) designs work well in both desktop and tablet mediums as I remain in a 960px fixed-width framework. I want to address those projects most suitable for having a “mobile” counterpart. In my thinking not all business would necessarily benefit from having a device-specific size, say perhaps my own web design site, more often than not I would imagine those looking for my services would be searching for and consuming content on a tablet or desktop screen. Whereas another client, an ISP provider, would definitely find a “mobile” site rewarding.

    Saying that, I want to start making a move in the direction of either responsive design overall for all screen sizes, or designing and implementing a mobile specific site. After spending a considerable amount of time researching, I grow more frustrated by the day. The alternatives I’m seeing magnify my confusion: adaptive design (fluid grid layouts, flexbox/”flex,”) or specific media queries to address specific device screen/viewport sizes. I am of the opinion, at this moment in time until I am educated further, that “fluid” would be simpler – addressing everything (?) in one fail swoop. I may be on the wrong track altogether here as I am not that familiar with breakpoints and how that would influence my decision making going forward.

    On the other hand, I’m thinking that for the amount of time and effort, would I be better off just designing a “mobile-friendly” counterpart to an existing fixed-width site? By this I mean, determining the lowest common denominator and going with a screen/viewport width framework to address the “majority” of smartphones. Naturally this would require the use of media queries and a subdomain (?) for content and styles. No?

    As you can see, I will require future support via the forums, or quite possibly a comprehensive “re-education.” Any pointers would be greatly appreciated. I’m a big boy, I can take blunt (positive) criticism. I have a rather sizable resource of pdfs on the subject, but need a hand getting focused on viable solutions before reading/studying hundreds and hundreds of pages of material.

    BTW Chris, GREAT SITE!!!!!! I am a frequent lurker: reading posts and the forums, watching videos both on this site as well as many others. Keep up the great work!

    Thanks …………..

    # May 14, 2013 at 9:24 am

    This reply has been reported for inappropriate content.

    1) Stop assuming that you know when people want to view your site, and that you know what they’re doing on their smaller units ;)

    2) I would go with a mix between fluid grid layouts and specific media queries, but don’t base them on screen/viewport sizes, but rather on your content.

    If you check this site, it’s in two columns until the text content would be too narrow, at which point the right column hops down, and the font size gets smaller.

    When you’re working off of an existing fixed-size site, look over to see what kind of media queries would make it friendlier. For instance, assume you have a 960px grid. One thing you can do is that when they reach the viewport where that’s too wide, you recalculate the grid using media queries, let’s call it something in the 768px width. So, a few major break points to make it more accessible, and then fully fluid once your content fills it up.

    # May 14, 2013 at 9:41 am

    Thanks Melindrea for responding.

    1. Thanks, I needed to hear that.

    2. Could you expand your thinking here for me please. My idea of a fluid grid layout it that it is always fluid, and that “breakpoints” weren’t necessarily part of the equation where I’d have to consider specific media queries? My thinking is pretty constrained as you can tell. ;-)

    I imagine that it would be easier for me to jump into total redesign of a site to “advance” it to be friendlier to differing sizes. Trying to retrofit a current site or design would be a nightmare, no? I prefer to learn from square one, one step at a time. Looking at an existing 960px width site now, and thinking “breakpoints” – having no experience, I wouldn’t know where to begin in my thinking or actions. To me using “fluid layouts” would move me from measuring in pixels to %, would I still have to think media queries at all?

    I’m a blank slate here, I hope to hear back from you.

    # May 14, 2013 at 2:57 pm

    This reply has been reported for inappropriate content.

    One concern with a fluid grid layout is that you still need to keep an eye on the width of the lines of text: You don’t want it to be unreadable due to too wide text areas.

    Media queries are good for making sure that the various bits of content look good in various widths.

    # May 14, 2013 at 3:30 pm

    This might help:

    # May 14, 2013 at 3:55 pm

    This reply has been reported for inappropriate content.

    I’m currently making the jump from fixed to responsive, and there are a lot of differing viewpoints, opinions and everything else. I am working on a “starter” theme for WordPress, based off Starkers, to cut down on dev time, but really want to keep it as lean as possible.

    I don’t know if this will help you or not, but it’s my “work in progress” simple grid system, as so many others seemed way overcomplex with every feature under the sun:

    This is fluid, mobile first with a single break point. But as was mentioned above, the break point could/should be changed relative to the content on a specific site.

    I am also going to look at rows within rows that may have custom breakpoints: For example, a site side bar has two columns within the side bar, and at a certain page width those two columns become one, but the side bar still remains a side bar until another smaller breakpoint, when everything becomes single column, if you get what I mean?

    # May 14, 2013 at 4:04 pm

    This reply has been reported for inappropriate content.

    Actually, one good item that I tend to base things on is the Golden Grid System

    # May 15, 2013 at 8:19 am

    As part of my workflow, I use Dreamweaver – for the ease of coding and viewing the results. A component of Dreamweaver is a widget allowing for ease of use to develop fluid-grid layouts. I anticipate moving forward that I won’t be using that functionality because it will make me rely upon things being done “automagically” – my intention, as it has always been, is to understand the principles and how they work together – besides, using such functionality often limits people from thinking outside the “box.”

    Will I be needing to use boilerplate, as does Dreamweaver, going forward? My understanding is that it allows better hand-shaking between HTML5 and older browsers/devices. What are your thoughts? Along with boilerplate, DW uses respond.min.js which extends support for media queries, I assume some form of java would be inherently necessary.

    # May 15, 2013 at 8:28 am

    @AlenAbdula & @deeve007 ( and @Melindrea) : Thanks for chiming in with additional resources of thought on the subject. Having an additional pair (or 2, or 3!) of eyes looking for great articles always helps when there is so much information out there. I don’t have the insight necessary to be able to weed out the unnecessary fluff on the subject.

    The support here is pretty fantastic.

    # May 15, 2013 at 8:57 am

    This reply has been reported for inappropriate content.

    You don’t really need boilerplates, but it’s generally a good idea to not need to reinvent the wheel everytime you want to go for a ride =)

    My workflow generally starts with pulling in some basic stuff (the HTML5 BP that Yeoman uses, Modernizr, Normalize.css, Typeplate among others) and then go to town on the design.

    I work out breakpoints and such using mockup content unless I have a good grasp of the correct one, focusing on where and when content needs to be rearranged, either starting from the most narrow viewport (IE mobile) or desktop, depending a bit on how the design was done.

    Most of my work is done in Sublime Text 2, since it gives me everything I want without getting in the way.

    # May 15, 2013 at 11:00 am

    Many, many designers encourage those wanting to move to RWD to be familiar with Ethan Marcotte’s [article]( ) as a starting pointing to understanding the ideas necessary to begin thinking along the lines of responsive designs.

    @AlenAbdula & @deeve007:

    Is it necessary that I move towards a “grid system” at all, or can I address that functionality by just doing the necessary math to address the percentages necessary to have my layout present properly? The idea is essentially the same isn’t it? Introducing grids at this point in my learning makes me feel as though I would have to rely on “additional” aides so to speak. What are you thoughts and experiences?


    I am getting a little confused. Earlier you stated that I wouldn’t necessarily require boilerplates (namely HTML5Boilerplate which includes Modernizr & Normalize.css), and yet your workflow pulls Yeoman’s BP in addition to Modernizr & Normalize.css. Aren’t we basically talking the same “requirements” here? Regardless of which boilerplate “flavor” is used, the same functionality results, no?

    I have heard of and researched the alternative code-editing solutions, and can appreciate the benefits they can provide regardless of source or specific application, but rather than muddy the water further – to make a change that significant would throw me into left-field so fast it would leave my head spinning. Albeit, I have heard many great things about Sublime Text 2 as well as SASS and the like. Keeping it simple and tackling the RWD question is my focus atm. I hope that doesn’t sound too snarky, for certainly wasn’t meant to be.

    :-) Nice discussion! Sharing thoughts and ideas is what it’s all about.

    # May 15, 2013 at 11:15 am

    This reply has been reported for inappropriate content.

    Sass can help you with RWD. I would make that your next focus, after you get the concept of RWD.

    I recommend Susy which is developed by Eric Meyer. It makes it very easy to lay stuff out, and the Sass knowledge is only limited to knowing how to set variables, and @include a mixin, (i.e., @include span-columns(4, 12), etc).

    Good luck my man! Glad you are finding your way. There is definitely lots and lots and lots of stuff out there to digest =)

    # May 15, 2013 at 11:19 am

    >Sass can help you with RWD

    No…it can’t.

    It can make you write your CSS quicker but actually designing…nope!

    # May 15, 2013 at 12:23 pm

    This reply has been reported for inappropriate content.

    No…it can’t.
    It can make you write your CSS quicker but actually designing…nope!

    sorry, I was thinking of RWD as a whole, including writing the CSS, not necessarily just the design process. Sass definitely makes things easier for layouts.

    # May 15, 2013 at 12:25 pm

    > Is it necessary that I move towards a “grid system” at all, or can I address that functionality by just doing the necessary math to address the percentages necessary to have my layout present properly?

    Definitely don’t need a “grid system” for your layout, just be aware of some cross-browser issues that each technique has.

Viewing 15 posts - 1 through 15 (of 22 total)

You must be logged in to reply to this topic.