Charlie's Frog Pond/Talk

This page is for discussing the contents of Charlie's Frog Pond.

Discussion from (BradMandell) related to placement of image on this and other pages with Table Headers.

Photo placement in RocWiki suffers from four main issues:

• RocWiki has no current facilities for flexible design consideration of browser window sizes.
  

• Limited control over images based on the Image and Flickr macros, and no control (except through tables) over directly addressed images.
  

• Substantive differences in browser handling of image placement from left, right, no parameter, tables and headers.
  

• Displayed table widths depend upon the nature of the text within a column, word breaks, and the browser settings for font size, etc.

Many editors, and even web designers, tend to layout information based on their particular display, browser, browser window size, browser option selections, font size, colors, etc. Many are unaware that their editing and layout decisions have impact on other viewers. Best practice for website design suggests testing across a variety of user environments. For individual editors, viewing the page in a variety of browser window widths and magnifications can improve layout choices and avoid artifacts.

Previous webpage design guides suggested designing to an 800 pixel width and RocWiki has some parameters geared toward that design criteria. However, guidance is now changing in that, as of Januay 2009, 93% of browsers are 1024 pixels or wider and 57% are greater than 1024. ¹

Impact of Display and Browser Window Size

Below are screenshots from displaying Charlie's Revision 36 with a variety of window sizes within the Mozilla browser. You may see different results from Interent Explorer or other browsers or if you have a different display size, magnification or other browser settings. The images below are for simple ease of comparisons.

The Large Display (lower center in images below) is Charlie's page displayed on my 1920 pixel wide laptop. The image placement creates a very large white space between the elements, not usually a recommended layout choice. Larger displays are becoming defacto on newer desktops and higer-end laptops. The wide-screen users may also use several browser windows simultaneously - sometimes quite small ones as well. These viewers may also see the artifacts for Small Display, shown below.

The intervening white space is obvious in the 1024 image (93% of viewers) and quite obvious for the 57% with 1280 and up displays.

The small display or small browser window (shown at right in table below) creates another problem caused by the way some browsers handle the image placement with "right" alignment. For Mozilla and Internet Explorer, the image will jump ahead of the information table, forcing the table below the image. Similar problems occur on smaller devices, which are becoming a big factor in web access.

Impact of Browser Window Size>
Most = 1024 Display	Majority = 1280 Display	Small Browser Window
	Large Display

A Proposed Solution

I have been making adjustments to Header Tables and images in consideration of the above. I use table placement of images as one of the techniques to deal with some of the issues. I have been making adjustments to the text within tables to compact the data, and allow better word breaks in long text strings. Some aspects of this were discussed earlier in Google Groups Thread -Templates and Complex Entries.

The recent changes and revisions to the Charlie's Frog Pond page suggest further discussion amongst a wider audience of editors in RocWiki so that we do not engage in Revision Wars:

My changes to the page included the photo in the Table header:

 ||<class="tablehead">'''Location'''||<|12>[[Image(FrogPond.jpg,

   "Front View - 1-2008",300 , thumbnail, right,noborder)]]|| 

Looking back to Revision 35, the page displayed with the photo connected to the right side of the header table as shown at right. No matter how small, or how large the browser window, the image position remains, the table header information stays to the left of the image and an editor selectable white space separates the two elements. For small displays, horizontal scroll bars may appear.

Revision 35 with Table

I began my quest to summarize restaurant reviews because links tend to go dead after awhile, and this loss of potential content bothers me, so I thought it'd be cool to summarize reviews within the body of each restaurant page (in addition to linking to the review until the link is dead). Let me know if you think this is a bad idea, or feel free to help if you think this is a good idea! Thanks :) Also, I have no idea why the summary review and everything below it is appearing bold and italic. Help, anyone? —RachelBlumenthal

Comments:

Note: You must be logged in to add comments