The idea

Finding lyrics has been a longstanding pet-peeve of mine. A lot of music players don’t allow to you easily copy the title and artist so you have to manually type them into Google. Once you’re there, most sites are cluttered and spammy. Way too annoying.

Lystener asks you for your last.fm username, and then displays the lyrics to what you’re listening to. Simple but effective.

But that’s not the entire idea. Posting lyrics to Facebook and Twitter is something a lot of people do, and the process for that sucks, too: you had to find the lyrics via Google and the spammy sites I mentioned earlier, copy the part you like, paste it into the form on Twitter or Facebook, format it, add the title and artist and only then you’d be done. With Lystener, you just select the lyrics you like and Lystener takes care of the rest, leaving you to just click the ‘tweet’ or ‘publish’ button.

Launch!

Go check it out! I’m pretty exited to see what everyone thinks, so please let me know. I have a whole bunch of ideas lined up to expand Lystener, but if you have ideas I’d love to hear them. To keep up with the updates, follow @LystenerApp on Twitter or like Lystener on Facebook.

Read on to know how I made it:

The process

After getting home I bought the domain name (I had thought up a name in that great moment when you’re not quite sleeping and not quite awake yet and everything is clear as glass.) and started sketching and coding. At the end of the day, the app was 60% done and after working on it for the entire Saturday, the minimum viable version was done as well. I invited people for the ‘beta’ and gave people access on Sunday, requesting feedback in the process.

That’s it, a web app in a weekend. What now?

The response under my beta testers was overwhelmingly positive, save for one thing: the lyrics themselves. I used an API that didn’t give full lyrics, and didn’t have a lot of songs, and was really error prone. It sucked. A website can work well technically, but if it doesn’t display what you want, or only partially displays it, it’s not useful.

So I decided to switch over to another API, the chartlyrics API. It had a lot more matches, it provided full lyrics and if lyrics were missing, they have options to easily add the lyrics. From Sunday to Thursday I tweaked my fetching script to find more lyrics and match better.

I’ll be iterating Lystener.com from now on, and if you have ideas I’d love to hear them!

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

A web app in a weekend: Lystener.com

Fronteers 2010 will be held the 7th and 8th of October in the beautiful Tuschinski Theatre in Amsterdam. While usually a movie theatre, we’ll be using the gorgeous room with awesome soft, red cinema seats, a huge stage and an absolutely gorgeous art-deco interior as the place where, for two days straight, the best of the best of front-end will come together.

Speakers

Fronteers 2010 has an impressive list of speakers:

• Cameron Adams
• Jina Bolton
• Jeff Croft
• Brendan Eich
• Jeremy Keith
• Nicholas Zakas

And those are just the first six of our fourteen presentations covered! Just yesterday we also announced Brad Neuberg and Steve Faulkner + Hans Hillen, and you can expect a whole bunch of really cool names to follow in the next couple of months.

The conference will be hosted by my buddy Justin, who did an excellent job at being the master of ceremonies, last year.

In terms of topics, We’re shooting for a more diverse range of topics than last year, while still keeping the technical level high. Expect topics dealing with HTML5, CSS3, JavaScript, performance, SVG and accessibility.

Workshops

Apart from two days of awesome presentations, this year we also host two workshop days in advance of the Conference. One workshop by Andy Clarke, and one by Dan Rubin. The former will be interesting to front-end developers looking to really hone their skills and be updates to all the latest CSS3 goodness, while the latter is set up specifically for designers interested in starting with CSS, or at least getting more of a grip on it.

Tickets

As of writing, there are just 50 early bird tickets left, at the insane price of just € 275. After next week, the price for a ticket will go up with 100 euro. So, go get some tickets and I’ll see you there!

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

Fronteers Conference 2010

‘We’ in this case is my team at Fluxility. Most of the time we make websites and webapps for clients, but we’re focusing more and more on building our own sites. This was at once a fun diversion, a project to see how fast we could bring something “to market” and whether we can make a Facebook app work. We’re still out on the last one, but the first two have been a major success in our book. :)

Facebook integration

The worst thing Facebook could do was change their API right before we started. Which of course they did. This meant we couldn’t use the current Django facebook apps available, and had to write our own.

With focusing on getting the website online, that app needs to be cleaned up a bit first but then we’ll open source it over at Github so everyone can use it. Facebook’s documentation and application settings are pretty bad. Every thing’s there, sure, but it’s very opaque and hard to find. We got there, but it took far more work than necessary.

Front-end stuff

As the website is basically one page, there is a lot of JavaScript and AJAX stuff going on (yay!), including getting the YouTube videos. For that we use oEmbed. We started out with the jquery-oembed plugin. Unfortunately during testing the webservice behind that plugin (oohembed.org) was offline a lot. It’s hosted for free at Google AppEngine, so it’s understandable, but we need something a bit more reliable.

Enter Embed.ly. I replaced the jquery-oembed libary with 6 lines of youtube-specific code, wrapped it in a jQuery plugin and it worked. Awesome! One thing I hope Embed.ly will do is add a wmode=transparant to YouTube videos to make it easier for us to do stuff with it. I could add it in with JavaScript myself, but I’d rather not.

Up next

Everything is working pretty well right now, but of course we have plans to expand. We offer a homepage position for videos for 300 euros a week (discounted from 500 for this month only). People can vote for this video too, so if your video is awesome enough, it’ll enjoy another week in the top ten.

As for the site itself, we want to get to daily top tens as soon as possible, but this means we need traction first (so get on there!). I’m also developing a Bookmarklet so you can vote directly from YouTube and we’re going to add a page with all submitted videos for you to peruse.

Let me know what you think and of course Become a fan and Start using Youtubetopten.com!

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

YouTube Top Ten: my new Facebook app

Trimage

Trimage is a GUI front-end to a couple of command line tools available on most linux based systems (though it should work on mac and windows, too), and can losslessy compress both PNG and JPG files. It looks native, (dare I say) pretty and is very easy to use.

That’s why Trimage has multiple ways of accepting files: You can drop them onto the app, you can open them via a file dialog, and you can feed it images or entire directories via the command line. So you can pick the method you find most comfortable, and use that.

More information can be found on the website: Trimage.org.

How to install

For the moment, I only have installation guides for Ubuntu and other linux-based systems. If you can help me with Mac and Windows, please e-mail me at help@trimage.org!

Ubuntu

Ubuntu is by far the easiest to install. If you’re on karmic or lucid, simply enter this into your console:

1. sudo add-apt-repository ppa:kilian/trimage
2. sudo apt-get update
3. sudo apt-get install trimage

If you are still on Jaunty, read this guide on installing PPA’s.

Other Linux:

I’m still looking for help with making .debs, .rpms and the like, but you can install Trimage via python as well:

1. Download the source via GitHub or Launchpad
2. Make sure you have all the requirements installed: python 2.6, python-qt4 4.4, optipng 0.6.2.1, advancecomp 1.15, jpegoptim 1.2.2, or higher versions
3. Enter python setup.py install into your console
4. Launch by executing trimage

Why and how

As I said in the intro, I wrote this mostly to scratch my own itch. I wanted an easier way to compress my files that didn’t involve mucking about on the command line or uploading all my images to some server far away via a crappy flash application.

Trimage was inspired by ImageOptim. It is made using python and the PyQt GUI framework. The choice for PyQt was made for a couple of reasons: the Qt4 designer is very easy to use, it’s available cross-platform and most importantly, it provides native widgets. As the latter is my number one annoyance, and I actively avoid using programs that do not look like they belong in my gnome desktop, this was a big issue for me. Paul Chaplin helped me with a lot of the python stuff.

However, PyQt has some downsides as well. For one. The documentation is bad. It’s not complete, hard to read and sometimes isn’t even correct. That’s not to say it’s unusable, but it clearly needs some more love.

Where the documentation lacks however, the #pyqt IRC channel on freenode is awesome. There are a bunch of really smart and nice people there that go out of their way to help you. Every community should be like this.

If you want to build a GUI app for Ubuntu using python, the best start you can get is PyAppTemplate by Neil Wallace, which takes care of all the Hoohaa and voodoo that goes into a setup.py and the debian build files. It took me a day to try and figure it all out by myself, and then an hour to get it working using PyAppTemplate.

Future development

As you can see on the website, I have a bunch of features lined up for the coming versions. All development is done on GitHub, so if you want to help out, add more options or scratch an item from the todo, I appreciate all help!

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

Trimage image compressor

So I decided some action needed to be taken. I got the domainname websitesthatdontworkwithoutwww.com, installed Chyrp, got a Thumbalizr API key and started making a list. Name ‘em and shame ‘em!. If any of the websites fix their non-www version, the without thumbnail will automatically update and I’ll add a link to their site :)

Input time

The site is there, and it has a couple of websites on it, but now I need your input to start adding more and more! If you encounter sites that don’t work without www., please send them to submit@websitesthatdontworkwithoutwww.com. You can also @reply the twitter account: @wtdwww. (and better yet, follow it!)

The Firefox thing

During development I got a couple of remarks that “well, site X just works you know”, to which I could wittily (*ahem*) reply “Nope, it doesn’t. I bet you use Firefox 3.5!”. That’s because Firefox 3.5 automatically adds www. in front of domain names if they don’t work without. While this is awesome for end users, it just hides the fact that a lot of hosting providers/webmasters are incompetent at doing their jobs. In that regard it’s a shame.

Since I don’t want to just point and laught, fun as that is, I’ve also added a help page, where some explanation of how to fix the non-www website will be placed. I’m still working on that, if you want you can help (just shoot me an e-mail!)

This was a fun little project I made in a couple of evenings. I still have to soften up some of the edges and tweak parts of the “site”, but overall I’m pretty happy with how easy it was to set up.

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

Websites that don’t work without www

Graphic libraries exist to take the page from the rendering engine and onto the screen. They’ve been underexposed for some time because the rendering engines caused the most grief, but with those getting rapidly better, little annoyances with the graphic libraries start to appear.

Google Chrome

When Google announced Google Chrome and it turned out to use the Webkit rendering engine, I think everyone collectively sighed in relief. Not yet another browser to support! Well, that was until it became known that Google Chrome actually doesn’t support a lot of Webkit’s more advanced CSS stuff such as text-shadow or transformations. The reason for this is called Skia.

Skia is the graphic library Google Chrome uses. Webkit renders the page and then Skia actually paints it on the screen. All fair and well, but Google Chrome is the only browser to use Skia. Safari, which also used Webkit, uses the Core Image libraries. So while you may expect that the stuff that works in Safari also works in Google Chrome, that won’t always be the case. The result: Same rendering engine, different looking sites.

Firefox

Another example: Firefox uses the Gecko rendering engine. It used to use the Pango graphics library but some time ago they switched to Cairo, which dramatically improved Firefox’s graphic rendering. However because of Cairo, fixed elements, when viewed on Linux, jitter. If you’re on Linux, and scroll this website, the top right background jitters. Very annoying, especially since this doesn’t happen on Mac or Windows. This isn’t a problem of gecko, but of Cairo having to (re)paint the site on the screen.

So what does this mean?

Do we all have to buckle up for a new era of browser hacking and working around more and more cross-graphic-libraries oddities? No, I don’t think so. I don’t think this will really become a big problem.

However, very few people know about the how and why of these differences. As a front-end developer it will help you build better websites if you do. So will you?

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

On rendering engines and graphic libraries

What’s up?

There is often a misunderstanding between designers and clients. Designers want clients to provide an overview of their business goals and client perception and apply their knowledge to make a design fitting with those goals. And clients, clients want more blue. Or yellow. Or mauve.

Dealing with design critique starts right at the beginning of a project. At that time, it’s best to confront a client with the way you work. what do you expect from them and what can they expect from you. I use a website requirements list that only touches on looks at just one question (asking if they already have ideas for the design themselves) and I’m considering taking it out. The rest of the questions are all based on their business goals. What do they want the website to achieve, what do they want their visitors to think about them, who do they want their visitors to be (and no, everyone is pretty much never a target audience). Then, the next question is…

Why

Clients say A, but mean B. You hear this a lot, and that’s because it’s true. There is, however, one question that will lead almost every client from A to B in a quick, painless way. Why?

Why happens when you craft a perfect design fitting to their every business goal and targeted at precisely their audience, and the client doesn’t like the colours. You ask them why they don’t like the colours. Perhaps he discussed his website with his wife, and she really liked hot pink. By explaining why the chosen colours fit with the clients business goals, and thus provide an advantage for them, you can help a client realise you want the best for his business, not the best for his (wife’s) personal taste.

By asking why, and allowing a client to explain his reasoning, you can show him, in a non-insulting way, that design is not about personal preferences.

Luckily, however, it might just be that a client has a perfectly valid business reason for wanting hot pink instead of whatever colour you chose. Being able to recieve design critique means that you can objectively decide whether the client is, indeed, right, and hot pink fits their business goals better.

Just because

ew. ew. If in any way possible, avoid clients that do not provide solid reasoning and arguments for their critique. If someone can’t tell my why they do or do not like something, I’m not listening to them. By asking the why question a lot at the beginning of a project you can easily filter these clients out. Filtering them out doesn’t always mean not taking them as a client. Sometimes, clients like this are really easy on design choices, and sometimes charging a lil’ more covers the frustration just fine ;)

This is the system I use to handle clients and design critique, What system or method do you use?

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

Why?

I am, obviously, talking about the Browser Wars of lore, between Internet Explorer and Netscape. At the time, both browsers were rapidly innovating and adding new features, — however, they both implemented different stuff, never the same thing in the same way. This caused web developers to develop for one of the two, two different sites for two browsers, or one sub-standard website that worked in both.

Luckily, This is all over now

Now, with increasing standards based browsers, this should be a thing of the past, right? wrong!

While we’re all piling over the new stuff the Big Four, Safari, Opera and Firefox (and, IE8, I ‘spose. At least, some people. I think…) come up with, both in own ideas and in standards support, there is an increasingly divergent pattern visible.

It seems that with every new nightly build, Safari (Webkit) adds a mindblowing new feature that’s still lacking documentation but oh my, it’s shiny and f-ing cool.

Opera, on the other hand, is hard on it’s way to be the first HTML5, CSS3 conforming browser. Oh, and for good measure, they added in pretty much every other standards: (X)HTML, XML, XSLT, CSS 2.1, SVG 1.1 and JavaScript.

Firefox is, well, playing catch-up with the above two, adding a bit of the idea’s from safari, opera or, if you’re lucky, both. To be honest, it’s also making great headway on SVG.

And IE isn’t even trying, adding their own non-conforming microformats and just getting round to CSS2.1. well, whoop-dee-doo! Now go to bed and stay there, this is grown-up time.

What do you want to be?

Opera is heading towards ultra-super-duper standards support. Safari wants to take over the desktop. Firefox wants to integrate the desktop and the web. Internet explorer… just wants to play with the big kids.

But because of these goals (as they are perceived by me, anyway) all the browsers have different priorities in what features they support. This makes business sense, but it’s incredibly frustrating for developers. Web standards are of course supposed to be the baseline here, but in reality they are not, and standards-based feature support is just as diverse as home-grown innovations.

What can we do

The way I see it, for developers, there are a couple of options:

• We can stick with HTML4 and CSS2.1 for the foreseeable time, they’ve solid support nowadays
• We learn every feature of every browser and serve (slightly) different pages to each
• we give up and all start using plaintext.

Obviously the latter isn’t going to happen, but the first two look suspiciously like the choice the martyrs in the Browser Wars had to make. Only instead of two browsers, we now have four to support. (Being extremely positive and forgetting about IE6 and IE7)

This is not a choice we should make

I’m all right with different browsers having different goals, and them needing different features for it. However, we thought up standards for a reason. The reason being interoperability.

What I think needs to happen, is an even larger degree of openness concerning features. Not business goals, just features. With 50% of the Big Four being open source, this shouldn’t be hard. Both Webkit and Firefox already have a lot of documentation, and Opera, despite being closed-source, offers a tremendous amount of documentation as well. (Notice who’s missing…)

All I’m asking for…

…Is a single document, outlining the baseline support in the browsers for the coming years (increasing the baseline each year), agreed upon by the Big Four. That’s is all that’s needed to help mature the web in a developer and user-friendly way and will still allow each individual browser to focus on it’s business goals.

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

The great divide

Nice stuff

SenCSS 0.4.5

How vain, to start with something of my own! Anyway, I released version 0.4.5 on saturday, and made a simple homepage for it: sencss.kilianvalkhof.com. It has links, changelogs and general information. I decided that the way to pronounce it is “sense”. Also, it surpassed 1000 downloads, cool! :D

Proposed Default rendering of HTML elements

Something I wasn’t aware of, the W3c has a default CSS2.1 stylesheet for HTML: http://www.w3.org/TR/CSS21/sample.html. It probably won’t lead to Amazing New Insights! but it’s nice to read what the makers of CSS thought would be correct standard CSS for the HTML elements.

Funny IE-hack

Tired of using * html to hide your css for IE? Someone over at mintpages recently did this:

#idname[id] { ... }
.classname[class] { ... }

Which is something like “select all elements with the ID “idname”, but only if they have an id attribute. A smart and funny way to hide it from browsers that don’t support attribute selectors. I thought that was funny. Stop looking at me like that.

Firefox 3 improvements

Next to the awesomebar and some other GUI improvements, Firefox 3 has some cool CSS improvements. In my opinion, these are some of the more interesting ones.

cursor:none

From a technical viewpoint it makes sense to have this option, though I’m not certain if it’s a really good idea. body{cursor:none} just doesn’t fit right. However, it could be useful in other instances, such as rich internet applications or video.

Ligatures! and kerning!

ligatures are awesome, and because Firefox 3 uses Cairo for it’s rendering, it can now do both ligatures and kerning. I don’t know of any web fonts having ligatures (correct me if I’m wrong, so I can start using that font everywhere) but proper kerning is certainly a nice feature. This article explains it very thoroughly: Firefox 3: Fonts and text

Firefox 3 has a CSS property called text-rendering. By default it will guess the right rendering, opting for either speed or legibility. By using this code, you can make sure that it will always opts for legibility, which enables kerning and ligatures:

body {text-rendering:optimizeLegibility;}

Check the Mozilla developer center for more information.

Font-size-adjust support

It took me a while to get what this does exactly, but I think I understand it now. As you might know, not all fonts look equally large at the same font-size. for example, Verdana looks much larger than Arial. This is because Verdana has a larger x-height than Arial. (x-height is the height of, indeed, the x and other letters without ascenders or descenders).

The value for font-size adjust is the ratio between the x-height and the full height of your font. By specifying this ratio for your first font, your browser can resize the fall-back font to have the same x-height as the original font, instead of the same full height. The result is that the fall-back font will look as large as the original font, thus fitting better in the design and being more legible. And Firefox 3 supports that, now :)

Text-shadow support in Firefox 3.1?

According to this article We’ll get text-shadow in Firefox 3.1. That makes for one dirty hack ready for the bin :)

That’s it for this week, I’m sorry for not writing anything new or exiting. I’ve got plenty of good stuff planned, but it’ll take a little longer :) See you next week!

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

Small bits

If you’re feeling adventurous or not as Dutch as you thought, here is a pretty funny Google translation of the article. The Google translation is quite unreadable in some places, so given enough interest I might translate the article into proper English for re-posting on this website. Who’d be interested in that?

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

External Reading