Archive for the ‘railsconfeu’ tag
Design for Usability
RailsConf Europe 2008
Session – Design for Usability
presented by Christian Lupp
In his talk at RubyConf Europe 2008 Christian Lupp showed a designers approach to solving problems. It my seem strange to have a designer give a talk in front of a developer crowd, but I think you will find, that we can learn a few things by observing other professions’ methodologies.
He told the audience that many great ideas have evolved on paper. You start out with rough sketches and prototypes. In this stage you basically create a landscape of your application and it should help you to understand what the problems are you want to solve. Once you’ve dont that, you redefine these prototypes iteratetively. Be confident to throw stuff away that isn’t working out and explore alternative solutions. Fail fast and early.
Hmm, this all sounds an aweful lot much like agile software development, doesn’t it?
He also mentioned that you should always take the context into account when constructing your application. Without thinking about the user’s perspective and his needs, may it be a human or a machine, it’s likely that you develop in the wrong direction.
If you have two equal solutions to a problem, take the simple solution. This is called the Occham’s razor Behold! Knowledge from the 14th century folks, but still true. In order to find the simplest solution, you reduce functionality until your application is missing something important, then you go one step back.
Then the talk got technical after all.
Christian asked why we as web developers should use techniques like unobstrusive javascript at all and listed some valid points. First, people using screenreaders will love you. Second, the marketing and SEO guys will love you. You improve the overall performance of your website and thus speed up the overall user experience on your website. Users don’t like to wait. If a page is snappy and responsive, they are more likely to come back.
Christian also shared some basic design tipps with us.
Repeat with DRY. Don’t show different elements on every page. Instead develop an overall graphical and UX concept. It doesn’t only make you site look more professional but will also help users to find their way around on your site. Usability equals recognizable patterns, so repeat yourself and use layout grids etc. that will help your users to understand the content of your site faster.
Another good tipp is to always validate user input immediately by javascript for example. Give your user feedback all the time and instantly, eventough the action he started may take longer. Be creative and entertain you user while he is waiting for search results. Instead of letting the user wait for the search to finish, you can show him an immediary screen which informs him that his search is beeing performed and could take a few moments to finish. You informed your user and in the backgorund your server is already working on finding relevant results for him. This pattern is already used by most forum software.
That was “Design for Usability”, a very interesting talk.
Popularity: 1% [?]
Accessible Ajax on Rails – RailsConf Europe 2008
RailsConf Europe 2008
Tutorial – Accessible Ajax on Rails
presented by Jarkko Laine and Geoffrey Grosenbach
In this tutorial on tuesday Jarkko showed how to use unobstrusive Javascript techniques, in particular LowPro, to seperate javascript logic from content. His example of choice was a simple ToDo list with checkboxes. He started out by using the standard Rails helpers and the refactored the application to use unobstrusive javascript.
If you’ve never heard of unobstrusive Javascript before the first part was very interesting, because here he pointed out that inline scripts not only block the browser, but also clutter your html code with unneccessary output. It bloats your file and is not very DRY. Imagine you use standard Rails helpers in a list of checkboxes to do Ajax calls. The same code over and over again.
The next step was a introduction to LowPro by Dan Webb (Prototype Core Team member), which makes it easy to attach javascript logic to elements on a page by the Event.addBehavior method:
Event.addBehaviour({
'#add_form' : RemoteForm({
onComplete: doSomething here ...
})
});
Here are some tips from Jarkko:
Be careful when using Event.addBehaviour.reassignAfterAjax = true;, because all your behavior code will run again after every Ajax request and potentially mess up your page. Instead apply behaviors inside the onComplete callback of the Ajax call like this: onComplete: function(){ Event.addBehaviour.reload(); }
He also suggested that instead of using too many classes to identify your behavior targets, you could use CSS3 selectors like "input[type=checkbox]" instead. The question here is if this performs better than classes on slow browsers like IE6.
All this ujs sounds pretty interesting, but you should use it wisely. For example if you need to apply a behavior to every cell in a large table. If you attach a behavior object to every single cell, it will not only eat a lot of memory, but will slow down the initialization of the page overall. If you add observers to each of these objects, the site will be sluggish. This is where Event.delegate comes in! Instead of applying the behavior to every single cell, you attach it on the table and let Event-propagation do the work for you.
LowPro comes in handy here, because it has this functionality built in through the Event.delegate method, which you can use like this:
Event.addBehaviour({
'table:click':Event.delegate({
'td':function(e){
var targetElement = e.element();
},
'a':function(e){
e.stop(); // stops the event from bubbling
}
})
});
Make sure you explicitly stop events from bubbling, because otherwise if a link inside a table cell is clicked, both actions will be executed. But there is a caveat to this method: unfortunately not all events bubble up. In particular ‘focus’ and ‘blur’, so be aware of this.
If you need to store state inside your behavior you can also attach custom objects to these elements, like you’ve seen it with RemoteForm in the first example. First you need the class:
var Hover = Behaviour.create(
initialize: function(className){
this.lassName = className || 'over';
},
onmouseover:function(){
// this will be a event handler
}
);
which will contain all your logic and observers.
Then you attach the Hover class to the DOM element like you’ve seen before:
Event.addBehaviour({
'.hover_thing':Hover
});
More on UJS will follow.
Popularity: 1% [?]
