Disable caching in Chrome

So, you're working on a web app and you can't figure out why the CSS/JS the browser is pulling back is stale. 15 minutes later you realise that it's the pesky browser caching the data - again!

...Here's a nice little settings tweak for Chrome. Disable Cache invalidates the disk cache, which is great for developing but only works if devtools is open.

Do more with less

Should I be supporting those pesky users without JavaScript enabled?

In the past, I've personally been an strong believer that progressively enhancing your web site was the best approach for handling users with JavaScript (JS) disabled. This way, users without the luxury of JS (for whatever reason) get the basic functionality; whilst the other ~99% have their JS enabled browsers 'enhancing' their experience.

Recently however, I've been wrestling as to whether this is the correct approach, it isn't easy and can be costly in development time and effort. Am I just being old fashioned by sticking with the progressive enhancement approach? Possibly.

What should you be considering when deciding whether to support users without JS? I think there's two important questions/areas to cover...

• What's the volume of users hitting your site and what are the percentage of your users that don't have a JS enabled browser?
• If you don't have this data, it's simple to get by placing images loaded in different ways on your most popular page and reviewing your web server logs (using something like log parser) to compare: 
• An image (a blank gif) loaded using a standard img tag in the body of the HTML page
• An image loaded using JS
• Think about it, 1% is a big number if you've got 1 million users hitting your site every month!
• Should your site need JS to function properly? 
• Don't complicate your web apps unnecessarily by throwing JS in as a requirement. Progressive enhancement works great in a lot of scenarios!
• Does your ecommerce web app, really need JS enabled before someone can give you their money? Probably Not. Does your interactive messaging web app really need JS enabled to work properly? If you want to give your users a rich and interactive experience, yes.

You can always serve two different versions of your applications, this is what GMail does:

So I suppose I'm giving you the consultants answer of "It depends!". But it really does, it's not just black and white.

One more thing. If you do decide not to 'properly' support users without JS, you should let them know, rather than them just leaving them with a bad taste in their mouth over your "broken" web site.

Useful Links

• A nice article from AListApart that's explains Progressive Enhancement 
• "How many people are missing out on JavaScript enhancement?" by the Government Digital Services Agency 

Html Encoding in ASP.Net MVC (and avoiding XSS)

Stop using <%= %> syntax in your ASP.Net sites...

Cross-site script injection (XSS) attacks are the most common security issues associated with web applications. Guarding against cross-site scripting attacks is relatively easy; just make sure that rendered output is HTML encoded within a page. This helps ensures that any content that might have been input/modified by an end-user cannot be output back onto a page containing <script> elements.

Ways of encoding with ASP.Net

ASP.Net applications (especially those using ASP.Net MVC) often rely on using <%= %> code-nugget expressions to render output. You can use the Server.HtmlEncode() or HttpUtility.Encode() helper methods within these expressions to HTML encode the output before it is rendered; this however can be verbose and easily forgotten!
A more convenient way was introduced in ASP.Net 4 (MVC 2), and that's the <%: %> syntax, this takes care of the encoding for you. If you're using the Razor engine introduced in ASP.Net MVC 3 then this also takes care of the encoding for you.

<div id="old">
<%= HtmlUtility.Encode(Model.Message) %>
</div>

<div id="new">
<%: Model.Message %>
</div>

<div id="newRazor">
<%: Model.Message %>
</div>

Avoiding double encoding

While HTML encoding content is often a good best practice, there are times when the content you are outputting is meant to be HTML or is already encoded – in which case you don’t want to HTML encode it again. The smart guys on the ASP.Net team decided to introduce a new IHtmlString interface (along with a concrete implementation: HtmlString) that you can implement on types to indicate that its value is already properly encoded (or otherwise examined) for displaying as HTML, and that therefore the value should not be HTML-encoded again. The <%: %> and Razor syntax checks for the presence of the IHtmlString interface and will not HTML encode the output of the code expression if its value implements this interface. 

For example, with ASP.Net MVC 2: the Html.TextBox() helper method returns markup like <input type="text" />. With ASP.Net MVC 2 these helper methods now by default return HtmlString types – which indicates that the returned string content is safe for rendering and should not be encoded by <%: %> syntax. This allows you to use these methods within both <%= %> syntax blocks, within <%: %> syntax blocks and within Razor engine syntax blocks. In both cases above the HTML content returned from the helper method will be rendered to the client as HTML – the <%: %> and Razor engine syntax will avoid double-encoding it.

Always use the <%: %&gt or Razor engine syntax to encode your HTML output; there's no reason to use the <%= %> syntax anymore!

What browsers does your app support?

To focus on supporting modern browsers, we are deprecating official compatibility of Google Analytics with Microsoft Internet Explorer 8 (IE8) at the end of 2013.

Above is a snippet from the latest blog post on the Google Analytics blog. The Analytics team have made the bold(ish) step of announcing the end of the line for IE 8 support in the next 3 months. It doesn't seem all that long ago when they announced they were dropping support IE 7 (and Firefox 3.5/Safari 3); but that was back in June 2011! Don't forget that they dropped proper support for IE 8 in a range of Google Apps like Gmail and Calendar last year, those users get basic HTML offerings with many features removed or read-only type views of the apps.

I'd love to see the analytics browser usage data for Google Analytics to see how many of their customer's are going to be affected!

I'm going to use this news as motivation to drop our legacy IE support (we still support even older browsers than IE 8 :/) - I'll let you know how it goes.

Git branching tutorial

Working with branches in git is easy. That's not saying there's some powerful, more advanced commands for complicated branching scenarios. This git branching tutorial demonstrates the basics and those advanced commands you may not even be aware of - worth a play if you've got 30 mins spare.

OWASP web application security cheat sheets

The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific web application security topics. These cheat sheets were created by multiple application security experts and provide excellent security guidance in an easy to read format.

https://www.owasp.org/index.php/Cheat_Sheets

Nice CSS layouts tutorial...

Tutorial that demonstrates CSS fundamentals to novices well (also useful for veterans looking for a friendly refresher).

http://learnlayout.com/

Disable or hide UI components?

When rendering the UI for a user, if a user doesn't have access to certain options, should the UI components be disabled or hidden?

I've been pondering this question all day and my particular use-case relates to navigation in an app. After lots of thinking, some discussions and some googling for UI wisdom, I've come to a fairly definitive conclusion. Users should have visibility on all components/options as long as the user can potentially use them. What I mean here, is that if the components require certain conditions to be met before the user can use them then they should still be present. If for the current user the components can never be used - they should be hidden. An inconsistent UI should be avoided and an inconsistent UI where components come and go will only confuse users more. A good analogy suggested by someone on a similar topic:

When the light bulb burns out, the light switch is still there. In the physical world, things don't disappear in thin air when they switch to a unusable condition.

Obviously there's probably exceptions to this rule, but I imagine this will hold true for most use-cases of this nature.