Rating System

I have now integrated a rating system to blummy. You can rate blummlets at the "view code" page and the "Rate" link on the top left.
Furthermore there is the first library function for blummy: Blummy.getSelection(). It will retrieve the selection not only in IE and Firefox but also in Safari. If no selection is given you can add a string as parameter that will serve as question in the prompt box.

, , ,

Bugfixes and Interface improvements

I've released a new revision of blummy with the following changes:

  • [Bugfix] Improved HTTP Headers for Caching (now ETag and Last-Modified).
  • [GUI] Now there is a loading sign for ongoing searches.
  • [GUI] Predefined searches such as Random or Most Popular have been moved to tabs.
  • [GUI, Feature] You can resize a blummlet now by using the shift-key.
  • [GUI] A grid is shown on blummy to make it more obvious that the drag and drop function provides snapping to that grid.
  • [Feature] You can now specify to be logged in automatically on each visit.

The first point may be the most important one. It should improve speed of loading enourmously. Please give me some feedback if it works for you. Also any other feedback such as feature requests or bug reports are welcome.

Improvements

There are some new features I have implemented lately.

  • There is a random blummlet display
  • Search shows how many pages there are all in all.
  • You can also chose presets (empty, anon) so that you can easily start over or start from the anonymous blummy such as on the first page.
  • You can copy an uneditable blummlet to correct an error in another blummlet.

Blummy Feedback Roundup

People seem to like blummy very much :) There have been several blog posts about blummy in English, German, Spanish, Italian, Chinese, Japanese, and Korean (I was astonished that Google Translate — accessible via blummy ;) — was able to translate all these languages to understandable English):

Software As She's Developed: Blummy: The Mother of All Bookmarklets

Ajaxian: If you are one of those people who love bookmarklets, and your bookmark toolbar is getting larger and larger for it, then this could be for you.

Max Kiesler: Blummy is […] in my opinion this is the best free apps of its kind. […] I review countless numbers of ajax and rails widgets, functions and apps every week but Blummy is truly a new and useful app that everyone who adds content to multiple websites should try.

UNEASYsilence: Blummy is the single browser bookmarklet to top them all. This nifty piece of javascript will single-handidly allow you to replace all your other favorite individual bookmarklets […] The screenshot does not do Blummy justice.

slapjack: Blummy Rocks. […] Maybe breaking free of the browser isn?t as important as I once thought.

Downloadsquad: Blummy: Configurable uber-bookmarklet – Today's Browser Tip

Brandinfection: blummy – The Tool to end all Bookmarklets

The Social Software Weblog: Blummy addresses that problem quite admirably by collapsing a number of bookmarklets into one bookmarklet (or blummlets, as it were) to rule them all. […] It?s a bookmarklet aggregator. It?s the Flickr of bookmarklets, yo.

Libraryclips: This is a great idea, a place to keep all my bookmarklets to use on any computer, also relieves some space on my very heavy Links bar.

German: netbib weblog, Sprblck

Italian: dowload blog, SKY TG24, Tutto Gratis

Spanish: Microsiervos, Genbeta, ├▒blog

More: WebLeOn (Chinese), PleasureDelayerDiary (Japanese), Korean Jurist, Linmagazine (Hebrew)

Thanks for the feedback!

, ,

Introducing: Blummy

So the project I've been working on lately is called blummy.

blummy is a tool for quick access to your favorite web services via your bookmark toolbar.
It consists of small widgets, called blummlets, which make use of Javascript to provide
rich functionality (such as bookmarklets).

blummy in action

You can create your own blummy by drag-n-dropping blummlets onto it.

It's hard to explain unless you've tried it yourself. So Come along. (it's free, of course)

, , , ,

Eclipse Everywhere. Buah.

It's been a little quiet lately. This is because I am working on a cute little project that I will be able to present soon. More when the time is ready.

There has been rumor lately that Zend (developer of PHP) will release a PHP Framework. This is nothing new, there has been a IDE (Zend ) for a long time now. But it will be based on Eclipse.

Also Macromedia announced that their new Flex 2.0 environment (Flashbuilder) will be based on Eclispe.

Why on earth Eclipse?! I think this is the most slowest IDEs available. It's based on Java which makes it incredibly slow already and it's so blown up that it's unbelievable.

I just can't understand why developers would use such a tool. I am not willing to buy a GHz monster PC just to have an editor running there. That's a pure waste of money and electricity. Emacs is kinda slow already but it runs on a few MHz.

Can anyone explain to me why to use such a monster?

I thought that maybe everything changed for the better by now and downloaded the whole thing. That's 100MB already. This already shows how much memory it will consume. Ok, I still started it. It took more than 2 minutes on my Powerbook G4. Hello? The features it provides are so not worth that.

I can recommend TextMate (best completition) and EditPlus (best integrated (S)FTP). These are fast, neat text editors. That's what I want.

, , , , ,

Caching of Downloaded Code: Testing Results

Today I did some experimenting with the caching of downloaded code (or On-Demand Javascript, whatever you want to call it).

I've set up a small testing suite that currently tests 3 different ways of downloading code: script-tag insertion via DOM, XmlHttpRequest as a GET and XHR as a POST.

These are my results for now:

Method IE6 Firefox 1.07 Firefox 1.5b2 Safari 2.0 Opera 8.5
script_dom cached cached cached cached cached
xhr_post not cached not cached not cached not cached not cached
xhr_get cached not cached cached not cached not cached

(Results are the same for Win and OS X where both browsers are available (FF & Opera))

Safari Code Downloading Cache Test

This gives an interesting picture: Firefox does not seem to cache any scripts, neither the ones loaded via DOM nor those loaded via XHR. Only IE loads an XHR GET request from cache.

I've got the script in my public testing area, so you can test it for your own browser. Please do so and correct my values if you receive different results.

The sources of my tests are available, too: index.phps and js.phps. I did my testings using the latest prototype.js library. Maybe I will try it later on with another library (e.g. with dojo.io.bind).

I'd be interested in more ways to download code (especially via document.write since I haven't been able to include this properly to my tests) and in your results for other browsers. Just leave a comment.

UPDATE: I have now included the Expires header field with the Javascript file. Now FireFox in both version caches the script with script_dom, in version 1.5b2 it also caches XHR with GET requests.

, , ,

Better code downloading with AJAX

I've been playing with Code downloading (or Javascript on Demand) a little more.

Michael Mahemoff pointed me at his great Ajaxpatterns in which he suggests a different solution:

if (self.uploadMessages) { // Already exists
return;
}
var head = document.getElementsByTagName("head")[0];
var script = document.createElement('script');
script.type = 'text/javascript';
script.src = "upload.js";
head.appendChild(script);

Via DOM manipulation a new script tag is added to our document, loading the new script via the 'src' attribute. I have put a working example here. As you can see this does not even need to do an XmlHttpRequest (XHR later on) so it will also work on browsers not supporting that.

So why use this approach and not mine? Initially I thought that it was not as good as doing it via XHR because you receive a direct feedback (i.e. a function call) when the script has been loaded. This is per se not possible with this technique. But as in good ol' times a simple function call at the end of the script file will do the same job (compare source codes from the last example and this one (plus load.js)).

Using this method to load code later on also provides another "feature" (thanks for that hint to Erik Arvidsson): Unlike XHRs Firefox also provides a cache for scripts loaded that way. There seems to be a disagreement about whether this is a bug or a feature (people complaining that IE caches such requests while it could be quite useful in this scenario).

When using dynamically generated javascript code you will also have to keep your HTTP headers in mind (scripts don't send them by default). The headers Cache-Control and Last-Modified will do usually (see section 6.1.2 of my thesis)

The method above is also the method used by Dojo, a developer (David Schontzler) commented, too. He says that Dojo also only loads the stuff the programmer needs, so little overhead can be expected from this project.

Also Alex Russell from Dojo left a comment about bloated javascript libraries. He has some good points about script size to say (read for yourself), I just want quote the best point of his posting:

So yes, large libraries are a problem, but developers need some of the capabilities they provide. The best libraries, though, should make you only pay for what you use. Hopefully Dojo and JSAN will make this the defacto way of doing things.

So hang on for Dojo, they seem to be on a good way (coverage of Dojo to follow).

Finally I want to thank you all for your great and insightful comments!

, , , , ,

No Google Office To Be Expected

According to an interview of Sergey Brin (founder of Google) by John Battelle, Google does not plan to publish a web based office, as rumored before (fueled by a new partnership between Google and Sun (owner of openoffice.org)).

"I don't really think that the thing is to take a previous generation of technology and port them directly," he said. I agree with that. We have to think about new tools to be our future web apps. Just porting office apps to the web won't work.

So what's this deal about now? Google seems to want a wider distribution of their toolbar. According to the Cnet coverage (via John Battelle again):

"Details about what exactly that will entail were vague at best, with the only nugget offered being that Sun, in the immediate future, will make Google's toolbar a standard part of the package when users download Sun's Java Runtime Environment from the server seller's Web site."

Sergey Brin further stated that distributed thin web applications allowed you to do "new and better things than the Office package and more." So further tools by Google can be expected.

, , , ,

Competitive Reproduction

We've seen it serveral times in history. Company A launches a new, innovative product and company B takes it, copies it and wins the competition.

Not that we have come so far in just such a short time of AJAX apps but there are quite a few examples:

A nice conversation or rather a little fight on words has started between the listed writing apps: an article in TechCrunch reported about Zoho Writer. In the comments for this article Jason Fried of 37signals (author of Writeboard) and Sam Schillace (from Writely) seem very annoyed about "such blatant rips".

But haven't we seen this earlier? Competition keeps the market alive. You cannot rest on your laurels. You have to prove that you deserve the predominant position. So if such a competitior beats you with your own product you have done something wrong, or simply waited to long. See IBM vs. Microsoft 1980, Microsoft vs. Google 2005. If you're better anyway you don't have to fear a thing.

Some interesting thoughts about this can be found at Bokardo: Web-based Office Competition Heats Up.

Posted in web

Office Web Apps are just Proof-of-Concepts

AJAX applications are far from replacing desktop office apps. So is Flash by the way.

Several projects are trying to prove the opposite. I still think that it will not happen.

The current development is only a rise of quite sophisticated JavaScript applications. We had such applications before but now it's "in" or rather acceptable to use JavaScript extensively. No. It seems to be a must to use JavaScript in new applications now.

I've created JS based applications back in 1997 when I couldn't afford web space with server side scripting. As soon as I started working with PHP I gave it up because servers were clearly faster at generating pages than browsers at interpreting JavaScript.

Rich interfaces were left to Flash at that time. As the Flash Player resides in the browser as a plug-in and operates as a natively compiled program for the platform it is run on, it provides more speed and is not only fairly dependent on browser restrictions. Additionally it is optimized for multimedia operation which made it first choice for complex navigation.

Browsers (or rather the PCs) are now fast enough to support JavaScript apps. And XmlHttpRequest of AJAX has provided the kick-off. We are now seeing rich interfaces done in JavaScript with the possibility of real time server communication for failure fallback.

There are a few points that keep AJAX apps from taking over. They mainly go together with arguments against Flash.

  • We are still caught in a browser. Ordinary web apps sit — by definition, of course — in a web browser. There are no means for accessing the local storage — which is initially a good thing. But when it comes to web apps you need to do all this up- and downloading to use these apps. Or you store everything at their server.
  • We are still caught in a browser. This is also a problem of user interface. "Normal" users have slowly adopted a different way of using interfaces when surfing inside a browser (single click vs. double click). With new interfaces we challenge them to start using web apps in another way once again. We should think about that thoroughly.
  • Web apps want your data. (see What is Web 2.0 by Tim O'Reilly) When using web applications you need to trust that app and give them all your data. Also for security reasons there is no chance to properly store the data on the client side. But even if there was, the web app would already have all your data anyway — as it needs it for processing it.
  • Running complex apps in JavaScript is a waste of CPU power. Our computers have become faster, that's true. But I don't think it's a good idea to use the speed for having a browser execute an app in JavaScript when we have stronger equivalents on our desktop.
  • Flash is a plugin. On the one hand it's a good thing. We have more CPU power. On the other hand it just does not feel right. I cannot use the browser's find function. Brr.

For these reasons I stick to my opinion that most of the web based office apps we see now are just a proof of concept. In near future they will not replace real office apps.

We also need to find methods to be able to effectively share data with our desktop computer. The current solutions I know are far from usable and prevent any ordinary user from getting into such projects.

All in all I am far from being against AJAX apps. But we need to keep the focus on apps where the technique can be applied in a useful way. I see them in the fields of collaboration and communication.

, , , ,

Posted in web