Font was too small (I don't like using set font sizes, instead I like using percents).
I have completely stopped using pt as the font-size unit for web pages. I might still use pt as the font-size unit if I develop a page specifically for printing out. But even then I would prefer to offer a PDF file so people can download a digital file and help save a tree.
I used em as the font-size unit in this web site. It was nice setting font-size one time for the HTML body (16px), then defining all other font sizes relative to that (1em = 16px, .5em = 8px, 2em = 32px, etc.). I think in the future I will use rem as the font-size unit instead em. I did not realize the em unit accumulates size changes in nested elements. The rem unit always points back to the parent element, so does not accumulate in nested elements.
It turns out there are 16 units developers can use with font-size. Here's a decent article explaining the options:
http://www.narga.net/understanding-font-sizing-in-css-em-px-pt-percent-rem/
This also will help you pass Google's mobile test. When I was testing
mine I had 2 issues (well, 3, but 2 were related to not having this meta tag).
Yeah, I think this meta tag is generally recommended for responsive sites. Mobile devices don't always report their screen sizes accurately. If you don't have this tag at all, then a mobile device may report an inaccurate screen size, and that will mess up your CSS media queries. The user will get the wrong layout because the device gave your site a wrong screen size. This meta tag resolves the problem.
But you don't need the "maximum-scale=1" at the end. The following version of the meta tag is enough to make sure you are getting the right screen sizes for your CSS media queries:
<meta name="viewport" content="width=device-width, initial-scale=1">
This version of the meta tag allows users to zoom if they need or want to do so.
But, you can make the body with a display:none (using CSS), then
with the jQuery make the body visable once the window loads.
Thanks! That's a cool tip. I will keep that in mind in the future. It's not always possible to load JQuery at the end of the body.
I ran into a few issues too, mainly dealing with the dynamic
content-swapping part, which you may eventually do with your site.
I initially wanted to do a little dynamic changing of content. I have short sentences as the text for links in the mobile drop-down navigation menu. The short sentences took up too much space for the traditional navigation bar in the desktop layout. I wanted single words as the text for links in the desktop navigation bar.
I used JQuery to write a script that changed the text in the navigation links based on screen size. The problem is the script only ran one time on a page load. So, if a user had a tablet that got the mobile drop-down menu in portrait, but the traditional menu bar in landscape, the navigation would get messed up if the user switched between portrait and landscape.
I enhanced my JQuery script to force a page reload every time a user switched between portrait and landscape. But I didn't like the results. The page reload was visually disruptive when switching between portrait and landscape. Plus, I was forcing the user to download information redundantly (possibly costing the user money).
I considered enhancing my JQuery script to set a listener for orientation, then execute text changes in the links based on the orientation of the device. But the script would also have to take into account the user's screen size. On a small tablet, the user gets the mobile drop-down navigation menu in both portrait and landscape. On a larger device like Microsoft Surface, the user might get the traditional navigation bar in both portrait and landscape (assuming Surface has orientations--never tried one out). I just didn't feel like adding or testing this yet.
I decided to have two main navigation lists in the nav section of my HTML file. I could then use display:none to hide the menu I wanted hidden, and display: block to show the menu I wanted to show. Having the two separate lists also made it easier to treat the PDF download link differently for mobile and desktop layouts. Someone with more advanced skills in JavaScript, JQuery and CSS might find my solution clunky. But, I'm still learning, so it is what it is...
Thanks,
Kelly
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Bradley Stone
Sent: Saturday, July 04, 2015 8:43 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] 7 lessons from my first responsive web site
I've been playing with a responsive and dynamic content-swapping site for our actual website as well.
http://m.bvstools.com
I ran into a few issues too, mainly dealing with the dynamic content-swapping part, which you may eventually do with your site.
It looks like it could be easily converted to something like that which would make the site more responsive (ie, you use jQuery to update the contents of the page instead of reloading everything including CSS and Javascript, each time a link is clicked).
Here's an article I wrote about the problems I ran into, mainly dealing with SEO and web crawlers (something to be weary of if you're going down this route):
http://www.fieldexit.com/forum/display?threadid=175
I also posted it on LI here (but I don't really like the posting tools for posts on LI.. they're too basic to format code):
https://www.linkedin.com/pulse/responsive-design-dynamic-content-swapping-seo-googlebots-stone
I found one thing that maybe I can help with in your case:
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.
This happens on a lot of sites. If you're using a lot of jQuery that's a lot to load (best to use a hosted library, which you are.
But, you can make the body with a display:none (using CSS), then with the jQuery make the body visable once the window loads:
$(window).load(function() {
// When the page has loaded
$(".hideMe").hide();
$("body").fadeIn(100);
});
The hide() is just there to hide anything that I initially want hidden.
I tried this on document.ready and it didn't quite work as good.
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">
This also will help you pass Google's mobile test. When I was testing mine I had 2 issues (well, 3, but 2 were related to not having this meta tag).
Font was too small (I don't like using set font sizes, instead I like using percents).
Font size easily fixed, but it took some searching to find this little gem you mentioned. :)
Just some thoughts.
Nice site!
Brad
www.bvstools.com
--
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
