Tuesday, May 27, 2008

Styling <select> tag widths

OK, there are a gadzillion web pages on the web already complaining about IE (pick any version up to 7) and the way it handles the <select> tag. My main problem was that I wanted to give the dropdown list a fixed width, so it could fit within the bounds of a box on the screen, but I cannot control the length of the items in the list, so I need to be able to show the user the entire text when trying to select the value.

My first attempt simply fixed the width CSS property. As you can see the result was perfect in Firefox:


However in IE7 (even with the new <select> tag) it just truncates the values:


When testing this with actual client data we realised they had values that differed in the last couple of characters only (e.g. "Training Course 001" and "Training Course 002"., but much longer).

So I went ahead and removed the width CSS property from the relevant class, and this is what we got:


The problem is now that the remove icon is covered up, preventing the user from using it until they have selected something from the list and it replaces the edit box with the read-only one (like below):


I looked for ages to try and find good cross-browser safe ideas for how to handle this, and briefly tried using JavaScript to trap the onclick and onblur events and re-size the field at that point. Ugly. Buggy. And just plain nasty as a future-safe solution. I even tried setting width on <option> tags using CSS, but while that worked in Firefox it still failed in IE.

So after much trawling for help, and revising much of what I already knew about styling forms in CSS, I came across this gem of a solution. Setting the title attribute on the <option> tags allows them to show a tooltip in IE7 that shows the user the full text value of each option:


Monday, May 26, 2008

Om's got the wrong business model for Twitter

I've been spending a lot of time recently looking at product strategies for Elcom, so I was particularly intrigued by one of Om Malik's latest posts that highlighted a business model for Twitter in the midst of their Scoble Problem. He says that he has “a theory that could help Twitter solve its scaling conundrum and also help the company make money”. What he's referring to, of course, is the rather expensive impact that a popular user like Robert Scoble has on their infrastructure.

Twitter (see my feed in the right hand column of this blog) is self-described as essentially a messaging system built on an architecture that better suits a content management system. This means that every time someone tweets, a record is created in a database, and then subsequent to that, tens, hundreds or thousands of messages are sent regarding that tweet - potentially creating their own database records along the way. Unfortunately Scoble has 25,000 followers, so every post from him involves 25,000 messages (and possibly text messages to mobile phones).

“Of course, Om's answer is completely wrong.”

Om says that the answer for Twitter is to view commentators such as Scoble as cash cows, and charge them for the right to have a certain number of followers. Of course, Om's answer is completely wrong. Twitter needs Scoble much more than he needs them. Why should he pay to have followers there? There are dozens of startups waiting for someone like him to to give them the techies' equivalent of an Oprah moment.

Om is right in one sense, the answer to Twitter's business model is hidden in the Scoble example. Instead of charging Scoble for the right to use their system, they should charge people who want to follow Scoble - beyond perhaps the first hundred or so. This allows anyone to use Twitter (helping network externalities along), whilst ensuring that the really heavy loads on the system are paid for, but by the subscribers to the content producers, not the content producers themselves. Another problem is that anyone could create masses of bot accounts to simply drive up your least favorite twitterer's monthly bill.

“That's almost ten times the income without annoying Scoble”

Instead of charging Scoble $10/month for 1,000 subscribers, giving them $250/month, they could charge the people that want to follow Scoble (past the first 100 or so) 10¢/month each, giving them $2,490! That's almost ten times the income without annoying Scoble, by simply asking people to pay a small premium fee if they want to know what Scoble is thinking right now. With that model they can grow as much as they like, and encouraging people like Scoble to use Twitter becomes a win-win proposition.

They are left with a micro-payment problem, but if people follow more than one interesting twitterer then the payments will quickly add up, and with volume I'm sure you could make credit card companies your friends. Besides, you could probably inflate my 10¢/month to 50¢/month with no great outcry. Now Scoble might get annoyed if suddenly 20,000 of his followers disappear, but then again, at least he knows the other 5,000 place a real value upon his tweets - and that's worth a whole lot more in media terms.

[UPDATE: It seems Scoble's already gotten annoyed ...]

Tuesday, May 13, 2008

Digging into the sourcecode

One of the things that's really impressed me about the New Microsoft is that they're much more open about their sourcecode, especially the Visual Studio guys (who know their main customer base are all over issues like this).

It is even more impressive to see Scott Hanselman digging into their sourcecode for the latest VS2008 and .NET 3.5 SP1 Beta and using NDepend to show us how much has changed. In my books that absolutely rocks!

It actually makes me wonder whether this sort of analysis should form part of Elcom's sprint delivery procedures. In other words that we actually make the effort to stand back and analyse the sourcecode changes from 20,000 feet, rather than only looking at backlog items completed.

[UPDATE: Patrick Smacchia the NDepend lead developer (and C# MVP) takes the analysis one level deeper, again using NDepend.]

Friday, May 02, 2008

LinkedIn's cute outage page

This is a nice touch from LinkedIn, an outage page with attitude:


Of course I would have preferred they not have an outage at all ...