I ve finished updating the mock-up for the recipe stash home page and converted it into a web page. There is a screen grab of the page below, unfortunately you can t poke around the HTML and CSS but believe me it is all there! In this post I m going to outline the decisions I ve taken for the visual design of the page. The next post will go into the considerations I ve taken to ensure the site will be standards compliant and work across all the major browsers. If that sounds a bit dry don t worry I ll be adding in some cheesy headings for your entertainment.

From Baking Websites

Top to tail

The most immediate visual change you will probably notice, compared to the original mock-ups, is the header and footer background colour. This was a handy hint from the senior designer at Cubeworks, so thanks Jesse! I much prefer how this breaks up the page and gives a clear separation between the main content and the rest of the page.

Press my buttons

I put a bit of time into making a big shiny Search button to use in the header. I found it surprisingly tricky to choose a button that draws attention to the user but doesn t stick out horribly from the rest of the design. I m not entirely happy with the selection but I think its good enough for now. Another button image can easily be dropped in latter if I feel the need.    

Tabs for Navs

Another major change in the design (and another top tip from Jesse) is a move away from the vertical icon based navigation menu in favour of a horizontal tabbed menu. This is a more conventional means of user navigation and will probably be easier for them to understand. I m happy with how the visuals have turned out on the tabbed menu, keeping colours in line with the rest of the site and curved corners for a more current feel.

Heading Home

I ve retained the icons that were originally used on the navigation. They are now displayed to the left hand side of the main h1 page heading. These icons are one of the few graphical elements on the site so I m pleased that there is still a place for them here. I think they provide an immediate prompt to the user as to which section they are in, complimenting the nav menu highlighting and h1 heading text itself.

Colour me red

Although not really shown in the image above, the plan is to still use a different colour for each of the main sections, which will be most evident in the main navigation and heading colours. This point will be one to revisit once I ve completed the other section pages.

<

p>That just about wraps up the main visual changes for the home page.  In the next post I ll be taking a look behind the scenes at the technical decisions I ve made to generate the page.

The recipestash website is flush with a shiny new domain name, however it was sadly lacking in any kind of visual design. Up to now I ve been working with a generic style sheet downloaded from free CSS templates however I think it is poorly suited to the site. So I ve put some time into making some mock-ups in Photoshop.

I ve identified the site homepage, main search page and Add a recipe pages as the main areas to mock up. The remaining sections can be investigated later. The design mock-ups for each of the pages are shown below (full size versions can be viewed in the Picasa web album).

Home

From Baking Websites

I ve gone for a minimal design on the homepage, the header will be used across all pages on the site and includes the site name, main search bar and login controls for the current user. The main content on the homepage highlights each of the four sections on the site which will be used most often. I ve chosen a different colour for each of the main sections, hopefully this will give users a visual feel of where they are on the site. The four icons on the left will be displayed on all of the pages and be used as the main means of navigation. I ll be looking to use some jQuery to display the section names when each of the icons is hovered over. If javascript is not available in the browser then a simple navigation menu will be displayed in the header.

Browse recipes

From Baking Websites

The Browse recipes page can be reached from either the navigation menu or the search bar. The main features of the page are:

Search keywords

If the page has been reached from a search the top section displays the keywords which have been searched for. Each of these can be removed from the search by pressing the x icon next to the keyword.

Filters

Each of the filters are a simple checkbox, which will cause the results to display only those matching the filters. I may include an apply filters button for accessibility as performing a postback on the checkbox selection would most likely require some javascript to operate.

List of recipes

The list of recipes will include summary information for each of the recipes, as shown in the mock-up above. The ordering of the recipes can be controlled by clicking on the column headings. I will look to colour one of the headings to indicate which is currently being used to order the results.

More recipes link

Clicking the link will cause more recipes to be loaded to the bottom of the search results.  

Add a recipe

From Baking Websites

The functionality of the Add a recipe page is already largely complete. The above styling will need to be applied to the pages to format the form as displayed above. It may be tricky to apply the styling shown to the text boxes but there are other sites using similar effects so I can probably find some hints for the required CSS techniques from them!

<

p>Next up I will be looking to generate some HTML and CSS to match the mock-ups which can be used in the website views.

With the turn of the year disappearing behind us, I thought it was about time that the site I m developing got a proper identity. Initially I would of liked recipebook.com, but that is far too obvious a name to be left unclaimed, also I think its quite boring and sounds too similar to facebook. So my main criteria for the name were that it should be related to the content, engaging, easy to remember, not too derivative and of course available!

After plugging some names into the lookup tool the two front runners were recipestore.net and recipestash.net. I liked recipestore as it conveys the main idea of the site as a storage place for your recipes. However it can also be interpreted as meaning a shop for recipes, which is not ideal as the recipes will all be freely available on the site. So I settled on recipestash, which I think meets all the criteria and is less derivative than recipestore. In virtual celebration of the new domain here s a picture of a lovely looking muffin (Image shared under creative commons on Flickr by rachellake).

 

<

p>Deciding on the domain also has a fringe benefit of motivating me to get on with the site! Its a bit of a waste not doing anything with the domain so I m going to try and get the site up as soon as possible with the core features. The site can be refined and updated with extra features after the initial release.

I ve been developing the recipe book website mostly using TDD (Test Driven Design) and I thought it would be interesting to measure the code coverage of my unit tests. After researching what tools were available it looked like NCover was the best fit for the sites technology stack. The commercial version has some good features, such as measures for cyclomatic complexity, however it is a bit out of my budget (of approximately 0!). Fortunately a community edition of NCover is also available for free and it stills works just fine for analysing current .NET assemblies.

After installing NCover a console application is available for running code coverage analysis. I got this up and running but the command line interface isn t exactly the most user friendly and the output is just a single summary report. I obviously wasn t alone in these conclusions because back in 2006 Grant Drake developed the NCoverExplorer tool to provide a GUI front end to NCover. This tool also has a community edition available (version 1.4) that works with the community edition of NCover.

Starters - Setting up NCover Explorer

The tool is fairly straight forward to setup, the NCover website includes instructions on how to setup the professional edition to profile an NUnit test project, and the settings are equivalent in the community edition. I also chose to specify which assemblies should be included in the coverage report as otherwise all the Sharp Architecture assemblies are included and the results are skewed.

After running the tool you are provided with an interactive view of the assemblies with the uncovered lines displayed in red. You can see how easy it is to identify the offending lines in the screen grab below:

The Main Course Improving code coverage

The results of my first report are shown below:

The prime candidates for improvement were:

• The RecipeBook.Data assembly. A couple of repository classes were not tested.
• The RecipeBook.Web.Controllers assembly. Some of the code paths in the controller methods were not covered.
• The RecipeBook.ApplicationServices assembly. Not tested at all, oops!

By default NCover sets the acceptable coverage level at 95%, however I felt that this was overly strict. I would rather spend the time writing fewer tests that I ensure are of a high quality than writing tests just to cover every single line of code. So I reduced the threshold to 80% and added tests to cover the essential missing features. Below if my much more healthy looking report.

For Desert A report without the red sauce

OK maybe I m stretching the food analogy a little too far with my headings now! By red sauce I mean those nasty red bars that were blazed across nearly every line of the report. Below you can see the report looks much more healthy after adding some unit tests and trimming some unused code:

I will endeavour to keep the coverage level at a minimum of 80% from now, and hopefully add some more tests to bump off those remaining pesky red bars!

As usual, any comments on this post are welcome. :)

I ve been working on a page to add method descriptions for the recipes. The most simple solution for this would be a large text area allowing the user to add multiple lines of text for the recipe method. However I think this would be too limiting for the users and also offer poor formatting when the completed recipes are viewed. A better solution is to use a rich text editor which allows users to entered formatted text and generates HTML to use on the recipe views.

The editor had to allow the users to enter formatted text including paragraphs, text highlighting, numbered and bulleted lists. It was also important that the editor could be limited to prevent users entering content which would break the styling of the site. For example no image tags should be entered in the method as there is already a separate image property for each recipe. Fortunately I ve had experience using the TinyMCE rich text editor from working on N2 CMS based websites at work and this editor meets all of the requirements.

Integrating TinyMCE into the site was pretty straightforward, there is detailed documentation on the TinyMCE wiki, including installation instructions. Adding the editor to the site is simply a case of downloading the assets, including them in the VS project and including a javascript call to load the editor in the page header. By default the call transforms all text areas into TinyMCE editors. I also found the simple mode provided the limited feature set I was looking for. There were just a couple of issues to resolve before the editor could be used.

Disable Input Validation

The editor generates HTML which is posted back to the server when the page is submitted. However by default MVC throws an exception as the postback contains HTML tags:

Exception Details: System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (CookingMethod=”<p>A Test method</p> <u…”).

To prevent this exception from being thrown the page validation must be disabled. This is done by adding the [ValidateInput(false)] attribute to the controllers action method which is called when the page is submitted.

Protect Against Unwanted HTML / XSS

After making this change the editor content posts back to the server and can be saved to the repository. However disabling the input validation leaves the site open to cross site scripting (XSS) attacks so some extra precautions need to be put in place. TinyMCE already checks the content which is posted back, however the wiki points out that the editor can be easily disabled by any user by disabling javascript in the browser. They recommend that some server side checks are put in place to prevent any unwanted tags and scripts from being persisted to the repository. I ve added some code to check the recipe method string and strip all unwanted tags. It uses a regular expression to allow a subset of tags to be saved. Any other tags are replaced by an empty string. I found a good SantizeHTML method posted on stack overflow, so no need to reinvent the wheel here!

Protect Against CSRF

While I was in the area of security I thought I may as well increase the protection of the form to cross site request forgery (CSRF) attacks. Steve Sanderson has already written a full blog post on this subject (among others I m sure) so I won t go into detail on this. Suffice to say I thought it was worth adding as it only takes 5 minutes and provides an extra level of protection which may be needed later.