 I’m really excited about ubiquity: http://labs.mozilla.com/2008/08/introducing-ubiquity/ is definitely worth a few minutes if you care about where the web is going.
I loved Aza Raskin’s Enso launcher and wrote a few commands for Enso 2 prototype but it was too buggy to use. I envy mac users because they have quicksilver. But now Aza, being the head of user experience in Mozilla Labs, has found a perfect place to push his ideas forward: firefox, the best cross-platform browser.
A little known fact is that Sitecore 6 comes with Prototype and Firebug lite preinstalled. Prototype is a mind saving javascript library, and firebug lite is a helpful javascript instrumentation console replacing dozens of alert(“I’m here”) calls. We’d do it for ourselves anyway, but what does it mean for you? Prototype Prototype javascript library is automatically included in Sitecore shell applications – both native, such as Content Editor, and the custom ones. This means you can safely use prototype both in your Sitecore customizations, such as custom fields, and in your own applications. (If you look closely enough, you’ll see that custom FieldTypes I’ve made for Crestone shamelessly use prototype whenever possible). Needless to say that prototype is great and saves a lot of brain cells if you do any javascript at all. Some great alternatives, such as jQuery, do exist – but if you don’t use anything at all, I really wonder why. If you’re new to prototype and javascript frameworks in general – they have very solid documentation at http://prototypejs.org/. Even more, prototype’s cousin – Scriptaculous, a javascript UI controls and effects library is also shipped with Sitecore, but is not included automatically. If you need it, it’s at /sitecore/shell/Controls/Lib/Scriptaculous. Firebug Lite Firebug lite is a cross browser javascript console – the fact that it works in Internet Explorer is of biggest interest to Sitecore developers. I’ve praised it before, but now it’s one key press away in Sitecore shell applications. Press F12 and the firebug lite console will pop up from the top: 
This means you can use console.log and other instrumentation methods to debug your javascript. Sitecore UI has a lot of IFrames, so pay attention where you click before opening the console – each IFrame is a separate javascript realm, and therefore has its own firebug console. The Website is Safe I’d like to stress again that both Prototype and Firebug lite are only included in the Sitecore shell applications. Technically, if the sitecore.js javascript file is loaded, the prototype and firebug are also inlcuded. We don’t add anything to the frontend sites – it’s your decision.
I like drawing when designing user interfaces, but my drawings don't usually end up as famous (nor as pretty) as these did: see The Paper Web, UI design sketches of flickr, twitter, vimeo, youtube and others.
“Haml is a markup language that‘s used to cleanly and simply describe the XHTML of any web document, without the use of inline code. Haml functions as a replacement for inline page templating systems such as PHP, ERB, and ASP. However, Haml avoids the need for explicitly coding XHTML into the template, because it is actually an abstract description of the XHTML, with some code to generate dynamic content.” Basically Haml is a domain specific language for XHTML. Unlike Velocity, which can be used to output any text data, Haml focuses entirely on xhtml output — and does it well. Instead of:
<h2><%= ViewData.CategoryName %></h2>
<ul>
<% foreach (var product in ViewData.Products) { %>
<li>
<%= product.ProductName %>
<div class="editlink">
(<%= Html.ActionLink("Edit", new { Action="Edit", ID=product.ProductID })%>>
</div>
<% } %>
</li></ul>
<%= Html.ActionLink("Add New Product", new { Action="New" }) %>
You can do this:%h2= ViewData.CategoryName
%ul
- foreach (var product in ViewData.Products)
%li
= product.ProductName
.editlink
= Html.ActionLink("Edit", new { Action="Edit", ID=product.ProductID })
= Html.ActionLink("Add New Product", new { Action="New" })
(It does look like python, doesn't it?)
Do we need it?
Andrew Peters has created a NHaml, .NET port of Haml made as an alternative view engine for ASP.NET MVC.
I assume it wouldn't be too hard to take it apart and create a Haml rendering type for Sitecore as a downloadable extension. Is this something you find interesting? I love its clarity and wrist-friendliness, and it should be much easier to type online using Developer Center or even Content Editor.
The downside is that you'd lose intellisense in visual studio, but personally I'm much more annoyed by visual studio trying to format my <% %> code the way it thinks i like it. And yes, it's yet another templating engine.
* Haml reference
HTML5 first Working Draft is up, and its incredibly pragmatic, as in taking stuff that everyone does using javascript libraries and browser plugins, and pushing it into the standard. More semantics: nav, header, footer, section, dialog tags and more.
Less presentation: getting rid of legacy elements like font, big, center and other tags. Use the CSS! Framesets are gone too.
Cool stuff you always wanted to be there: <input type="email" autofocus="true" />, support for audio/video and canvas drawing, drag and drop. For shorter reading, HTML 5 differences from HTML 4. Now all we have to do is wait till IE9* becomes the oldest browser around. That'll be soon, right? Lets stay hopeful. * unless it takes years to get to further working drafts and recommendation. Or Microsoft decides HTML5 is against its interests. Or..
If you haven't already, check out the new .Mac Web Gallery for some interesting use of javascript. Here is a sample gallery - once it finished loading you can hover over the albums to quickly scan whats inside. 
Grid, Mosaic, Carousel and Slideshow modes are available for viewing individual albums. Mosaic looks great on wide screen displays, and makes perfect sense since most of the new Macs have one of those. Reducing clutter also helps - no ads, comments, ratings, tags and "related photos" of people you don't care about. 
It's also about using the effective use of available space. Compare with Flickr album view of same screen size and resolution and see how much space the later wastes by using the fixed width layout optimized to work on most screen sizes. Dot Mac gallery, on the other hand, uses a smart javascript driven fluid layout - when browser window is resized main image is scaled in steps, preserving the aspect ratio. 
.Mac gallery is not yet bug free, certainly feels heavy while it loads and with all javascript goodness I don't understand why it doesn't preload next image in individual / slideshow modes. However it is definitely more inspiring than yet-another-ajax-grid. I'm sure it gets dissected on patterns and controls soon enough. via Ajaxian.
Just in case anyone else is wondering how to play with first bits of IronRuby and DLR, here's from John Lam himself: Q: I am wondering if at all, i can see few working examples just like IronPython in asp.net futures section.
A: We're still quite a ways from ASP.NET. There are a lot of implementation details to sort out, particularly around how we deal with isolating concurrently executing pages from each other.
 Added web 2.0'ish license agreement popups on SDN5: try any paid product download, like the Sitecore itself (SDN and download access required). It's not intended to hide actual download location, and in fact is unobtrusive.
Done with modalbox, which worked out well. The only issue we've spotted so far is that the page is moving underneath the modal overlay because scrollbar disapears in IE. Let me know if you see anything else. [A classic "look what I've done post"]
If you're lucky to have IIS6 serving your site, turning on the HTTP compression is a really easy way to decrease page loading times and cut bandwith. With compression enabled, web server can zip static and dynamic content before sending it over the wire. For this to happen the receiving side has to support compression too, as do all modern browsers. There are two types of compression: static is essentially free. IIS will compress files on first request and store them on disk for future use, for minimal performance overhead. This works best for javascript and stylesheets. Dynamic compression allows .aspx output compressing; it's done on the fly and does add some CPU load. If processor isn't your bottleneck, enabling it is still a good idea. For both types you need to define which file types should be compressed because the defaults are really lame: no css and no javascript. On the new www.sitecore.net I've started with total frontpage load being 260kb and combining both compression types decreased it to 142kb. My favorite part is that prototype and scriptaculous (effects module only) javascript frameworks are 27kb total - at this point I refuse to take "prototype is too big" argument into consideration. Useful links:
 Less than a year from the last update, we've flipped the switch on the new public website this weekend. I hope you like it and find it better than the old one.
While it's not a total overhaul, I think it ended up being a major change. What I like about it is increased friendliness - more whitespace, text is easier to read and navigation is improved. Some technical facts: the site is running on Sitecore 5.3.1 rev.070515 in a live mode. We use a simple two step "editing - published" workflow instead of publishing to control item visibility. Your comments and criticism are very welcome, especially since I'm lucky to have people much more experienced in building websites reading this blog.
On having layout is a mind saving in-depth article discussing internals of Internet Explorer rendering engine, why and how do the hacks work and so on. I've just fixed a really weird Internet Explorer 7 bug (absolutely positoned element randomly jumping inside relatively positioned one) - it was unstable enough to hide until the finishing stages of the site development. Here's what saved my day: As a rule of thumb, never position an element relatively without setting layout. [..] When possible, try to stick to cases where the containing block has layout and it is the parent of the a.p. [absolutely positioned] element (i.e. there aren't other ancestors in between the a.p. and the containing block). So its Holly hack to the rescue again. And no, it didn't become obsolete with IE7.
I cannot stop being amazed at the number and weirdness of problems fixed in Internet Explorer 6 by the infamous Holly Hack. I think I need to make a t-shirt, just out of honest appreciation:  
 Our google analytics account has been upgraded to a newer version, as any data junkie I'm wondering around looking here and there. I must say it looks nice, has all the fancy sparklines, etc.
Some stats on browser usage (last week): Internet Explorer: 70%
Firefox: 24%
Safari: 2.5% Internet explorer versions: IE 7.0: 57%
IE 6.0: 42%
|