17. January 2013 21:54
by Troy
0 Comments

Website (Re)Design - What is Important Today?

17. January 2013 21:54 by Troy | 0 Comments

Mobile devices.  More on that later.

I decided that it was time to update my website with a new design.  The previous one had been around since 2002.  Since then, the site had seen some content updates and a few technology updates, but nothing major.  Nothing architectural.  Nothing visual.

I began the process of redesign by doing some research and identifying some requirements.  I also identified some specific technologies that I wanted to use, mostly out of interest, since this simple site could be completed successfully in many ways.

The requirements:

  • Mobile device compatible
  • Responsive UI design (related to mobile device compatibility)
  • new look and feel - new design, something different
  • adopt HTML5 and CSS3
  • adopt MVC (Model-View-Controller) with extension-less URLs (like /Resume instead of /Resume.aspx)
  • support proper redirection of URLs that changed because of above, so that old links to my site would not return a 404 Not Found
  • support for canonical URLs
  • custom 404 Not Found page
  • update blog to use latest version of BlogEngine.NET
  • provide a printer friendly version of my online resume

If you are redesigning an existing site or application, the size and scope of the work has to be analyzed to determine the best implementation strategy.  In my case, the site was small enough and simple enough that a complete re-write was the logical choice.  For larger projects, a phased approach might make more sense and would probably deliver business value sooner than attempting a complete re-write from scratch.

I started with site architecture research.  I wanted an HTML5 site that used CSS3 and supported mobile devices.  Mobile device support is important.  It is no secret that mobile device adoption is soaring.  The typical options for mobile support currently include building:

  • a native application (an application designed specifically for each device type such as iPhone, android, BlackBerry, Windows Phone, etc.)
  • a website with a Responsive UI design that works well with mobile devices or a site designed specifically for mobile
  • a hybrid - a site built mostly with HTML5 and javascript that is then wrapped inside a native application using a tool like PhoneGap to create the wrapper

My simple site did not warrant a native application, nor a hybrid solution.  I did not want to create a separate site or design to support mobile devices, so I opted for a Responsive UI design that "adjusts" itself as the screen size changes, to provide an optimized view of the site content at different resolutions.  To implement this, I reviewed HTML5Boilerplate and Twitter Bootstrap, eventually choosing the latter.  Both are very good based on my testing so far and are an excellent way to get started with a responsive layout using HTML5 and CSS3.  Bootstrap includes Glyphicons which are cool, but I switched to FontAwesome, which uses a custom font instead of images.  Using a font is cool because changing the icon size and color is as simple as changing font size and color using standard CSS.  No photoshop required to get a blue version of a white icon.

I am not a web designer, my strength lies more with software architecture, so the new look and feel was developed with help from some Bootstrap themes and my desire to move towards a clean, simple site that focused on functionality and readability. In some respects, moving toward a Microsoft Modern UI (formerly Metro) style look, but without going all the way there.

I implemented the site with ASP.NET MVC3. I used a Legacy Route Handler to accomplish the redirection of old links to the new extension-less URLs in a way that provides a proper 301 Moved Permanently response to help search engines update their indexes.

Support for canonical URLs was implemented using the IIS7 URL Rewrite 2.0 extension.  It allows the definition of simple rules to manipulate URLs.  In my case, it was used so that multiple domains (like troyfarrell.ca) get redirected to my primary .com domain.  This is also important for search engines, to avoid duplicate indexing of the same content.

So that sums up what was important to me, when considering a site redesign this time around.  What do you think?  What did I forget?

3. August 2008 01:55
by Troy
1 Comments

Maximum file path length - Windows and TFS

3. August 2008 01:55 by Troy | 1 Comments

260 Characters.  This seems like alot, and it is, however...

I ran into this issue a while back with an existing project I worked on and it was a royal pain.  When attempting to follow the naming conventions adopted for the folders and projects within a Visual Studio solution, the newly added filename + path exceeded this hardcoded limit within windows (many core Windows APIs still have this hardcoded limit, and many of the more recent APIs, including the .NET framework still depend upon many of these core APIs).  This issue became apparent when trying to check the file into Visual SourceSafe, when an error was thrown.

Now having moved on to a new project, and new technology (Team Foundation Server), I somehow thought that the issue would magically disappear.  Not so.

While 260 characters seems like alot, it is quite possible to hit this limit when you:

  • use nice descriptive names for folders within projects instead of more cryptic abbreviations
  • root your TFS workspace in a subfolder, that will ultimately add unnecessary characters to the total path (D:\work  vs. D:\CompanyName\ProjectName\Source) 
  • use a VS.NET database project, which has its own built in folder structure (Schema Objects\Tables\Keys\) and file naming conventions, which if you have descriptive table names, means the file name of a foreign key constraint SQL file could be really long, just over 100 characters alone for the filename itself without the path in a recent database that I reverse engineered

There is no real fix for this that I have found, except using a shorter path.  Being aware of this limitation when setting up the naming conventions on a new project can save alot of hassle later on, and could avoid having to rename the existing files/paths or changing your naming conventions part way through a project to accommodate this limitation.

References:
http://www.shifd.net/post/2008/02/Maximum-file-path-length-in-TFS-Team-Build.aspx
http://blogs.msdn.com/aaronhallberg/archive/2007/06/20/team-build-and-260-character-paths.aspx
http://neovolve.com/archive/2006/11/09/So-you-still-can_2700_t-have-a-path-more-than-260-characters_3F003F003F00_.aspx
http://blogs.msdn.com/saraford/archive/2005/12/15/504240.aspx

Edit:  I've posted Part 2 on this topic here.