Blummy: Major Update

I’m proud to announce a major update of Blummy.

Blummy now includes blummyWiki, a small notebook-wiki that can be displayed within the current page. So you could store favorite URLs or commonly used information there which will be available on any page just like Blummy. And of course it’s crossbrowser and crosscomputer.

In my opinion this is a very unique and useful feature.

There is now also custom color and css support. You can browse other users’ Blummys via the “Explore” link in the menu.
Furthermore Blummy is now secured by password at last (so private blummlets are quite secure now).

A few words on the blummyWiki: It is invoked by switching an option on the Prefs page or by using one of these blummlets: open on the left, open below and open on the right. (display all three blummlets in configuration view).

blummy, major, update

Announcing Wizlite: Collaborative Page Highlighting

So I’m not the first to write about my project? Well. Nice ;)

Wizlite takes the good old highlighting marker from paper to web. People get different colors and mark important sections on any homepage.

Users can create groups and wizlite away on a certain topic (either private or public).

You’d have to use it to experience how fun it is ;) So: http://wizlite.com/

wizlite, collaborative, highlight, groups

Speed up your page, but how?

Today I ran accross the blog entry by Marcelo Calbucci, called "Web Developers: Speed up your pages!".

It’s a typical example of good idea, bad execution. Most of the points he mentions are really bad practice.

He suggests reducing traffic (and therefore loading time) by removing whitespace from the source code, to write all code in lower case (for better compression?!?), reduce code by writing invalid xhtml, and to keep javascript function names and variables short. This is nit-picking. And results in a maintenance nightmare.

For big sites, e.g. Google, the white space reduction tricks make sense. But they have enourmous numbers of page impressions. Saving 200 bytes tops by stripping whitespace is nearly worthless for smaller sites. And not worth the trouble. Additionally I bet that Google does not maintain that page as such, but has created some kind of conversion script.

Other thoughts are quite nice but commonplace. Most of the comments (e.g. by Sarah) posted at that article reflect my opinion quite well and deal with each point in more detail.

For most dynamic pages the bottleneck for responding to a client request is the script loading (or running) time. I suggest the writer to read some articles about server caching (my thesis also deals with that topic) and optimization.

Often also the latency between client and server can be held responsible for considerable delays. As the client has to parse the HTML file to decide what files to load next, delays can sum up.

All in all, it’s a good idea to deal with the loading time of a page. But you have to search at the right place.

web, speed, xhtml, script, caching