Tips from experts responsive web designers.

Hello all you there. I'm glad to be here in your forum.

My name is Javier, and I'm a developer with good experience on Java, ActionScript 3, and no so much but some experience on C# and PHP.

But now I'm making a friends Web page, and I'm diving into web design with css and html.
So I will be very glad if you can give me some tips on best responsive design on the first page I have make, that is the home page of http://letsublet.com/index.php/, all the other page of the site are still on development. So if someone can take a look on the homepage source code and say anything it will very nice.

Thanks.

Javier

PD: I will try to help any body in anything that I can.

 

Well, if you want to learn to do it properly, you are going to have a bit of a disconnect mentally from everything you mentioned in your existing skillset. This is because the visual appearance in front of you is only a small part of what properly written HTML and CSS is there to do; there is no 'single target' and markup specifications exist to say what things ARE, so user agents (browsers) can best show that meaning within the capabilities of the device, and so that you can fine-tune that with CSS. IF you are even THINKING about what the page is going to look like when choosing your HTML tags you are doing it all wrong.

The best way I've found to make a responsive layout is to follow every other stepping stone along the way known as "accessibility" -- which is to say elastic and semi-fluid layout as well. What are those you ask?

Semi-fluid layout means you have a container (or multiple same-depth containers on some layouts) with a maximum width set so that long lines of text don't get too long, and a minimum-width at which the layout breaks. This is so you can target non-media query capable browsers as the lowest common denominator. A LOT of people say start with "mobile first" -- but mobile is the smart one of the bunch we CAN target wtih media queries to make responsive, as such it makes no sense for that to be the starting point; that's putting the cart before the horse. We can unset that min-width with media queries for mobile.

Elastic layout means your fonts are dynamic - aka declared in %/EM instead of PX, and any layout widths (fixed sidebar widths, min/max-widths) are declared in EM... EM is inheritance based, starting on body as the default font size the browser or OS has declared. That default is NOT a fixed value though 16px is the most common -- on this laptop I'm on right now it's 20px (aka 120dpi/125%/WinXP and lower "Large" Win Vista and newer "Medium"), on my media center it's 24px (aka 144dpi/150%/Win7+Large)... Declaring EM fonts means users don't have to dive for the zoom if they have the OS or browser set properly, and using EM widths means the layout automatically enlarges/shrinks based on that font size without forcing presentational images to scale. (which most browsers do very poorly).

But before you even GET to layout or THINK about what it looks like, you should mark up your content semantically. What is semantic markup you ask?

Basically it's a sick euphemism for "using HTML properly" -- we say it so as not to offend the halfwits who still vomit up markup based on what things should look like out of utter and complete ignorance of what HTML is and what it's for -- which sadly is the 80%+ of people out there crapping out websites any-old-way with their heads permanantly wedged up 1997's backside... aka the people who until a couple years ago were still sleazing out HTML 3.2 and slapping 4 tranny on it, and today slap 5 lip-service around the same outdated halfwit dumbass code.

Semantics is simple... and related to professional document writing. In professional writing "headings" indicate the start of sections of the page; lower order headings indicate the start of subsections of the higher order heading preceeding them. Likewise "rules" (as in a ruler/break) are used to indicate changes in sections/subsections where a new heading is unwanted/unwarranted -- like a change in scene/location in a novel that doesn't become a new chapter.

In HTML's case, an H1 is the highest order heading under which all content on the page is a subsection, which is why STRUCTURALLY the H1 should be the first element inside BODY to actually contain CDATA. (character data -- text to be renderered on the page). An H2 indicates the start of a subsection of that H1, an H3 is the start of a subsection of the H2 and so forth. The higher the number, the lower the order. You need to go more than six deep, your document is either too complex or poorly written. Likewise HR, the "horizontal rule" is a RULE, it indicates the start of a new subsection or change in topic where you don't want a heading. H1..H6 does NOT mean draw text in different sizes, nor does HR mean draw a line across the screen -- even if those are the default behaviors in "visual screen media user-agents", aka "browsers".

Semantics also means if you have a list of bullet points like quick selections, menu items and so forth you use list tags to show them -- an unordered list <UL> if they are in no specific order, an ordered list <OL> if they are in a specific order. These tags to NOT mean "put bullets before them" or "put numbers before them" -- AGAIN -- even though that is the default behavior for them in "browsers". If you have a GRAMMATICAL paragraph it goes in a P, if it's just some text that is not a complete thought, or stuff that isn't one sentence or more forming a complete thought, it doesn't go in a P.

Which is why the rubbish idiotic practice of slapping single IMG tags or form elements inside P is really "special" -- in the same way some olympics are "special".

Once you have a grasp on using the tags for what they mean, the site building process can begin... and it does NOT begin by dicking around in photoshop drawing goofy pictures of what a site MIGHT look like. Paint programs like Photoshop work in pixels, thinks in pixels, and is the surest road to an inaccessible non-responsive non-elastic train wreck possible. ANYONE who calls that their starting point, screwing around making PSD's usually don't know enough about HTML, CSS or accessibility norms to be "designing" a blasted thing for ANYONE!!!

Where you start is your CONTENT, or at the very least a reasonable facsimile of your future content.

Step 1: Put your content into a flat text editor (notepad2, notepad++, editplus, crimson, win32pad, gEdit, textWrangler -- there's hundreds of perfectly good free programmers editors out there) as if HTML doesn't even exist, and just try to put it into an order that makes sense.

Step 2: Use the semantic tags to say what the various pieces of content ARE. Headings to mark starts of sections, HR when headings don't make sense or are unwanted (like right before a headerless footer), P around actual flow/content paragraphs -- being sure when you add things like forms that you use form elements properly. At this point you have no real business adding DIV or SPAN since those are semantically neutral and have no defined meaning.

*NOTE* some halfwits will claim classes and ID's can have semantic meaning; while it is VERY useful to use clear meaningful words to describe what things are with your classes and ID's, they do NOT provide semantics as user agents have NO idea what ANY class or ID actually means!

It is also worth noting that at this point, what you will see on screen is basically what screen readers, braille readers, data-scrapers and search engines will use. Remember, search engines don't have eyeballs and apart from some minor bits of CSS like "visibility" or "display:none" could give a flying purple fish about your layout or style. They see CONTENT and the structure of that content as provided by the markup!

Step 3: Create your initial non-media query screen media layout. THIS is when you can also add DIV to group together tags for styling and span as styling hooks, adding classes or ID's as needed to the markup -- but those should NOT be saying what things look like, just what they are or WHY they are getting style. Anything that goes into your markup at this stage should say "WHY" is it getting style, not WHAT that style is. Classes like "red" or "left" being prime examples of what NOT to do. WHY is it red, WHY is it to the left?

Likewise if you want presentational images you add them at this point. Images that represent text or that are not content have NO business in IMG tags, and belong in the CSS as backgrounds. This includes things like logo's which are usually presentational affectations to the site title. There are advanced "image replacement" techniques like Gilder-levin designed to allow you to use CSS to add said images in a manner that images off the text will appear instead.

A GOOD layout again should be elastic and semi-fluid at this point with dynamic fonts -- those requirements mean a LOT of the artsy fartsy PSD jockey BS and scripttardery are NOT viable for web deployment no matter how many ignorant halfwits insist on pissing all over their websites with things like sliders, perfect width equal-height elements, mosaic layouts, parallax scrolling, and every other bit of fancy yet ultimately useless bandwidth wasting slow loading rubbish.

Step 4: Add media queries to bend that desktop resolution screen layout to your will doing things like changing heading sizes and stripping off columns for smaller displays. It's usually easier to take layout away than it is to add it which is again why starting out with non-media query desktop screen layout and then adding queries to it is far easier and simpler than the broken "mobile first" approach.

Good rule of thumb, if someone says something other than "content" as the "first" thing, they don't know enough to be running their mouth about it.

Step 5: Consider adding other media targets like PRINT, though simply letting the markup defaults be your print version is often more useful. Usually for print I like to simply hide things that serve no purpose when printed like menus and links.

Step 6: If desired enhance the page further with things like scripting, keeping in mind the "unwritten rule of JavaScript": If you can't make the page fully function without JavaScript FIRST, you likely have no business adding scripting to it! -- nothing wrong with using JS to enhance the page, but it should NEVER be used to supplant basic functionality.

The above steps are called "progressive enhancement" -- you start small and you progressively add to the page. The end result is that if any of the fancier bits like images, CSS, scripting, even markup become unavailable, unwanted and/or intentionally blocked, or are just plain irrelevant to the device being used -- the page will still at least be useable by the visitor in one form or another. That ability to still work when fancy bits are missing is called "graceful degradation" and is one of the cornerstones of accessibility.

... and really that's all responsive layout is, the next logical step in building an accessible layout after dynamic fonts, semi-fluid elastic layout, accessible colour contrasts, semantic markup and graceful degradation -- and it's why for those of us who've been building sites with those things in this manner we were able to add responsiveness to three to six year old designs in an afternoon, while the people who still have their cranium wedged up 1997's rectum and never bothered to learn how to use HTML or CSS properly still struggle with the most basic of it's concepts. Or worse, dive for the absolutely idiotic re-re crippie crutches like "frameworks"

So... with all that in mind, let's look at what you've done.

You do not seem to have content of value, you don't even have enough text to tell anyone just what the devil the site even is much less why anyone should give a flying purple fish about it or even want to THINK about signing up for it. You have a ridiculously massive background image that takes FAR too long to load and makes what little text you have hard to read, and a layout that requires scrolling at EVERY resolution below 2560x1440 because of it.

There is NOTHING remotely resembling document structure or semantics, resulting in your entire page reading as one giant run-on sentence thus:
"Magento Commerce popular SIGN UP LOG IN FIND YOUR PLACE live like a local in 3 steps Monthly sublets + learn more ADD YOUR PLACE About Us Customer Service Privacy Policy Confidence and security Terms and conditions"

Not an auspicious start to a site. My advice, throw it in the trash and start over, there's nothing from that I'd even TRY to salvage. I'm sorry if that seems harsh, but the truth often is. You are just starting out, so you can't claim you didn't see an analysis like that coming. There's a LOT to learn about what website are, what they are for, and how to build them in a meaningful manner, and you are still a good ways off from doing that.

... and I'd apologize for the long post, but so far as I'm concerned the TLDR mouth-breathing twitter generation can go plow themselves.

 

Hi Deathshadow.

What a wonderful post!!

Thank you very very much for this, is like a Master class of web design!!

Regarding my home page. The truth is that some graphic designer send me the "how it should look" and I do the "coding" part. But, reading your post I will try to follow the rules to get it better.

After that I will show it to you again if you want, so you can know if a have learned something from you or not .

Thank you again.

Regards,

Javier.

 

Yeah, it shows too... Not really your fault, for some jacked up reason it's become an industry standard practice to start at the end instead of the beginning by having some "designer" who -- to be brutally frank -- usually knows **** about **** and has no business designing a blasted thing for anyone create the "look".

Sure, what they make is often very pretty, but when it is typically built with a complete ignorance of what HTML is, what CSS can do, what accessibility should be doing, or even concepts artists should know like emissive colourspace... Well, the end result is rubbish from a functionality and usability standpoint no matter how pretty it is.

It's easy to understand WHY that happens and why so many people fall into that trap; it's just easier to go "wow" over what you can see on screen than it is to go "wow" over functionality that it takes an hour to explain and eight different devices to show. People have always been more impressed in the short term by flash than they are substance -- and it's only when it bites them in the backside in the long term that they even consider questioning it; assuming they do question it and don't just give up. See why 90%+ of web startups go tits-up face-down in their first year.

It is also why you do NOT see these image heavy design concepts on "real" websites other than those that are the personal sites of such designers, places that try to dupe nubes into spending money on such scams out of ignorance, or brick and mortar companies for whom a web presence is a money-pit afterthought instead of a serious tool.

... as evidenced by simply looking at websites like Google, Facebook, Twitter, E-Bay, Amazon; not exactly a visual tour-de-force. These are the top websites out there, and do ANY of them actually look like they have some PSD jockey spanking it on the screen in Photoshop? Of course not.

Hell, you want to make a "designer" cringe, show them Craigslist.

You could do far, FAR worse than following their example; said example being putting content ahead of the arsty-fartsy bull... even if a few of them are knee deep in other failings like scripttardery they at least get that it's about the content and visitors to the site.

Which is another part of the equation people often miss; building a website is not about stroking the designers ego, showing off your l33t JavaScript sk1llz, or even meeting the whims of the client! It's about meeting the needs of visitors to the website. That means accessibility so you can reach as many of those visitors as possible, and that means content!

... because at the end of the day vistors to websites do NOT visit websites for the goofy graphics hung around the layout, the goofy animated nonsense in the UI, or the goofy gee ain't it neat scripttardery. They visit websites for the CONTENT.

CONTENT, CONTENT, CONTENT, CONTENT! CONTENT, CONTENT, CONTENT, CONTENT...

-- We make fun of Steve for that one, but to be frank he was right when it comes to an OS. If there's nobody to build it, nobody will come. In that same way if there's nothing of actual value on your site where it's all flash and no substance basically dumping a can of shellac on a pile...

The other side of that coin being the lies people tell themselves so they don't have to implement accessibility, such as "percenters" saying it's only x%, or the "that's not our audience" lie. Simple fact is the only thing you can know about who will visit a website is that you don't know who will visit a website.

A lot of such things falling into being "Lame excuses" -- this article from a few years ago is as relevant today as it was then on the topic:
http://www.456bereastreet.com/archive/200704/lame_excuses_for_not_being_a_web_professional/

 

Thanks for giving your article here........It gives good details.