So, what’s the purpose of inline design construction?
The “purpose” is the same as what’s already been discussed: a bombproof layout that will scale with any amount of content.
This is the price to paid when using FW to build an inline layout. As I’ve said before FW was designed for table- and layer-based design, and even so it’s not difficult to break the Master/Child relationship. Inline construction, for whatever reason, will always break that relationship. It’s a very useful technique but a pain to use in FW.
One of the most painful things for me about inline-construction in Freeway
Pro is the way the app so often confuses a click with a move. Making that
interaction better would greatly improve Freeway’s usability for those
constructions. Until then, Site pane and undo are your only friends.
–
Ernie Simpson
On Thu, Jun 28, 2012 at 11:11 AM, Todd email@hidden wrote:
The “purpose” is the same as what’s already been discussed: a bombproof
layout that will scale with any amount of content.
This is the price to paid when using FW to build an inline layout. As I’ve
said before FW was designed for table- and layer-based design, and even so
it’s not difficult to break the Master/Child relationship. Inline
construction, for whatever reason, will always break that relationship.
It’s a very useful technique but a pain to use in FW.
Yes that makes sense, but what about fonts in an inline design?
I’m having problems with some of my pages displaying in IOS devices. They look fine on a PC, but when viewed on an IOS device some of my lines wrap. Should I be specifying fonts in pixels or something else?
MobileSafari on an iPhone or iPod touch uses complex scaling algorithms to resize text to make the page easier to read on a tiny screen. Note that you will not see this behavior on the iPad.
The larger issue you have to come to terms with is the idea that it’s your text and that it should appear to be a single line. You don’t get to choose that – the visitor’s browser does. Your design is a suggestion to the browser, which will interpret it in its own way. Your design should honor this, and respond gracefully to different fonts, window sizes, and other things you don’t control. Visually disabled visitors may set their browser to larger font sizes to allow them to read at all, again, it’s not your browser to control.
In your desktop Safari, in the View menu, turn on Scale Text Only. Now look at your page, and zoom up two levels and back down. What changed? Fix that. Now your design is better prepared for the real world of browsers you don’t control.
Walter
On Jun 28, 2012, at 11:44 AM, RavenManiac wrote:
Yes that makes sense, but what about fonts in an inline design?
I’m having problems with some of my pages displaying in IOS devices. They look fine on a PC, but when viewed on an IOS device some of my lines wrap. Should I be specifying fonts in pixels or something else?
Walter, I’m not seeing the Scale Text Only option under View.
On 28 Jun 2012, 4:06 pm, waltd wrote:
In your desktop Safari, in the View menu, turn on Scale Text Only. Now look at your page, and zoom up two levels and back down. What changed? Fix that. Now your design is better prepared for the real world of browsers you don’t control.
Sorry, it’s “Zoom Text Only” – I misremembered the label.
Walter
On Jun 28, 2012, at 12:30 PM, RavenManiac wrote:
Walter, I’m not seeing the Scale Text Only option under View.
On 28 Jun 2012, 4:06 pm, waltd wrote:
In your desktop Safari, in the View menu, turn on Scale Text Only. Now look at your page, and zoom up two levels and back down. What changed? Fix that. Now your design is better prepared for the real world of browsers you don’t control.
By not making your design too tight, or containers too narrow. Give these
thing a little more room to grow (make the div called “navigation” a little
wider to accommodate at least one level of growth).
–
Ernie Simpson
On Thu, Jun 28, 2012 at 12:33 PM, RavenManiac email@hiddenwrote:
Ouch! When I do that my CSS menu gets all screwed up. How do I account for
that?
So, as a rule of thumb, is it better not to use an inline design layout for the header (i.e. the section with the CSS menu)?
Unfortunately, I converted from a standard FWP layout to an inline construction midstream and the one thing that is not inline is my header section. What that means is that changes, like the one you suggested to my CSS menu, are relatively easy. Whereas, if they had of been inline I would have had to cut and paste a bunch of menus.
Of course, if I had of used an inline layout for the header and placed my CSS menu within an HTML container that floated right, would that have solved my menu issue to begin with?
My impression is that there is an optimal point for FRW layer design, beyond which a “bomb-proof” inline design is better.
Freeway is so good in layer design, that I tend to compromise with some differences how various browsers render the page.
Of course design is restricted in that I have to admit for more white space between the layers downward, so the page won’t break if zoomed up twice.
It’s a compromise, as everything else in webdesign.
/ my piece of thought…
/ Omar
::: Communication to improve civilisation :::
s_ip
On 28 jun 2012, at 17:11, Todd email@hidden wrote:
So, what’s the purpose of inline design construction?
The “purpose” is the same as what’s already been discussed: a bombproof layout that will scale with any amount of content.
This is the price to paid when using FW to build an inline layout. As I’ve said before FW was designed for table- and layer-based design, and even so it’s not difficult to break the Master/Child relationship. Inline construction, for whatever reason, will always break that relationship. It’s a very useful technique but a pain to use in FW.
Okay Ernie, I took your advice using a smaller font and modifying the CSS Menu action so the menu moves to the left. That way I can keep it anchored on the right, which is what I prefer for this design.
Unfortunately, after one level of increase the CSS Menu blows up.
Kelly
On 28 Jun 2012, 4:55 pm, The Big Erns wrote:
By not making your design too tight, or containers too narrow. Give these
thing a little more room to grow (make the div called “navigation” a little
wider to accommodate at least one level of growth).
By the way, since this website is intended for older users, do you think I should incorporate a button at the top that increases the size of the fonts?
When I have seen that done, I think there’s a javascript for it. However,
my bet is that older users are already hip about how to zoom pages.
–
Ernie Simpson
admitting your age and admitting that you’re old are not the same thing…
On Thu, Jun 28, 2012 at 3:00 PM, RavenManiac email@hidden wrote:
By the way, since this website is intended for older users, do you think I
should incorporate a button at the top that increases the size of the fonts?