I recently wrote a post about the ASP.NET Razor rendering engine. The post wasn’t that significant, but what was significant was that I did it from my phone while on the subway and then at physical therapy.
Creating content has become extremely easy on the modern web. Whether it’s through a platform like Twitter, YouTube or Facebook, or through a self-hosted or created package. Either way, the creation of content is easy. And it needs to be. It’s one key to providing value with your site.
Any given site, in order to provide value, needs to either provide content or provide functionality. Often, the difference between these two can be blurred – while Gmail’s functionality is clearly impressive, it’s ultimately a method of providing content. The same goes for Facebook and other sites with a lot of functionality.
Thus, there is a lot of content flying around, from individual, small sites to massive, cutting-edge applications.
This is what the modern web has become – an egalitarian medium where anyone can add content quickly and easily. While the creation if good content itself can be hard and time consuming, the addition of that content is fast and easy.
This does create a lot of unnecessary and superfluous noise (check out some Twitter hahstags to see what I mean), ultimately, it’s a good thing as it gives everyone the chance to be heard. Not a guarantee, but a chance.
PS – I wrote this post in the same physical therapy session. 
April 28, 2011
I recently starting working on a project that uses the Razor rendering engine. While I had read about it and seen it before, I hadn’t actually used it full-time until this project.
My first real take-away is that it is simply a brilliant enhancement to embedding display code into your views. With the markup being clearly distinguishable from both HTML and JavaScript, the code is far more readable.
The traditional web forms bracket-style notation, originally inherited from classic ASP and in-line with the de facto standard of the day when embedding server-side code into HTML certainly served its purpose, but it quickly becomes apparent that it doesn’t produce the most readable code.
See Razor:
<a href="@Url.Action("Index", "Home")">
<img src="@Url.Content("~/Content/Images/logo.png")" alt=
"Logo" />
</a>
Versus Web Forms:
<a href='<%= Url.Action("Index", "Home") %>'>
<img src=
'<%= Url.Content("~/Content/Images/logo.png") %>'
alt="Logo" />
</a>
Thus, the Razor engine solves this problem and makes the front-end code easy to read and distinguish between HTML, JavaScript and server-side, embedded code.
April 25, 2011
A recent post by Tim Peter about designing for a certain browser got me thinking about design and usability and the current state of the browser wars.
Tim argues that instead of looking at what the general market trends in browser usage is, you should look at what the usage of your users are. I completely agree with that sentiment.
Given the current state of modern browsers, however, there is very little reason that your website design and development can’t support the majority of browsers. There might be slight display issues in some cases, but the big hitters: IE7/IE8/IE9, Chrome, Firefox and Safari, are all relatively easy to support. Of course, there are occasional bugs here and there (I’m looking at you IE7) that require special attention (and often additional hair-pulling), there is little reason beyond working with some intense JavaScript or cutting-edge CSS3/HTML5 features that your website will not work in the above browsers.
Once that’s accomplished, it becomes a business decision how far you want to go to support less common situations or exotic browsers or antiquated browsers (hey, IE6). Just like how how much A/B testing you do becomes a business decision, how much cross-browser compatibility your company is going to pursue is also a business decision.
April 4, 2011
