|
Joe,--
I was just looking at the Zurb Foundation, that looks nice. I saw a
comment in there that it uses Rails, but no real requirements
documentation. Do you happen to know if the foundation will run on
IBM i ? Certainly we could put Ruby on the partition but then we'd
have both Ruby and PHP. That'll blow someone's mind somewhere that
this old legacy system actually does what a LAMP stack can do but at
an enterprise level......
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Joe W
Holt
Sent: Saturday, July 04, 2015 8:13 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] 7 lessons from my first responsive web site
Thank you for sharing your experience. Instead of starting from
scratch in the interest of time I used zurb foundation framework for
my responsive front end. Their design is "mobile first" as well. Your
heart break of course is Internet Explorer version 8. It like the
version 6 refuses to go away and boy will the user scream when it
doesn't work with Css3. I am hopeful the Win10 upgrades put the nail in that coffin.
By using this approach I robbed myself of this type of education. I
never trust online emulators since all they really can do is test screen size.
Too
many browser choices for too many devices. Number 7 I also find an
issue. I was wondering what affected the zoom function since my eyes
are not as focused as they use to be.
Joe
Sent from IBM Verse
Kelly Cookson --- [WEB400] 7 lessons from my first responsive web
site
---
From:"Kelly Cookson"
<KCookson@xxxxxxxxxxxx>To:web400@midrange.comDate:Fri, Jul 3, 2015
9:49 PMSubject:[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.
--
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.
--
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
