Last week colleagues of mine had a problem with an e-mail newsletter they wanted to send out; everything worked OK in Firefox and IE 7, but MSIE 6 displayed the wrong part of the page.
The setup was pretty basic; the URL in the newsletter pointed to the servers of the mailinglist-provider, where each request got logged and the browser was redirected (with a http 302 status-code and Location in the http response-header) to the target URL on one of our servers. That target URL contained an anchor to have the browser to display a specific tab on the page thanks to some jQuery-magic, which worked perfectly in Internet Explorer 6 in a non-redirect scenario.
The problem seemed as simple as it was annoying; MSIE 6 dropped everything starting with the ‘#’ from the URL when performing a redirect. Google pointed me to some sites that claimed that adding an ampersand should solve this, but that did not work. I made a little PHP-script to test with different encoding-tricks, but that did not work. So that old fart of a browser indeed did not support anchors in redirect-URL’s and that’s what I told the colleagues last Thursday.
Yesterday I started writing this post, thinking it was a great time to demand the death of the piece of junk that Microsoft unleashed on us back in 2001 and which, believe it or not, still has 16,94% market share. So I replaced the company-specific address in the php-script with the URL of the wikipedia-page about anchors and … it just worked, even in MSIE 6! And then I remembered getting that silly popup in MSIE 6, warning me that “The current website is trying to open a site in your Trusted sites list”. Apparently the ugly bugger does not only ask you if he can redirect, but also eats the anchor in target-URL’s that are in your Trusted sites.
So dear colleagues, in case you’re reading this; you can send out that newsletter now, it’ll work for everyone except for those who are silly enough to use MSIE 6 with our site in their “Trusted sites”-list. And let’s not forget; MSIE 6 must die is dead!
Web development
Blogposts on blog.futtta.be about “web development”; looking into frameworks, security, best practices, the use of Flash, usability and accessibility, …
Firefox 3.5 and tinyvid.tv do Ogg/Theora
Google might be pushing back support for HTML5’s <audio> and <video>-tags in Chrome, but these certainly are one of the nicer features the upcoming version of Firefox will bring us. Version 3.5 (RC1 will probably be released the beginning of July) will indeed natively support ogg/vorbis, wav and ogg/theora. And this is important why? Well, apart from the open source (Theora) vs proprietary (Adobe Flash with VP6-codec) argument, using video will allow us to get rid of the memory (and cpu) hog Flash can be (or at least to replace it by another cpu-hog 😉 ).
Now having Ogg/Theora built right into your favorite browser might be great, but you’d need a place where you can use that as well, no? Well, there’s no support for Ogg on YouTube yet, but that void can be filled by TinyVid, an “experimental Ogg video uploading and converting site”. Especially the converting-part is handy; just enter the URL of a YouTube, Vimeo or Daily Motion-video and TinyVid will download and convert it for you a few minutes later (depending on the length of the conversion queue).
So you’re having big fun, uploading, converting and watching, but wouldn’t you want to show off those great vids on your open source blog as well? Easy-peasy;
<video src='http://tinyvid.tv/file/3h31b472fv0ng.ogg' controls='controls'></video>
And if you’re in a partcilurly good mood and you want friends that are not running an Ogg-enabled browser to be able to see some disco, you could even try this;
<video src="http://tinyvid.tv/file/3h31b472fv0ng.ogg" controls="controls">
<applet code="com.fluendo.player.Cortado.class" archive="http://tinyvid.tv/static/cortado.jar" width="640" height="368">
<param name="url" value="http://tinyvid.tv/file/3h31b472fv0ng.ogg"></param>
<param name="BufferSize" value="4096"></param>
<param name="BufferHigh" value="25"></param>
<param name="BufferLow" value="5"></param>
<param name="duration" value="257.369"></param>
</applet>
</video>
And that’ll result in Thom Yorke doing this disco-version of “Everything In Its Right Place” in Theora;
Developing a mobile blogclient with Breeze
I’m one of those crazy gadget-loving freaks that are eagerly awaiting the arrival of the Palm Pré. One of the reasons I’m that exited about that device is the development-stack. Applications are written on the Mojo-framework: html+css+js plus a great API to interface with the OS and hardware. But the Pré isn’t available yet and there’s nothing more to do then drooling over the specs, the pics and the vids. Or is there?
Actually there are more companies betting on html+css+js-stack as mobile application development platform; the mobile version of Google Gears allows you to download web-applications to run locally (which is a slightly different approach, but with approximately the same result). And another giant, Nokia, has its Web Runtime for S60 5th edition devices, which seems to follow the W3C widget-specs to some extend (they can be tested as Opera widgets).
The issue with both environments however, is the lack of an API to interface with the phone. And that is not the case for my latest crush; Cascada Mobile‘s Breeze. Breeze provides you with a simulator (or Eclipse-plugin) and a simple javascript API to access o.a. storage, contacts, camera, gps and network off course. It compiles your applications into J2ME midlets, which can then be distributed via breezeapps.com and installed on a whole bunch of J2ME handsets (Nokia, Blackberry, LG, Samsung, Sony Ericsson, …).
I’ve played around with Breeze, building a prototype of a blogging-client (ugly and wordpress-only for now, source here) and it really is great fun to develop applications that way. And it works too; the first draft of this post was written using it on my Nokia E61i. How I love the smell of my own dogfood in the evening!
Powered by mlogger
5 reasons why the NMBS should have an API
This weekend I joined the Facebook-group “NMBS should have an API”. The NMBS (or SNCB, for the route planner) and Infrabel (for railtime) have data available that is very relevant for their customers, but this does not really translate in great applications, does it? Wouldn’t it be better for public companies such as the NMBS to focus on exposing their data/ business logic and less on the presentation, allowing 3rd parties to connect to their API’s to create innovative new applications?
Just image what kind of sexy, useful applications that could be created this way. Here’s 5 to start with:
- A mobile application that can
- plan your rail-travel based on your current GPS-position and the destination you enter
- adapting your route while “on rails” in case of delays of current or next train
- A Netvibes-widget containing basic route planner and railtime funcionality. Netvibes is great by the way, their widgets can be deployed in Netvibes, iGoogle, Live.com and standalone on any site, but also on your Mac OS X and Vista desktop. I build a very simple LinkedIn widget almost a year ago. It’s actually little more then a wrapper around their mobile site, but according to the Netvibes stats it’s installed by more then 1200 users. Great potential!
- mytrain.be: a personalized website for daily commuters:
- register and select the train(s) you use on what days of the week
- receive warnings by mail/ sms in case of delays
- automatically propose alternative routes in case of delays
- A sexy mashup of real-time train info and Google Maps, as already seen on http://swisstrains.ch/ (great to look at, not sure it’s that useful though)?
- A trainusers-application integrating into social websites, allowing you e.g. to hook with fellow-travelers on Twitter or Facebook while on rails?
So indeed, NMBS and Infrabel, give us API’s and enjoy the great stuff that’ll be build on it. And if you’re reading this and you would like to use or develop applications based on such data, join that Facebook group!
Fun with RFP’s: organizing a RAD-race
Selecting a good (web-)application development partner is not an easy task. Between writing your RFP, reading offers, organizing Q&A-sessions, commercial and juridical negotiations, … it’s easy to lose sight of what is most important: finding someone with the right tools and the right knowledge and experience to efficiently build (web-)applications.
That is why (at work) we decided to include a POC in the last phase of our “web framework and development services” selection process. But not just your normal POC, where you have no control over the context in which the development takes place. No, we brought in Ivan Verborgh to help us organize an “original RAD race“. In such “development competition” you put the participating teams in 1 room and give them 1,5 days to create the same administrative application. And somewhere along the line you throw in a change request as well, just for the kicks of it (and to check agility off course).
Our participants had to use a Java-based solution (as defined in the RFP), but their frameworks were very different, with one opting for a commercial product and the other one for an open source component stack. Without going into too much detail, the RAD-race was a great experience for us as well as for the participants. Although neither team was able to complete the assignment, there was a clear difference in the teams’ performance. For some colleagues the results were a true eye-opener, with one competitor clearly having less knowledge and experience with their chosen framework. The result of the RAD-race was an important element in our decision process and it was a fun experience during an otherwise sometimes dull RFP-process.
Mijn deredactie-journaalplayer gefixt
Dju, m’n journaalplayer is was kapot!
Dat heb je natuurlijk met spielereien op basis van ongedocumenteerde 3rd party xml-feeds; als de bron wijzigt, dan werkt je webhackje ook niet meer. De atom-feed die ik gebruikte, was sinds de lancering van de videozone (en de stille redesign) van deredactie immers niet meer beschikbaar.
Uit een snel testje bleek dat de nieuwe videozone andere feeds (voor Journaal en Terzake) gebruikt. Die feeds bevatten zowel entries voor de integrale afleveringen van de afgelopen dagen als voor alle individuele fragmenten uit die verschillende edities. Aangezien een entry in de ATOM-file evenwaardig is aan elke andere entry, wordt de relatie tussen die verschillende entries dan maar in de comments in de XML meegegeven. Of hoe XML ook gestructureerde rommel kan zijn.
Maar aangezien er op deredactie nog altijd geen grote knop “Bekijk hier het Journaal” staat, omdat een kat zijn jongen niet terugvindt in de videozone en vooral omdat ik het niet leuk vind als mijn speledingetjes niet meer werken, heb ik één en ander toch aangepast aan de nieuwe feeds (waarbij ik op basis van de titel de individuele fragmenten van de meest recente aflevering uit de ATOM-feed filter).
Hoera, m’n journaalplayer werkt dus terug.
Stop software patents
Really, sign this petition:
If in doubt, just check out some of these European software patents;
- Webshop: Selling things over a network using a server, client and payment processor, or using a client and a server – EP803105, EP738446, EP1016014
- Order by cell phone: Selling over a mobile phone network – EP1090494
- Shopping cart: Electronic shopping cart – EP807891
- Adapt pages: Generate different web page depending on detected device – EP1320972
- Related results: Show related results if customer likes the current ones – EP628919
So stop coding that fancy webapp now and go sign that petition!
Voorspellingen 2009: browser-oorlog, ook mobiel
Naar aanleiding van de publicatie van de voorspellingen van 20 online experts door Netlash, zijn dit enkele van mijn verwachtingen voor het web in 2009;
- Uw job als (front-end) webdeveloper (of tester) wordt er door de grotere concurrentie tussen browsers niet eenvoudiger op. Ge zult niet alleen moeten ontwikkelen voor Internet Explorer (het nieuwe IE8, maar ook nog altijd voor het verwenste MSIE6 en voor versie 7 natuurlijk) en Firefox, maar ook voor Safari en Google Chrome. Samen zullen deze Webkit-gebaseerde browsers eind 2009 immers tot 15% van de browsermarkt pakken (nu al 9%), tegenover 25% voor Firefox (nu 21%) en pakweg 60% voor (MS)IE (nu nog 68%). Gelukkig zult ge wel iets meer kunnen terugvallen op standaarden (MSIE6 buiten beschouwing gelaten) en zullen componenten als JQuery, YUI of Dojo uw cross-browser inspanningen blijvend verlichten.
- Bling-developers mogen die dure cursussen Silverlight en JavaFX annuleren, Adobe blijft immers oppermachtig met Flash en -ondanks de gigantische hype in 2008 in veel mindere mate- met het nauw verwante Flex. 2009 zal overigens niet het jaar van Flash op mobile zijn. Een volwaardige versie van Flash voor GSM’s zal immers pas op het einde van het jaar uitkomen en zal dan nog enkel vlot werken op smartphones met ARM Cortex gebaseerde processoren, die nu ook nog niet te koop zijn.
- Webagencies staan voor een belangrijke uitdaging; “mobiel internet” groeit (mede dankzij krachtige Webkit-gebaseerde mobile browsers) zowel aan vraag- als aanbodkant en kosten-bewuste klanten zullen convergentie tussen hun mobiele en hun “gewone” website hoog op het verlanglijstje hebben staan. Mobiel web wordt dé groeipool, ge kunt dus maar beter mee zijn, zowel functioneel (“mobile usability“) als technisch (er is meer dan Mobile Safari, niet iedereen heeft een uitgebreid toetsenbord en device-dependant rendering is een moving target).
En voor een recessie tenslotte, heb ik in 2009 echt geen tijd. U ook niet, toch?
WebApp Security is mandatory (even for spammy virals)
I just received a mail from Frank Goossens. I’ve apparently invited myself to view “an adorable Christmas-card” containing “warm wishes”. Moreover I tried to guilt-trick myself into forwarding that same card to friends and family, as that simple gesture would provide the poor with (unhealthy fried) food for the Poverello Christmas-dinner.
In general I don’t like virals, but I was curious to find out if Agency.com just spammed me or if someone (ab)used my name and email to bug me. So I clicked the link, told Noscript to trust the (flash-)site temporarily, looked at the Firebug-output while testing the application and tinkering with some of its URL’s.
The results:
- One can tweak the system for the “message” to contain links and images (lesson 1: do not solely rely on client-side validation in flash or javascript)
- Going one step further, you can also insert javascript in that message. That code isn’t executed inside the flash e-card, but assuming there is a plain html-backend (there always is, for reporting or export-purposes) it’s trivial to sniff the backend URL and steal the session-cookie as soon as someone accesses a page which contains that message. The URL and session-cookie can be used to gain access to the admin-site (lesson 2: render all user-submitted data harmless before storing in the database, use a html filtering component if need be)
- It’s trivial to abuse this system to send spam with 1 automated GET-request per 5 recipients (lesson 3: think about how your system can be abused an try to harden it accordingly)
- It’s really easy to “harvest” all 48.000 names, e-mail-adresses and messages sent (lesson 4: auto-numbers are a bitch)
Ladies and Gentleman marketeers and ad-agency account executives; do not think that virals, mini-sites and e-cards aren’t susceptible to hackers. You should consider web application security as a mandatory feature! Unless you have an unstoppable urge to gift-wrap your (or worse, your customers) data and hand it out to spammers and hackers, off course.
Free your content now!
Bert Van Wassenhove considers RSS to still be “a diamond in the rough” which has not yet been picked up by the mainstream public. The reason for this, according to him, is that:
[Newspapers] copied their paper/website logic to RSS feeds without adapting it to the medium. As a result, you get long lists of news articles with no difference between front-page news and a small article at the back of the newspaper.
To solve this problem, he proposes editors to (also) offer a “front-page feed”, which would contain only the most popular (automatic) or most important (handpicked) items.
Not a bad idea at all (are you listening, deredactie?), but even more important; shouldn’t news-websites start treating RSS as a publication-channel in its own right, containing the entire article (and why not even enclosures for AV-material)? Because, expecting me to click through, seriously?
- I don’t have the time to click through when quickly skimming through my feeds at work
- I can’t click through when reading offline, on the train
- I don’t want to click through and have to load 1or 2Mb to see an article in it’s bloated context when reading on my mobile phone
RSS-feeds can indeed be a great way for readers to focus on content, without the overhead of the “normal” website-context. Heck, I’d even accept some text-ads and links to related items in there if need be. Publishers will sooner or later really have to let go of the concept of their (semi-)walled garden as the only place where visitors are allowed to consume their content (as they had to let go of the paper-only distribution-model). Focus on reach (“content views”) instead of pageviews, allow your readers to decide in which context the content is consumed (think rss-reader, think syndication, think mash-ups, …)!
I happened to stumble across this full atom-feed for deredactie.be, containing entire articles and enclosures for images, audio and video and it’s just great! I’m sure it could help info-overloaded users to keep more up-to-date with the news and that an official (because this one isn’t) full feed from deredactie could massively improve the reach of the great VRT nieuwsdienst content (according to CIM they’re really not doing that great when compared to the competition).
So, let me quote Bert; “Mr. editor in chief, please help RSS to become the success it deserves to be” and I’ll happily add “Set your content free!” to that.