One of the few web applications I was actually waiting eagerly for is FeedLounge, a new feed reader, which I thought may be a much better interface to use instead of my old trusty Bloglines. I’ve found Bloglines to be clunky, and not full enough of Web 2.0 goodness (read: AJAX) for me to be impressed each time I use it.
However, and this is a major problem, FeedLounge requires payment. I know these guys have a need for a wage, but $5 per month? Hmm, a bit too much, I think. Especially when there are plenty of free web-based feed readers out there.
I’m not against paying for web applications (after all, I paid for Mint just the other day), but there’s a very thin line to tread when it comes to charging for a website. Even a very nice looking website that does a lot.
Some companies get it right, realising that giving something away for free can actually be a good business idea. What 37 Signals have given away is a very limited online project management system – only one project can be managed for free. But that’s fine, it gives people a taster of what is to come.
Actually, as an aside, I would prefer to have been able to manage 2 or 3 projects for free in Basecamp, that way I could have seen how multiple projects are displayed and handled. Of course, my project management system will be better. But I would say that, wouldn’t I?
So, pricing. It’s a big problem, especially when you’re trying to sell services on to of something that is essentially free like RSS feeds. But I suppose there are people that will pay for these things. But, unfortunately for the FeedLounge crew, I’m not one of them.
I’ve mentioned Mint before, but it’s only now I’ve bought it for a domain I run that I realise what a supreme example of programming it is. It looks good, is easy to use, does the job fantastically, and is fully extendable. What more could we ask for?
Huge kudos is due to Shaun Inman, and the wonderful team of Pepper-writers (see here for more details).
There’s an interesting article here about validating user input, and the usability implications of doing so. It outlines several methods (I suppose they could be classed as patterns) of doing this and notifying – or not notifying – the user.
This was found through Harry Fuecks article on Sitepoint, where he says that there’s no real alternative to regular expressions. He’s right, of course, and over the last couple of years my use of regexp’s has increased so much that rarely does a day go by when I’m not messing about with them. However I’ll be referring to the list of “validation patterns” (as I’ll call them) as it provides a useful reminder of the different ways that user input can be handled.
Well, it’s finally arrived. The “Chocolate and Coffee” look is in this season, so I’m told…
Let me know what you think.
As previously mentioned, I needed a place where I could easily get all the information I need to make sites accessible. This is that place. Here I’ve linked to very useful, and in some cases definitive, website from some of the worlds greatest accessibility gurus so that I – and hopefully you – can get everything you need in one place.
I will treat this entry as being always open for editing.
Tables should be used for tabular data, not for layout. As Roger Johansson explains, there’s a lot more to accessible tables than just rows and cells.
Acronyms are very useful, and in increasing use – especially when talking about technology. How do you make sure that everyone knows what that string of letters means? Why, by scoring the A List Apart hat-trick, of course.
All web applications have forms – sometimes many of them. Forms can be really complex, but with the WebAIM accessible forms tutorial, you’ll be forming (geddit?) perfect forms in no time.