Things I Learned Through OFPv2's Redesign

I learned and relearned a number of things designing other sites and pages and through this redesign. This page will chronicle some of these items, though not necessarily in the order I learned them. Hopefully they will serve not only as a reminder to myself for future designs, but as help for others if they find themselves in similar "binds". May we all keep learning about things that interest us, and continue to find those things that interest us, for all our lives. -Bill Sanders

Disclosures

• I use FrontPage 2002 (10.6308.6735) SP3 as my WYSIWIG editor. It's not perfect - and don't give me crap about that, because NO WYSIWIG editor will be "perfect - All will have SOME problems rendering. It works pretty well for me.
• I DO NOT have a personal server set up on my Windows XP Pro computer. I probably should, but have not really found a real need to set it up. I'm a little afraid to, think it may be a little "too techie" for me to do, and I worry about security. Therefore, verification that some things will work is "live". While I created a FrontPage subweb to the original site for testing the new version, and have tested it as best I can, I don't doubt I missed some things.
• I DO NOT have access to browsers other than Microsoft Internet Explorer (IE) v6 and Firefox v1.5 (especially at the time of the redesign). This does not mean that I wrote the markup and styles for IE and IE alone. However, I wanted to get the new version of the site out ASAP
  • A quick check, shows that Firefox seems to have a problem with the negative margin and 100% width I used to define the divs INSIDE the main-page div (to the right of the sidebar. Oh, it displays everything, but with the main section of the page defined at 100% width, it appears to push the right side off the page the width of the sidebar. For now, if you use Firefox, just shift the page to the right. The sidebar will shift off the page to the left, but all/most of the content should appear. (I HATE trying to write things that work in multiple browsers.)
  • 09/2006 - I changed the full-page, sidebar and main-page divs so there's no negative margins. It appears to have taken care of SOME of the Firefox problems, but I noticed that the page-bottom div appears near the top of the page. Hmmm...
• If you use other browsers and encounter any major problems, let me know. I will need to know what the problem was, what page it appeared on, and (if you have one) a solution. Again, I do NOT have access to other browsers, and any "testing" with them will have to be "live". (Ugly, I know, but it's what I got!)

Oh... And don't "flame" me because some of the following stuff is obvious to YOU. Many who will read THIS page are more "techie" than I am, started designing pages younger than I, have taken classes, and have designed MANY more webpages. I am self-taught. I spent a lot of time on the internet researching almost everything I've done here. If you have SUGGESTIONS, I welcome them. If you have complaints, please couch your complaint as "criticism" instead of a rant or bitching at me. I will take suggestions, advice and polite criticism well. Otherwise, you may just be told to fu... uh... "bug off".

What I Learned/Reminders

Here's some of the stuff I found (some from prior design work). I hope it helps me remember, and helps others:

• Obviously there are a lot of browsers out there. Not all work the same. (Duh!) I tried as best I could with the limited resources I had to design this site so it will work the same (at least to some degree of standardization) in many of them. Obviously, this IS not (see above IE/Firefox note) and WILL NOT be the case. I DID NOT use any FrontPage add-ins or components.
• SSIs (Server-Side Includes) - As I noted on my Redesign Page, while there's quite a bit of documentation on SSIs out here, it may be difficult for some (like me) to understand a couple of things:
  • On many servers, if a page has to be named with a ".SHTML" extension or type, it will be the page IN WHICH the <!--#include xxx --> statement is located, not the file being included (unless, of course, it too has an include statement - Yes... They CAN be "nested").
  • SSIs and FrontPage (and, probably, others) - Don't forget that if you design your SSIs in your main section and move them to another folder, all links will need to be modified. FrontPage modifies link to moved files (except certain circumstances, like included files) to keep them working. SSIs are loaded into your page by your server when the page loads, so any image or included file in them needs to be modified to point to the correct folders from the page in which the include statement is located. (A little complicated, I know, but not too difficult once you get the hang of it.)
• FrontPage WYSIWIG
  • I tend to leave the "Show All" button turned on, so I can see where everything is. This shows a graphic exclamation point ("!") for all HTML comments including all SSIs and Javascripting, which should also be wrapped in a comment. This can be a bit confusing, at times. REMINDER: You can turn it off, if you wish, using the "paragraph mark button" (Show All) although a quick click on the PREVIEW tab will show the page without showing them, too. BUT, PREVIEW starts at the top of the page. If what you wish to see is "further down the page", you will need to scroll through everything, including all the comments, to view it.
  • FrontPage (at least 2002) DOES NOT have a way to introduce inline SPAN classes with a single click or two. It's possible to include SPANs in the CSS for each generic class defined for which you will need it (see Webmaster World's WYSIWYG and Text Code Editors forum Off Site New Window), but doesn't that just add unnecessary code to the style-sheet? Styles ARE supposed to be generic (inline AND block), right? The styles listed in the styles menu (above the VIEWs sidebar) only show one "Default Character Style", but THAT REMOVES the style from what's selected. If you don't use the CSS trick, above, you need to actually edit the HTML to make inline changes. (BTW: I've noticed there's no way to add various "STANDARD" character- and word-based styles - HTML tags like <em>, <strong>, <code> and others - without directly editing the HTML, at least in FPv2002). [see following bullet-point]
  • That last BTW is wrong. I found them in the FORMAT/FONT menu. In fact, I've found a couple of short-cuts that work for me in coding SPANs and DIVs:
    • For SPANs, I highlight what I wish to make a certain class, and make it <STRONG>, then I edit the HTML, changing the <strong> to <span class="xxx"> and the </strong> to </span>.
    • For DIVs, I highlight the lines I wish to handle with DIVS, and click the "Increase Indent" button. FrontPage puts an open and close <blockquote> around the statement(s) or paragraphs. Then I edit the HTML, and change the <blockquote> to <div class="xxx"> and change the </blockquote> to </div>. (I'm a "tab-a-holic", using TABS to format my HTML, making it easier for me (and others?) to read, NORMALLY, I have to tab all the lines between the open and close div to format it the way I like. So, after changing the open blockquote, I do so to the close blockquote, and change it.
  • Especially in the "off site" "inline buttons" (ie: Off Site New Window)
    • When you put borders around a word or phrase (inline - say, instead of an image, for a note or for a link), NORMAL (editing) Mode will not display it correctly. (This is one of the situations that belies the WYSIWYG of FrontPage, huh?)
      • Padding - left and/or right - Putting an escaped Non-Breaking Space ( ) in the text will display another border/vertical line against the word. Padding will work, even if it's not shown in NORMAL Mode. NOTE: BOTH METHODS (Padding or Non-Breaking Space) WILL WORK, though using left/right padding in the CSS is more ... "elegant" and probably semantically correct. Be sure to verify what it will actually look like by looking at it in PREVIEW Mode. See note about links, below.
      • Padding/Margins - top and/or bottom - NORMAL Mode will display the chosen font (or the first in a list of fonts) sized correctly, but borders will DO NOT DISPLAY, and despite sizing of the text and padding, it will display as if it was the full height of the line (most of the time, you're going to want to shrink the font in these a little, at least) and the text will appear at the bottom of the "box". Again, the padding works, and again, you will need to verify in PREVIEW Mode.
      • Because of this, you will need to experiment with your style until you get it to look the way you want it to (in PREVIEW Mode).
    • The <SPAN> color ("New Window" - right side) will not display colors correctly on my computer, even in PREVIEW mode. It appears that this happens only if the link begins with "http://" (an external link). Apparently, it needs to (and sometimes doesn't) actually "connect" to the internet to appear correctly. To verify that the inline buttons look right, use a blank link, or remove the "http://" temporarily (makes it a "local link"). UPDATE: I've found that if the link contains the "http://", even online, it may not display correctly. This also applies to the general "Off Site/New Window" buttons, but the colored side matches the page colors. If the links are internal (no "http://") they seem to work correctly. Still trying to work this out.
    • At times, cutting and pasting sections of code in NORMAL mode, with inline buttons loses the <SPAN> tag part of the button. BE CAREFUL. Double-check these, and make SURE they are included. (Also, be careful when cutting and pasting LIST elements. the </LI> may be included and pasted where it shouldn't be.
• HTML
  • From information found at "Anatomy and Deployment of Links" Off Site New Window:
    • When defining a "fragments" (link to a portion of the same page), be sure to not only use name="xxx", but also id="xxx" in the anchor. Remember that name="xxx" is depreciated and apparently should not be used in HTML 4.01, except for backward compatibility.
    • [Remember, also, that if you REMOVE a bookmark (fragment) using FrontPage 2002, it will remove the name, but the id will remain.]
    • When using images for links, be sure to include both description and destination in the alt="xxx" attribute. (And, remember, alt="xxx" is required for ALL images, is used for aural browsers, and appears in the tool-tip of images, especially of non-titled (should never exist, but do) links.)
    • When defining links, use real words to describe them AND use the title attribute, which appears as a tool-tip.
    • [NOTE: To implement these, I will have to revisit many links... especially in the Link Central pages. There's NO guarantee that all will be changed this way any time soon.]
  • I knew these before, but tend to forget when creating new pages, so I thought I'd reiterate them here:
    • "HTML divs are for page layout. Tables are for tabular data". This Discussion on the Daily WTF Forum Off Site New Window: shows this quite well. But remember, even webpages with tabular data should use tables, not divs!

    • If you try to put quotes or other punctuation around a link, while it will work to code it as follows:

      ... "
      <a href="url"
      	title="short description">
      	Here's a Link</a>
      &quot; ...

      to help "see" the links in (and to "prettify") the HTML, it will cause a space between the punctuation and the link. The above code produces:

      ... " Here's a Link " ...

      (Note the spaces between the link and the quotes?)

      To keep this from happening, it MUST be coded with NO WHITE-SPACE between the punctuation and the opening <a tag for the front of the link; NO WHITE-SPACE between the anchor close bracket and the first displayed word (or the opening of an <img tag), and NO WHITE-SPACE between the last displayed word (or the closing angle-bracket of an <img tag), the anchor close tag </a> and the closing punctuation. For example, the link above CAN be coded as follows:

      ...
      &quot;<a
      	href="url"
      	title="short description">Here's 
      	a 
      	Link</a>&quot;
      ...

      and produces:

      ... "Here's a Link" ...

      ... MUCH "cleaner"-looking.

    • Using <pre> tags
      • All code between opening and closing <pre> tags appear in most browsers as they are entered in the HTML. In other words, it will include all line-breaks, tabs and spaces in it. If you "adjust" your HTML to be more readable, and want your <pre> code to appear left-justified in a container div (as above), you MUST put (at least) the code between the tags against the left-margin of the HTML.
      • <pre> tags do NOT preclude hypertext links. If you are describing something like the above, you need to "escape" at least certain characters, like "<" (<), ">" (>), quotes ("), any non-breaking spaces (  and probably others.
    • The title attribute can be used on many HTML elements/tags. If you break up a long title to make it fit in your text editor or HTML screen, in some browsers, the tool-tip produced when the user rolls the mouse onto the element/tag and pauses, will include all the line-breaks and spacing that appear in the HTML. (If you "line up" your HTML using tabs or spaces, all of them, AND the line-break will appear in the tool-tip.) Element/Tag titles work something like a <pre> tag. While you COULD do some "arranging" by breaking lines logically and leaving the broken line to the far-left in the HTML code, 1) it's ugly HTML; 2) not all browsers will show it the way you "arranged it" (some will cut it off at the line-break); and 3) you MUST remember that tool-tips only appear for about five (5) seconds - If you put much more than a couple of lines (wrapped normally, if it will), MOST users will not be able to read it.
    • One error can cause the HTML validator to report many. For example:
      • If you include links in your pages, if there are ampersands ("&") in the link (these identify variables passed), and you haven't "escaped" them (ironically, escape an ampersand in a link with "&"), the validator counts the "&", the characters following, usually to an equal sign ("=") AND the equal sign (basically saying it couldn't generate a system identifier for the entity - the characters between "&" and "=".) Escape the "&" and all will be forgiven.
  • The Printing CSS MUST be tested thoroughly. Most Positions must be made "static" and most floats must be dropped. Remember, though, I am going to make a print CSS that drops the sidebar, probably the breadcrumbs, and linkbar and print most as black on white. I also want to make sure all links are shown in some way, probably related to something in A List Apart: Articles: Improving Link Display for Print Off Site New Window.
  • There seems to be a problem using any of my colored background blockquote replacements - hbbqr??, where ?? is background color, inside a bqr (blockquote replacement div. They appear correctly in FrontPage NORMAL mode, but not in FrontPage PREVIEW mode. I'm not sure what the problem is. There's no color background on BQR... *confusion*. Hmmm... MAKE SURE ALL THE close DIVS (</div>) FOR THE PAGE EXIST! I've found that if they don't it can cause this situation.
• More to come, I'm sure.

Send email to Bill Sanders ()
with questions or comments about this page or site.

This site, all text and graphics (unless otherwise noted) on it
were designed, developed and published by Bill Sanders of Orange Frog Productions.
It and it's CSS was validated and complies with both the: CSS and HTML 4.01 validators from W3C.
NOTE: All CSS validates except the "New Window Buttons" - Their CSS includes  some invalid code (ie: hacks)
and warnings for using transparent backgrounds when color foregrounds defined.
Copyright © 2003, 2004, 2005, 2006 by Bill Sanders / Full site last modified: July 10, 2006