Nathan,

It seems to me that absolute positioning and fixed pixel sizing
should be kept to a minimum under responsive UI design.

I generally agree that less is better when it comes to absolute positioning and fixed pixel sizing. I may rely more heavily on absolute position and fixed pixels sizes now because I'm still relatively new to responsive design. I may rely on them less as I become more experienced and do a wider variety of designs. For example, I have not developed a responsive web page with fluid grids or with responsive graphics.

I don't think the adverse effects of absolute positioning and fixed pixel sizing are as bad when they are targeted at the vertical dimension (top, bottom, height). Most of responsive design is based on changes of screen size in the horizontal dimension (left, right, width). In fact, fluidity along the horizontal dimension is a key part of responsive design, IMHO. There is simply no practical was to code for all of the screen widths on all user devices in the wild.

I'm currently working on a documentation viewport, which
previously relied on inline frames, but works nicely as a SPA.

Thanks for the link. Digging in to the JavaScript will be a good exercise to help me start learning JavaScript. It will take me some time, though.

I noticed you don't appear to be using JQuery in your documentation viewport.

Thanks,
Kelly


-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Tuesday, July 07, 2015 10:39 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] 7 lessons from my first responsive web site

Kelly,

Yes, you have given a nice review of what's happening under the covers and some pros and cons of a scrolling content area between fixed headers and footers, which may be better suited for database applications than site content.

I often use "Fiddler" to see comprehensive I/O details and data streams occurring between the browser and the server. I/O is streamlined considerably under the SPA approach, though SEO and other concerns may take a back seat.

It seems to me that absolute positioning and fixed pixel sizing should be kept to a minimum under responsive UI design.

I'm currently working on a documentation viewport, which previously relied on inline frames, but works nicely as a SPA. It follows a book-viewer metaphor where "pages" are placed within "chapters" within a "table of contents" within a "book". In addition to VCR style navigation links, users can use Home, End, ArrowDown, and ArrowUp keys to navigate from page to page.

http://rd.radile.com/rdweb/info2/home.html

Most of the intended content is yet to be filled in. Mobile users may toggle the visibility of the table of contents in order to free screen space for page content.






On Tue, Jul 7, 2015 at 8:51 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx> wrote:

Hi Nathan,

Interesting.

Fixing the position of the navigation at the top of the page
eliminates the need for navigation links at the bottom of the page.
That's something I'll keep in mind as a design strategy.

I have mixed feelings about fixing the position of the theme statement
(i.e., the lighter blue bar with the text "Social hope is faith in the
ability of human beings to care for each other.") Fixing the theme
statement in place reduces the height of the main content area. To me,
the main content area is functionally more important to the site than
the theme statement. So, on the one hand, fixing the position of the
theme statement helps preserve the visual consistency of layout, but,
on the other hand, it reduces the real estate of the main content and
thereby disrupts functional prioritization of the layout. I would
probably try some options like loading the theme statement at the top
of the main content (so it scrolls with the main content) or dropping
the theme statement on all pages except the home page. However, I might not like these options once I see them.

I clearly see the maintenance benefits of loading the main content
into a page. The web site header information, theme statement,
navigation links, and footer information--basically everything except
the main content--is in a single HTML file. If I want to make changes
to this information, I can do it one time in one file. Conversely, the
way my web site is currently set up, if I want to make changes to a
navigation link, I have to make the change in multiple HTML files, one HTML file for each page of my web site.

Moreover, loading the main content into the page avoids the need for a
page refresh when the user clicks a link. The web site header, theme
statement, navigation and footer are loaded only one time when the
user visits the web site. The only thing that changes is the content
of the DOM element with the selector id #content (i.e., the main content of the page).
This eliminates any white flicker while waiting for a page to load
because there are no more page loads after the initial page load. It
also reduces the amount of data that has to be downloaded while
browsing the web site, making the site more efficient in terms of
bandwidth and more cost-effective in terms of data charges for users.

Let me see if I understand the details correctly.

In the HTML file, you coded this in the anchor tag for the page on Care:

href="javascript:ht_html('care.html');"

The argument 'care.html' is the name of an HTML file that contains
only the main content for the page on Care. The care.html file does
not contain any of the header, navigation, or footer information. When
the user clicks on this anchor tag, the JavaScript function ht_html is executed.

In the JS script, you coded the ht_html function:

ht_html(s) {
$("#content" ).load(s);
}

The "s" argument in ht_html(s) and load(s) is a variable that is
replaced by the name of the file provided in the code
javascript:ht_html('care.html').

So, when the user clicks the link for the page Care, JQuery grabs the
care.html file and loads it into the DOM element with the id selector
#content.

Is this basically correct?


--
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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.