Blog

When it comes to designing layout for on-line content, what size is the right size?  How does one design for multiple screen sizes without spending duplicate effort on multiple designs. The answer depends on what size windows users are using to access the site.  For me, creating a variable fixed width design based on both 960 pixels (large) or 700 pixels (medium) helps minimize duplication of design effort.

Monitor Sizes and Screen Size

The following is a list of screen sizes that are typically used.  Larger monitors can set their resolution to sizes in between those listed below.  Browser window sizes are usually smaller than the screen size.

• 320x240 - mobile CE device size
• 640x480
• 800x600 - typically smallest screen size in use
• 1024x768
• 1280x1024
• 1680x1050
• 2560x1024 - typically dual monitors at 1280x1024 resolution

The three most common minimum screen sizes in use in 2008 are:

• 800x600
• 1024x768
• 1280x1024

Dave Shea outlined in The Web Beyond the Desktop some of the complexities in designing for numerous screen sizes and how to use server side methods of selectively dishing up style and content.

Best Size For Design

Monitor size is not screen size. There appear to be two differing camps in approaching the size limitation for browser windows.  Some argue that a fluid layout is the most desirable because as a user re-sizes their browser, the layout should resize as well (Screen Resolution and Page Layout). Others argue that a fixed size is better because it allows a designer more explicit control of the layout. I believe that users ultimately set the width of what they want to view via the browser window, not the designers and if I take that point of view, then the question for me is how much are designers willing to cooperate with what the user wants to see from a layout perspective for width and height (up to a point).

In the ideal world, a designer could specify a layout with a minimum and maximum width and let things be fluid from there. However, with the limitation of today's browsers (okay really IE) not being able to support minimum and maximum widths, it makes it difficult to support a fluid layout properly without hacks.  IE is notoriously poor (i.e. IE 5, IE 6, IE 7, with IE 8 TBD) at supporting CSS min-width and max-width.  Numerous people have developed several CSS hacks, but these are nonetheless hacks and when IE changes, the hacks will have to change.

It just doesn't set well with me to design a solution using hacks for 70-80% of the users that visit a site.  In my experience, even the hacks don't weal with very narrow windows where the window begins to collapse and layout becomes unreadable.  For this reason, I prefer a minimal fixed width design for most solutions.  A fixed width allows a minimum width and a maximum width, they just happen to be the same.

Fixed Width Sizes

I've seen the concept of using grids for design before, but until I saw Nathan Smith's 960.gs images on the grids, it didn't really dawn on me the usefulness of using grids to create common layouts for multiple window sizes. More people seem to be moving toward taking advantage of a full 1024x768 size layout.  But, just because their screen sizes are larger, doesn't mean that a users browser window is necessarily larger.  I have a 22" monitor (actually some times I have two side by side) but I personally don't like sites to use up my screen width.  I prefer to use a browser window of about 800-900 pixels.  This allows me to have two windows open in parallel.  I really don't prefer sites that force me to open a browser window to a full 1024 pixels wide.

Nathan outlines in the 960 grid design a grid of using 16 columns of 40 pixel increments, or 12 columns of 60 pixel increments.

I've created some Microsoft Expression Blend templates based on Nathan Smith's 960 grid layout.  The zip file of the Expression 960 grid templates can be downloaded here 960_Expression.zip (516.38 kb). Based on the spirit of Nathan's 960 grid design, these Expression templates are free for your use and licensed under GPL and MIT licenses.

16/10 Columns

Using a margin of 10 pixels with a gutter of 20 pixels leaves a design layout with a minimum inside dimension of 940 pixels (for larger windows), or 700 pixels (for smaller windows) depending on the minimum window size.  Using a grid spacing of 40 pixels, this creates a design pattern of 16 columns (large) or 10 columns (medium)

12/8 Columns

Again, using the same margin and gutter sizes above, and a using a grid spacing of 60 pixels, this creates a design pattern of 12 columns (large) or 8 columns (medium), but with the same overall dimensions for each basic column.

13 Columns

After some further review, I found that using 13 columns of 40 pixels each and a 20 pixel gutter allowed a 780 pixel wide format with an internal width of 760 pixels.  While this allowed a slightly wider content, the symmetry of the 12 and 16 column layouts is in my opinion lost and this approach is less elegant in my opinion, despite have slightly more room for content.

Variable Fixed Width Sizes

Variable fixed width sizes sounds like an oxymoron.  Like a 50" big screen LCD TV the size of an iPod, how do you get both variable widths and fixed widths. Richard Rutter outlined in Variable Fixed Width Layout using some different techniques to accomplish the result.  The net from my perspective is:

1. Use JavaScript to switch between alternate the class settings based on browser width.
2. Use JavaScript to set alternate style sheets based on browser width.
3. Use CSS Floats to set the "extra" columns position based on the layout.
4. Use CSS to set multiple columns width based on the layout.
5. Use a cookie to set the layout width.

I can't say that any one technique above would be preferred by me, but it would entirely depend on the designer's and coders decision on which technology they prefer and how they want to minimize multiple style maintenance. 

Based off my experience of having to support both IE and a mobile device using the same application, the cookie combined with JavaScript and multiple style sheets when done correctly seems the most flexible, albeit a bit more maintenance.

Screen Sizes In Use in 2008

As a side note, it appears to me the percentage of users using 800x600 resolution is decreasing each year. Joshua David McClurg-Genevese reports in Designing for the Web  in 2004 it was 35% and in 2005 it was 28%. In 2007, browser display statistics for users at 800x600 resolution might typically be 14% of all users. The usage on this site and others I monitor indicates that typically a size of 1024x768 or larger is used to access a site with typically 800x600 in the 2-4% of overall users. 

Does that mean people are buying new systems with bigger monitors or are they replacing their 800x600 monitors with bigger ones?  I don't know.

Conclusions

Nathan Smith's 960 grid ultimately help me find what I was looking for, a set of common column sizes to use for design regardless of the browser width.  The Variable Fixed width technique also helped me reach a decision for some size layout issues I was struggling with.  The next step for me is to try a few of these techniques in some new sites to see how I like the concepts.

References

1. Dynamic Resolution Dependent Layouts
2. Resolution dependent layout
3. Switchy McLayout
4. Screen Resolution and Page Layout
5. W3C CSS2.1 Length Units
6. Best Screen Size For Web Design in 2008
7. Designing for the Web
8. The Web Beyond the Desktop
9. Server side methods of selectively dishing up style and content
10. WURFL - Wireless Universal Resource File
11. Variable Fixed Width Layout
12. CSS Drop Column Layout
13. Redesign Notes 1 Width Based Layout
14. A Dao of Web Design
15. Body Switchers
16. Style Switchers

How to create a new account in Windows Live Writer for a site using BlogEngine.Net 1.3.0.18 or later.

Add a new weblog account.

Select Another weblog service.

Enter the Homepage URL, username, and password.

Live Writer will detect the weblog settings (If you use another service that supports other formats, you'll be prompted what API and URL to use).

I recommend letting Live Writer detect the theme.  Live Writer does not successfully delete the test post so you will have to do that manually later.

Your done.

How to use ASP.Net Cache settings to automatically read and update values from an XML file when the file is updated, and how to lookup a value in the XML file.

.Net surprises me every day.  I think about how I want to do things and then I dig a little (some time a lot) into .Net components and viola, I find it provides some new interesting functionality that I didn't know about before. 

I recently wanted to implement some features for using configuration values for an ASP.NET application.  My requirements were as follows.

1. Implement an Admin page to allow writing / updating the configuration file.
2. Use an XML file format for the configuration data.
3. Cache the data in the IIS cache once read
4. Update the cache if the XML file was updated
5. I did not want to utilize a database
6. Since these would be updated frequently, I did not want to utilize the web.config

I found the ASP.NET Cache.Insert method to be the key for my needs.  By creating a Cache Dependency tied to the configuration file, when the file is updated, it will automatically update the cache.  This is the same behavior as the web.config file, but without some of the same permission access issues when trying to write to the file.

I could have used a NameValueCollection to do the same thing, but I wanted to use the DataSet in this instance.  I added the PrimaryKey value to the DataSet and .Net took care of the lookup of the data with Rows.Find(). 

Note: In order to write to an XML file via ASP.NET code, the directory must have write permissions enabled on the IIS user account (ASPNET, or Network Service, or the ID used in the application pool, or virtual directory).

The code for this particular logic was placed in the App_Code directory, so it could be accessed from code as well as ASP.NET pages via something like the following.

public static String CustomSettings(String keyValue)
{
    DataSet oDS;
    String szXMLFileName;
    String foundValue = "";
    oDS = (DataSet)System.Web.HttpContext.Current.Cache["Settings"];
    if (oDS == null)
    {
        szXMLFileName = SettingFileName();
        oDS = new DataSet();
        oDS.ReadXml(szXMLFileName);
    
        CacheDependency oCacheDependency;
        oCacheDependency = new CacheDependency(szXMLFileName);
    
        System.Web.HttpContext.Current.Cache.Insert("Settings", oDS, oCacheDependency);
        
    }
	
    DataColumn[] oKeyCols = new DataColumn[1];
    DataTable oTable;
    DataRow oRow;
    
    oTable = oDS.Tables["Attribute"];
    oKeyCols[0] = oTable.Columns["Key"];
    oTable.PrimaryKey = oKeyCols;   
    oRow = oTable.Rows.Find((object)keyValue);
    if (oRow != null)
    {
        foundValue = (string)oRow["Value"];
    }
	
    return foundValue;
}

Settings.xml located in the App_Data directory

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Configuration>
    <Attributes>
        <Attribute>
            <Key>PageTitlePrefix</Key>
            <Text>Page Title Prefix</Text>
            <Value></Value>
        </Attribute>
        <Attribute>
            <Key>PageTitleSuffix</Key>
            <Text>Page Title Suffix</Text>
            <Value> - Tim-Stanley.com</Value>
        </Attribute>
        <Attribute>
            <Key>SiteName</Key>
            <Text>Site Name</Text>
            <Value>Tim-Stanley.com</Value>
        </Attribute>
        <Attribute>
            <Key>CopyrightName</Key>
            <Text>Copyright Name</Text>
            <Value>TSI Systems LLC</Value>
        </Attribute>
    </Attributes>
</Configuration>

Cameron Moll has posted some incredibly useful information on his site regarding CSS, JQuery, AJAX and extensibility in a set of articles titled The Highly Extensible CSS Interface.  The information is PHP oriented, but the concepts certainly apply to ASP.NET.

Short on the heels of the Visual Studio 2008 release in November 2007, Microsoft released in early February a hot fix that contains several fixes.  I took a bit of time before jumping on the Hot fix for production projects, but there are several IDE editing and build improvements for those using ASP.NET. 

Based on the list of fixes surrounding HTML source view / HTML editing, JavaScript editing, and web site  build performance, it looks very compelling to apply this fix .  I've updated today and see no adverse side effects yet.  The hot fix installation instructions state it can be uninstalled in the future if needed.

The information on the hot fix details and the download can be found in Scott Guthrie's post VS 2008 Web Development Hot-Fix Roll-Up Available.

Those who've read the book The Mythical Man-Month: Essays on Software Engineering know the mantra Adding manpower to a late software project makes it later.  But why does it make it later?  How many resources should you put on a project to optimize the delivery date?  How do you explain and justify to the customers and teams the optimal number of resources to be on a project?  How do you explain that adding more than the optimal resources won't make the delivery date sooner?  Resource saturation is my answer.

Optimal Delivery Date And Optimum Resources

I started with a simple premise for planning project.  Something that was a known size, I could add as many resources as possible, but the delivery date needed to be as soon as possible. I don't often get offered unlimited resources, so I was intrigued with the plan.  Some assumptions I noted for estimation.

• The scope was 24 man months effort
• The lowest granularity of the work is one month
• There are no critical path dependencies between 24 work items
• There is zero ramp up time for adding a resource to a project
• There are no vacations, sick time, or holidays
• 1-24 resources could be added
• Optimize delivery calendar time
• 10% communication time between team members (four hours per week)

Adding resources to a project helps initially.  Once the team reaches a certain size, the amount of time saved by adding an additional resource has very little impact on the delivery time.  I used a factor of 10% of the time per resource spent in just communications (e-mail, meetings, discussions or interactions with other members of the team).  That number is likely too low compared to an average organization and likely unrealistically low for large organizations which have a significantly higher communication overhead, but for the initial optimization of resources, it doesn't really affect the optimum number of resources by a significant amount of calendar time.  I built a simple spreadsheet to do the calculations.  My spreadsheet had more detail, but hopefully you get the idea.

• 1 resource, 24 months
• 4 resources, 6.4 months
• 6 resources, 4.6 months
• 8 resources, 3.4 months
• 12 resources, 3.2 months
• 16 resources, 3.1 months

We can see that four resources instead of one cuts the time to 25% of the original 2 calendar years.  Six resources, cuts it to about four months and two weeks.  Eight resources, cuts it down to three months and two weeks.  From there, it takes an additional four resources (for a total of twelve) just to bring the delivery date in one week earlier (3.2 months).  Doubling our eight resources to sixteen only saved two weeks on the calendar time delivery.  What happened?  We hit resource saturation.  I put together the image below to show what resource saturation looks like and how adding resources affects the project time it takes to complete the work.

Resource vs Time

Resource vs Time showing resource saturation above eight resources.

If only 10% of developer time was spent in communication, by the time we hit 10 resources, we had the equivalent of one full time person doing nothing but communicating.  That causes and interesting thing to our costs.  As we add resources, we are adding communication to the team.  That adds costs, which goes up non linearly.

Resource vs Cost

Adding more than eight resources didn't affect our delivery date by more than two weeks, but adding more, certainly increases our costs.  Optimizing both resources and costs gives us a a good range for planning.  I've rounded the numbers up to the nearest week.  This is the type of information that we might need to present to a team or a customer.  This doesn't take into account vacations, sick time, or holidays, but it does give a rough number for resource planning and allocation.

• 6 resources for 4 months and 3 weeks
• 7 resources for 4 months and 1 week
• 8 resources for 4 months

We now have enough data to logically explain planning questions.

• How long do we anticipate the project to take?  Approximately 4 months with 8 resources or 5 months with 6 resources.
• Can the project be completed in two calendar months? No, regardless of the number of resources, the full scope can not be complete in two months.
• Can the project be completed in three calendar months? It may be possible, but it's unlikely it can be completed in three months.

The most significant thing that can be done to improve the delivery time is to prioritize the features and delivery less feature and function in a shorter time and then follow with a subsequent release with the remaining function.  The next most significant thing that will affect the delivery date is the injection of overtime.  While I'm not a fan of using overtime for planning, once resource saturation occurs a 10% increase in time can shorten the delivery date because it doesn't typically add an increase in ramp up time or an increase in communications to the team.  Planning more than 10% overtime over any extended period of time is unsustainable and unrealistic planning.

Adding Resources Makes a Project Later

We found an optimal number of resources, and an optimal time and delivery date, but I still haven't answered the question, why does adding resources make a late project later?  Once resource saturation is achieved, adding resources to a project underway does two things.

1. It Increases the amount of time that an existing team member must spend in explaining what has been done already and what is planned.  This increases the overall communication time spent by the team.
2. It increases the amount of ramp up time that a resource must spend on learning what has been completed already.

I was reminded of this both by prompting from a customer and by an article Jeff Atwood wrote on Revisiting The Facts and Fallacies of Software Engineering.

The model I show doesn't exactly simulate adding resources to a late project, but it does show what happens when communications is increased.  Instead of having 10% communication, what if we increase the model to 33% communication overhead, what happens?

Instead of decreasing the time to delivery, it actually takes more time.  24 resources take the same amount of time as 3 resources.  After resource saturation, adding resources makes projects later.

Help authoring tools like RoboHelp and Doc To Help provide the ability to generate PDF, Word .DOC, and compiled html help (.CHM) from a single HTML source.

Some time ago, I needed the ability to generate other forms of documentation for help files other than HTML.  The original content was authored as a standalone simple HTML (h1, h2, ul, ol, dd, dt, p, etc.) with images and used a common style sheet.  I needed the ability to generate other forms of documentation that could be printed and transmitted over the Internet to clients (Word documents, PDF, etc.). 

Requirements

The general requirement was for end user help for administration screens, not for programmer internal object or API help.  There are further tools that are more suited for generation of programmer API documentation (like Microsoft Sand Castle on the Codeplex Sand Castle site)

1. Help documentation was originally written in HTML pages (standalone read from files, no ASP.NET or IIS Server)
2. Generation and distribution of standalone PDF’s
3. Generation and distribution of standalone .CHM (Microsoft Compiled Help)
4. Generation and distribution of standalone HTML files viewable in Internet Explorer
5. Generation and distribution of standalone Microsoft Word.doc files.
6. HTML Used as primary Help and displayed in IE.
7. Table of Contents written in HTML Pages
8. Include HTML Images in all output (PDF, DOC, CHM) without requiring re-work.

Help Authoring Tools Evaluated

• RoboHelp by Adobe new $999, upgrades from $499
• Doc To Help by Component One new $900, upgrades from $500
• Microsoft HTML Help 1.4 SDK - Free

In evaluating the tools, I already had existing HTML documentation with images present.  If I were creating a new documentation solution from scratch, I might have chosen a different tool or approach.

The Microsoft HTML help compiler generates .CHM files from HTML, but it does not generate Word .DOC, or PDF formats so this didn't meet the requirements.  Both RoboHelp and Doc To Help utilize the help compiler to generate the .CHM files.

Doc To Help generated CHM files, PDF files and Word Documents, but generation of documents took a very long time (i.e. 20 minutes or more).  The output of the images in the PDF and Word Document was problematic.  I never could figure out how to generate the "contents" of those documents correctly.

RoboHelp generated the CHM files, PDF files and Word documents fairly quickly (less than 5 minutes).  The images were placed correctly, and with only minimal work I was able to generate the table of contents for all documents correctly.

Both tools provided the ability to edit HTML content, but this wasn't really utilized since all content was already in HTML format.   Both tools also provided the ability to utilize the existing CSS style information when it generated the documentation.

Robohelp was selected because it was significantly faster and had fewer errors in generating the required output than the Doc To Help product. Doc To Help would have required further investigation and “manipulation” of the original HTML source in order to generate .CHM or .DOC files without errors.   It's been used for several revisions of the documentation and it still works fine.

RoboHelp has also been a consistent Award Winning help generation product and has won the Best .NET Products of 2007 for Help Authoring.

Differences In Output

Why generate different output formats?  Each format has unique features that the other formats don't offer.  Some clients reviewing our documentation prefer one format over the other.  In particular, many clients prefer the ability to print the full set of documentation for review when evaluating the product.  Each format helps support the sales cycle as the circumstances dictate.  Printing in HTML and CHM formats is listed as poor because these formats only allow printing one page at a time.

Sample Output

HTML Help sample viewed in Internet Explorer

PDF Help Sample Output from RoboHelp

Microsoft Word Sample output from RoboHelp

Compiled Help Sample output from RoboHelp

API Documentation Tools and Links

• Sand Castle on Codeplex and Sand Castle Docs
• DocumentX by Innovasys about $594 USD for one user, 2008 version
• NDoc on Sourceforge - no longer updated
• VB Commenter in Power Toys for Visual Studio  - No longer needed in Visual Studio 2008