Kelly,
Thanks for posting this. I like the effort and clear crisp way you explain
the issues and the process.
Paul
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Kelly Cookson
Sent: Friday, July 03, 2015 9:15 PM
To: web400@xxxxxxxxxxxx
Subject: [WEB400] 7 lessons from my first responsive web site
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>
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.
midrange.com
