I have my first responsive web site up and running. You can find the website here:
http://www.socialhope.info/. The content is nowhere near finished. But all of the interesting "responsive" stuff-like navigation and layout-is finished.
I am making the code for the entire site available in a zipped file (196 KB), in case anyone wants to download and play around with it. Here's the zipped file:
http://www.socialhope.info/code/SocialHope.zip
Here are 7 lessons I learned developing the site.
1. There is no substitute for testing on actual devices. I like online emulators for development (e.g.,
http://www.mobilephoneemulator.com/,
http://emulator.mobilewebsitesubmit.com/,
http://mobiletest.me/), there are things I only discovered by using real devices. Here are two examples:
a. I have a smaller Kindle Fire tablet. Font-sizes that look fine on other tablets are small and hard to read on my Kindle Fire. I had to bump up my font sizes to get an acceptable display on Kindle Fire without being annoyingly large on other tablets.
b. Online emulators showed my pages looked good in both portrait and landscape. However, when I switched between portrait and landscape on a real tablet, the displays got all messed up. I had coded some CSS that caused problems only when a user switched between portrait and landscape. This wasn't caught by the online emulators.
2. A mobile-first approach can help in developing responsive web sites. By mobile-first I mean this: You first develop the design and CSS for your smallest screen size. Then you progressively enhance the design and CSS for progressively larger screen sizes. For example, here is the sequence I used for this site:
a. Develop the design and the CSS stylesheet for small phones (240-320 screen width).
b. Enhance the design in a new stylesheet for larger phones (321-559 screen width).
c. Enhance the design in a new stylesheet for tablets (560-959 screen width).
d. Enhance the design in a new stylesheet for notepads (960-1139 screen width).
e. Enhance the design in a new CSS for desktops (1140+ screen width).
The breakpoints I chose are arbitrary. You can choose break points based on the common screen sizes of devices. However, I based my break points on a compromise between the common screen sizes of devices and how my pages looked when viewed at various screen sizes. After I had created all of the CSS stylesheets, I could then go back and forth between the various layouts to tweak things. But starting small and treating each larger screen size as an enhancement of the previous screen size really did help me.
3. Use a CSS reset or normalize.css to help ensure your layouts look the same across browsers. Browsers have their own default CSS stylesheets. Different browsers have different default stylesheets. This is why a button looks different on different browsers. A CSS reset removes the browser's default styling. You then have to style everything in your own stylesheets, but you have greater confidence that your stylesheets will look the same across browsers. I used the Meyer CSS reset for my first web site (
http://meyerweb.com/eric/tools/css/reset/). Some consider normalize.css to be an improvement over a CSS reset (
https://necolas.github.io/normalize.css/).
4. A CSS preprocessor is useful when developing a responsive web site. I created five CSS stylesheets for the different screen sizes. I had another CSS stylesheet for my dropdown navigation menu. I had another CSS stylesheet for the Meyer CSS reset. If I had tried to link to all of these styles in my HTML files, the browser would have to make 7 HTTP requests to get the CSS each time it loads a page. That's obviously not good for performance. I used a CSS preprocessor to combines all of the CSS stylesheets into a single CSS stylesheet. I'm using Koala (
http://koala-app.com/). I start Visual Studio. I start Koala. I make the changes to the CSS files in Visual Studio. Koala automatically updates the single CSS file without me having to think about it. (Koala is not a Visual Studio plug-in. It is an independent program, and will work whether you are using RDP, WebStorm, NotePad++ or any other coding tool.)
5. You don't need to know very much JavaScript to develop a responsive web site. My first responsive web site contains only 6 lines of JavaScript. I didn't even write them. I copied them from the exercise file of a Pluralsight class. The 6 lines of JavaScript use JQuery and toggle the drop-down menu on or off. Of course, I expect that my future web sites will grow more complex and use much more JavaScript. But you don't need much Javascript to get started learning responsive web site development.
6. Load JQuery at the bottom of the body section in your HTML file, if possible. While browsing between the pages of my website, I kept getting a very annoying white flicker. The page would very briefly flash all white before the page displayed. This is often a sign that the browser is trying to render the page before it has downloaded everything in the head section of the HTML file. Loading JQuery at the bottom of the body section in the HTML file resolved the white flicker problem. You might not always be able to do this. If you need to run some JQuery JavaScript *before* the page loads, then you can't load JQuery at the bottom of the body section. You probably need to load it in the head of the HTML file.
7. Some designers are willing to sacrifice accessibility in order to quickly work around design problems. For example, certain kinds of responsive design problems can be quickly resolved by including the following meta tag in your HTML files:
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
The problem is that "maximum-scale=1" at the end. The "maximum-scale=1" solves some design problems. But it also prevents users from being able to zoom in on a page (you know, the finger gesture you do with a touch screen to zoom in). Designers who recommend this fix usually say something to the effect, "Users don't need to zoom in if you have a good responsive design for all screen sizes." This is a bogus argument. It assumes that all people have equally good eyesight. Someone I love has macular degeneration and needs the ability to zoom in on pages. I myself am getting older and find it hard to read some text. I appreciate the ability to zoom in on pages. So, please don't be a developer who lazily takes quick fixes at the expense of user accessibility. You're affecting real people-like me.
Hope something in the above is useful.
Thanks,
Kelly Cookson
IT Project Leader
Dot Foods, Inc.
1.217.773.4486 ext. 12676
kcookson@xxxxxxxxxxxx<mailto:kcookson@xxxxxxxxxxxx>
midrange.com
