Another short tip, because I really like the smusher gem!

first install it:
gem install smusher

then crush your images automatically using the PunyPng service, which is currently delivering the best results in terms of file size:
smusher * --service PunyPng

Popularity: 1% [?]

If you need to generate thumbnails of the first pages of alot of PDF documents you can use this tiny ruby script:
http://bit.ly/8T0B1a
I also included smusher support to crush the PNGs after they were created. Just gem install smusher and uncomment the smusher command.

Enjoy!

Popularity: 1% [?]

Wir wollen, dass die Ladezeit von imedo.de so gering wie möglich ist, damit unsere Besucher nicht ewig auf den Aufbau der Seite warten müssen und gefrustet auf den “Zurück”-Button einhämmern.

Welche Bildformate gibt es für Webseiten?

GIF:
verlustfreies Format, bis zu 256 Farben, eine transparente Farbe möglich, unterstützt Animation

Wann verwenden?
Eigentlich nur bei sehr kleinen Grafiken mit wenig Farben oder wenn eine Animation sein muss. Ansonsten sollte man PNG-8 verwenden.

Daumenregel:
Wenn eine Grafik (keine Fotos) kleiner als 20×20 Pixel ist, keine Verläufe hat und mit weniger als 16 Farben auskommt, ist Gif eine gute Wahl. Kleinere Animationen sind ausser mit Flash nur mit Gif möglich. Je weniger Farben, desto kleiner wird die Datei.

PNG-8:
verlustfreies Format, bis zu 256 Farben, unterstützt echte Alphatransparenz, also Übergänge von transparent nach nicht transparent sind in unterschiedlichen Stufen möglich, keine Animationen

Wann verwenden?
Eigentlich genau wie Gif, aber PNG-8 ist zu bevorzugen wenn man gröere Grafiken mit mehr als 16 Farben hat und echte Alphatransparenz verwenden will. Vorsicht ist geboten bei Internet Explorerer und einigen anderen Browsern, weil die Transparenz manchmal falsch interpretiert werden und das Resultat nicht besonders schön aussieht. Ist dies der Fall, sollte man auf Gif ausweichen.

Daumenregel:
Bevorzugtes Format für Grafiken mit bis zu 256 Farben, wenn Transparenz benötigt wird. Fallback auf Gif falls es Probleme gibt. Je weniger Farben, desto kleiner wird die Datei.

JPG/JPEG
verlustreiches Format für Fotos mit sehr starker Kompression, mehr als 256 Farben, keine Transparenz, keine Animationen

Wann verwenden?
Bei Fotos.

Daumenregel:
Alles was keine Grafik ist (z.B. ein Chart mit wenigen Farben) ist ein Kandidat für JPG. Alle Fotos die ihr mit einer Digicam aufnehmt haben normalerweise dieses Format.
Beim abspeichern kann man normalerweise die Qualitätsstufe von 0 – 100 einstellen. Normalerweise sollten 75 reichen, aber wenn es ein Portrait einer Person ist kann man auch mal bis 90 hochgehen.
Umso geringer die Qualität ist, desto kleiner wird die Datei.

Und jetzt? Was nehm ich nun?
Grafiken: PNG-8 oder GIF
Fotos: JPG

Dateigrößen:
PNG-8 und Gif: je weniger Farben, desto kleiner die Dateigröße
JPG: je geringer die Qualität, desto kleiner die Dateigröße

Gibts noch was zu beachten?
Ja! Die Ausmaße der Bilder (Höhe, Breite) die ihr verwendet haben eine enorme Auswirkung auf die Dateigröße. Deswegen Überlegt Euch wie groß das Bild sein soll, bevor ihr es hochladet. Skalierung von Bildern in Browsern verschwendet Bandbreite und sieht unter Umständen (IE *hust*) schrecklich aus.

Und noch was
Die Auflösung im Internet beträgt 72dpi (Dots per Inch, also wieviel Pixel pro Fläche). Alles was darüber hinaus geht ist Verschwendung. Wenn ihr also irgendwo Bilder findet die eine höhere Auflöung haben als 72dpi dann rechnet diese um auf 72dpi.

Popularity: 1% [?]

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% [?]

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% [?]

Quick Tip:

Set a variable called TM_RUBY in Textmate’s “Preferences/Advanced/Shell Variables” menu to the correct path and you can run your script with CMD-R and the correct ruby version.

Popularity: 1% [?]

As requested here is the presentation for our awesome email plugin:

Slides

Popularity: 1% [?]

For the impatient

Check out the demo application:
http://opensource.imedo.de/htmlmail

Install the plugin:
script/plugin install git://github.com/imedo/awesome_email.git

Learn how to use it below.

Introduction

Have you ever tried sending HTML emails to your users? If you did, you know for sure that it sucks big time: none of the usual ActionView helpers want to work, URL routing is disabled, layouts don’t work, and last but not least, the CSS you wrote for your email simply won’t work in any e-mail client except maybe Apple Mail. To solve all of the above problems, the awesome_email plugin comes to the rescue. Just install it into your vendor/plugins folder, and the rest comes by itself.
If you are interested in what works in which Email client check this link: A guide to css support in Email

What does it do?

There are a few interesting components in awesome_email:

• awesome_email adds layout support to emails. That means that you can use templates for e-mails just like you would with normal Rails Views.
• The HTML Mail’s CSS is automatcally inlined. That means that your designer and/or CSS guy can design the email in a web browser without worrying about how it might look like in excotic email clients. Yes, it works in Outlook, too, and no, it doesn’t work in Outlook 2007 without tweaking. The reason is a “stupid decision from Microsoft about Outlook 2007”, but we’re working on that one.
• ConvertEntities replaces Umlauts and other crazy symbols like ä, Ö etc. with their HTML Entitiy counterparts e.g. ä and so on.
• HelperMethods allow you to dump the content of the CSS file right into a style tag inside the header of your HTML mail.

How to use it

In your Mailer.delivery_xxx methods you can use

1
2

layout    "template_filename"
css       "css_filename"

to define which layout should be used and which css file should be used to create inline styles

CSS inlining

The cummulated style of each DOM element will be set as an style attribute when using css inlining.

Example:

your css file:

1
2
3

#some-id { font-size:2em; }
.some-class { color:red; }

your template:

1
2

<p id="some-id" class="some-class">Hello World!</p>

will result in the following code:

1
2

<p id="some-id" class="some-class" style="color:red; font-size:2em;">Hello World!</p>

Important!

Be sure to follow these simple conventions or otherwise awesome_emails’s magic will fail:

• The layout must be located inside app/views/layouts/{mailer_name}
• If you send mutlipart mails, check out the conventions on how to name your files: http://rails.rubyonrails.com/classes/ActionMailer/Base.html
  • So if you have these files inside of /app/views/{mailer_name}: signup_notification.text.plain.erb, signup_notification.text.html.erb ActionMailer will send a multipart mail with two parts: text/plain and text/html
• Your CSS file must be inside of /public/stylesheets

Dependencies

gems: rails 2.0.2, hpricot, csspool

Getting it, License and Patches

Get the complete source code through http://github.com/imedo/awesome_email. License is MIT. That means that you can do whatever you want with the software, as long as the copyright statement stays intact. Please be a kind open source citizen, and give back your patches and extensions. Just fork the code on Github, and after you’re done, send us a pull request. Thanks for your help!

ToDo

• More test coverage (as usual)
• make it more flexible with view paths
• rails 2.1 compatibility

Popularity: 100% [?]

If you ever wrote something similar like this (or more complex constructs):

<%= @jadda.name rescue @jadda.nickname rescue 'unknown' %>

and then wished you had a construct like try(*these) in prototype? Surrender not, for there’s light at the end of the tunnel!

I present you try these which I found on Chu Yeow’s Blog today.

Here’s the mixins code:

1
2
3
4
5
6
7
8

module Kernel
  def try(*these)
    raise ArgumentError, 'try requires at least 2 arguments' if these.size <= 1
    fallback = these.pop unless these.last.respond_to?(:call)
    these.each { |candidate| begin return candidate.call rescue next end }
    fallback || raise(RuntimeError, 'None of the given procs succeeded')
  end
end

That’s all. Use it like this:

<%= try(lambda{ @jadda.name }, lambda{ @jadda }, lambda{ 'unknown' }) %>

and it will call all these blocks until one will yield no exception or the end of the array is reached. If one yields a result it will end the loop and return the value yielded by that block.

Hope this is useful for someone.

Popularity: 1% [?]

What is this about?

These are excerpts of some very interesting articles I found while researching how simplicity is used in order to improve webdesign and user experience. I added the links to most articles so you can read them in full length if you like.

Another great resource about simplicty in both design and business: Getting Real

Quotes:

Leonardo Da Vinci: “simplicity is the ultimate sophistication.”

Milton Glaser: “less isn’t more; just enough is more.”

The complexity of simplicity:

http://uxmatters.com/MT/archives/000151.php

• reduction of lines, colors, shapes, plenty of whitespace => perceived as easy to use, even if it may not be the case
• but: simplicity can’t be determined by how few items are on a Web page. Simplicity, like most elements of design, needs to be evaluated in context

• simplicity engages users to try a service, perception of complexity turns users away (“this looks cluttered; therefore, it must be difficult to use”)
• contributing users under 10% on websites (youtube 0.5%, wikipedia 1.8% produce 70% of articles, top 100 digg users submit 56% of stories)

Yahoo! Groups – content production pyramid:
http://www.elatable.com/blog/?p=5

• 1% of the user population might start a group (or a thread within a group)
• 10% of the user population might participate actively, and actually author content whether starting a thread or responding to a thread-in-progress
• 100% of the user population benefits from the activities of the above groups (lurkers)
• social software sites don’t require 100% active participation to generate great value
• top users (power participants) most vocal about their needs, they need more powerful tools than lurkers
• edward tufte: measures simplicity by information density (= how much screen real estate is devoted to useful information)
• simplififying may penalize power users, if the needed tools are out of sight
• track different types of users, their states and transitions => map this to presentation of feature sets
• present more functionality if they tell you that they are ready for it
• showing all features available without context makes a product complex
• IDEA: “advanced”-links with dropdown (mouseover) which reveals expert options available in this context
• muting the expert actions will allow faster completion of the most frequent actions by both experts and novices
• power participants drive revenue, desired behavior must be encouraged by exposing the features that create value for the site
• hiding of functionalty discourages users to adopt desired behavior (content creation)
• most users don’t use customized toolbars etc, so smart defaults are important

John Maeda’s laws of simplicity:

http://lawsofsimplicity.com/category/laws?order=ASC

Reduce:

• “The simplest way to achieve simplicity is through thoughtful reduction.” When in doubt remove it
• how simple can you make it? <-> how complex does it have to be?
• balance between simplicity and complexity is important -> finding it can be truly complex

Organize:

• “Organization makes a system of many appear fewer.”

Time:

• “Savings in time feel like simplicity.”
• waiting is frustrating
• users want to find the quickest/simplest way to get a task done, everything else gets in their way and adds to their frustration
• When forced to wait, life seems unnecessarily complex.

Learn:

• “Knowledge makes everything simpler.”
• people don’t care for instructions, they will just try if it looks simple enough
• if they fail they will read instructions eventually so they should be within the users reach when needed

Differences:

• “Simplicity and complexity need each other.”
• without complexity we could not recognize simplicity when we see it
• in a complex world a simple product stands out, it becomes remarkable (worthy to make a remark about, like a purple cow)

Other laws:

• Context: “What lies in the periphery of simplicity is de?nitely not peripheral.”
• Emotion: “More emotions are better than less.”
• Trust: “In simplicity we trust.”
• Failure: “Some things can never be made simple.”
• The One: “Simplicity is about subtracting the obvious, and adding the meaningful.”

Other Articles:

http://www.guuui.com/browse.php?cid=225

• Users love link-rich home pages, The secret is clustering: “Users look at each cluster and quickly decide whether the cluster is likely to contain their content or not. By focusing on just one or two clusters, the user winnows down their choices to just a handful of links.” -> Page Hierarchy
• contrast is google’s search homepage

http://www.uie.com/articles/simplicity/

• people judge the quality of a product based on the number of features, if they have never used it before.
• After having used these products however, usability will start to matter more than features.
• many consumers, when faced with a purchase decision, choose complexity because they try to predict they potential future needs
• users want to avoid trade-offs, help them to make the right decision by understanding what they need -> user centric design
• also communicate simplicity, make it your story, tell users that they will find what they need and that all is simple to use

http://informationarchitects.jp/100E2R/

5 Statements

• Don’t tell us to adjust the font size
• Don’t tell us busy pages look better
• Don’t tell us scrolling is bad
• Don’t tell us text is not important
• Don’t tell us to get glasses

Five Simple Rules

1. Standard font size for long texts
2. Active white space
3. Reader friendly line height
4. Clear color contrast
5. No text in images

The beauty of simplicity:

http://www.fastcompany.com/magazine/100/beauty-of-simplicity.html

Google

• Marissa Mayer: “Google has the functionality of a really complicated Swiss Army knife, but the home page is our way of approaching it closed. It’s simple, it’s elegant, you can slip it in your pocket, but it’s got the great doodad when you need it. A lot of our competitors are like a Swiss Army knife open—and that can be intimidating and occasionally harmful.”

Philips

• philips transformed into the simple company
• consumer centric design, they listen to what consumers want
• advanced technology simple to use
• it’s not just a marketing term, it’s also lived on management level: 500 -> 70 businesses, 30 divisions -> 5
• meetings: max 10 slides per powerpoint allowed
• Sales growth for the first half of 2005 was up 35% in north america
• Supplier of the Year by Best Buy and Sam’s Club, 12 Innovation Awards

Quicken

• microbusinesses (9 million potential customers)
• small businesses afraid of accounting software, terminologie
• they blew the first try, then got it right after the 3rd interface iteration
• changed terminology to simple terms like “money in” and “money out”
• simplified setup and feature set to bare minimum (just enough) => 125 setup screens -> 3, 20 major tasks -> 6 essentials
• 100,000 units sold in its first year on the market

Simplicity/usability pitfalls

http://www.guuui.com/issues/04_03.php

“The human brain can’t process more than 7 +/- 2 items at a time”

• study to measured short term memory, not what people can perceive visually at a time
• Humans can only retain 7 +/- 2 items in the immediate memory, but have no problem in dealing with great amounts of information in the field of vision
• dangerous assumption when applied to navigation\!
• Reducing the number of menu items will make the site hierarchy deeper and thereby increase structural complexity
• users find information faster in broader navigations than in deeper ones

Download time

• strong correlation between perceived download time and how fast users can accomplish their tasks
• help users to find the information faster

“Users don’t like to scroll”

• study from 1996 (10% of users scroll beyond fold)
• not true anymore, strong clues that page contains desired information -> user will scroll to find it
• too much “breaking up” of content is frustrating
• hiding information on other pages increases structural complexity

Striking the balance

• difference between what people say and what they do
• rely on users behaviour, not on what they tell you

Popularity: 1% [?]