Jim, it can be used in Rails, not a requirement. I've not done anything
more than build a custom download of the framework and incorporate it into
my hand designed pages. I've been using the 400 as our webserver since 98
and haven't pulled the trigger on Zend or anything else beyond the move
over to Apache that IBM forced when they retired their web server and
implemented Net.Data because at the time it was the only "go-between" for
my RPG applications to serve html that was quick to implement. I use
Dreamweaver to make a static page. I use Notepadd ++ to hack that down to a
CGIDEV2 template and good old RPG to feed the pages. Nice, neat, and
simple. The cool thing about the Foundation framework is that it was an
easy tie in to my hand coded templates. So, it isn't that the framework
"runs" on the 400, it can be used anywhere it can be loaded.
***
Regards,
Joe W Holt
Sr Programmer/Developer
Jack Onofrio Dog Shows, LLC
405.427.8181
From: "Jim Oberholtzer" <midrangel@xxxxxxxxxxxxxxxxx>
To: "'Web Enabling the IBM i \(AS/400 and iSeries\)'"
<web400@xxxxxxxxxxxx>
Date: 07/04/2015 08:39 AM
Subject: Re: [WEB400] 7 lessons from my first responsive web site
Sent by: "WEB400" <web400-bounces@xxxxxxxxxxxx>
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.
midrange.com
