
For a long time, web design was handled by those with the necessary technical skills to build websites. It was often the same person doing both the front, and back end of a website. These are two very different skills and really, one should lead on to the other. The more you look at Web 2.0 services, it becomes obvious which ones have spent time, money and expertise on their interfaces, and those that have not. But of course the Web 2.0 isn’t all about the big sites, this applies as much to those going through Blog designs as anyone else. To emphasize the areas where you can succeed and fail in designing a Web 2.0 site, I’ve picked out a handfull of aspects that you need to consider, and what you should consider for each. So let’s get started.
Permalink Comments (2 Responses) TrackBack
I ran across this story earlier today and it completely shocked me. It would appear the the huge amount of diggs
received by the iPhone story (which now appears to have been dugg down) couldn’t be handled by certain aspects of digg’s UI. The reason this shocked me was that the problems started to come at 10,000 diggs. Now to me, considering the large numbers of users digg has, thats not a huge amount. Of course this little issue was fixed fairly quickly but it begs the question, if the UI has never been tested to this level, what about the stability of the rest of the digg platform?
We’ve seen that digg has the ability to easily bring down other sites, and we’ve also seen that digg itself and slow to a crawl on occasion, early last week being an example. But the question is not of the infrastructure, which can easily be expanded, but more of the software. The nature of digg means that users “swarm” around certain articles, see the highly entertaining digg swarm tool for a great visual interpretation of this mass behaviour. This means its very difficult to perform accurate automated load testing on the scripts themselves. And, it seems obvious now that the digg team have not been able to test the site to the extent it is currently being used. Either in terms of numbers or usage patterns. It must be a scary time, so lets hope it all holds up. And lets all bear in mind that the uniqueness of sites like digg mean they fall out of the realm of standard testing practice, techniques that can be safely applied to other internet sites (i.e. content management systems, shopping sites etc.).
Permalink Comments (No Responses Yet) TrackBack
As someone who has a real ‘thing’ for usability I’m cosntantly astonished that AJAX is used to complicate and baffle users. As if the non-standard navigation on websites wasn’t enough we’ve now got these new behaviours that don’t follow HTML rules to consider as well. What we really need is to clean up the use of AJAX and make sure that when the word is mentioned as part of site development, its the designers and user interface specialists that suggest it, not the developers.
In fact, AJAX should only be used to solve a problem that can’t be solved with regular static pages. I would add a very loud caveat to that though, and that is a problem doesn’t necessary have to be a bad thing, but, more likely, is an internal design problem. We can apply this fairly simply to some popular Web 2 applications. How about gmail, what ‘problem’ did they solve by using AJAX? See after the jump…
Permalink Comments (No Responses Yet) TrackBack
AJAX is very much the new kid on the block, he’s smart, he’s popular and damn, all the ladies love him. A bit like the Fonz in some respects. One flash of that jacket (read: no refresh forms with fancy effects) and everyone is swooning. The problem with AJAX, much like the Fonz, is that its all too easy to overlook the flaws.
So what exactly are the problems with the Fonz? Well for starters, he was awfully promiscuous, so inevitibly, for the time, was a carrier of multiple STDs, then theres the hair, surely a fire hazard if ever I saw one. Wait, I’ve expanded on the wrong point there (eyyyyyy etc.). So what are the problems with Ajax, and just whats going on in the world of Flash (would Flash be Tom Bosley possibly?). Read on…
Permalink Comments (No Responses Yet) TrackBack
I’ve just embarked on a new project and I thought it was time to update the tools I use, just to streamline things a bit and make sure development is as easy as it could be.
First up is the editor. As a recent Mac convert I needed something to take the place of Notepad++, my Windows editor of choice. Well that was fairly easy, I had a look round and kept coming across Text Wrangler, BBedit’s little brother, and its fantastic. In fact it easily surpasses the usability ot Notepad++. Could I find a replacement for my favourite FTP client, SmartFTP as well? Again its a resounding yes! Initially I started using Transmit, the award winning Mac FTP client, and yes, I can see why its award winning. In fact it’s as easy to use as finder and shares much of the functionality. Eventually though (read 30 days trial ran out) I moved over to Cyberduck ftp which actually comes close to matching the functionality of Transmit, and only falls slightly short in terms of stability and usability. But its free and unlimited, which suits the tightwad in me. There is also the integration with Text Wrangler, which means that if you open a file in Text Wrangler, through Cyberduck, saving the file will save it on the server, which really streamlines the ediitng process. Text Wrangler itself offers saving over FTP but you will always need a fully featured FTP client at some point.
The next items I added to my toolbelt were FireFox extensions. I already had the Web Developer Toolbar, which, if you don’t use it, is simply astonishing. It just makes everything you could ever want to do so simple. I simply could not live without it. Iw as dissapointed to learn that the eyedropper mode of color zilla does not work on Mac, which means I’ve had to drop that from my toolbelt, which is unfortunate as it was really usefull. I thought it would be worth seeing what else was out there, and boy am I glad I did.
The first extension I came across is called Fangs. Fangs does a great job of visually interpreting the output of screen readers. This is a must have if you care about accessibility, of course to be used in conjunction with this article on accessibility. Next I came across an extension called View Source Chart, which visually formats source code by grouping block elements and their children together and highlighting them in colour. It may sound fairly trivial but it really helps you find errors quickly. You simply would not believe how much of a difference using this entension, in conjunction with the highlight block level elements feature of the Web Developer Toolbar, makes debugging your HTML. Especially if you use dynamically generated code from a CMS, Forum of Blog.
In addition to these tools, I use the Gimp for images, Safari for testing and IE on a seperate Windows Machine for testing. I also tend to use the superb script.aculo.us scripting library and a set of key PHP classes that I wrote a good while ago and have been serving me well. Theres also a whole host of bookmarks that I’ve got that help me out with colour schemes and commonly used layout techniques, including my own.
Whats your development environment like? Any tips for a recent Mac convert? What can’t you do without? One thing I will say, however, is that I simply cannot get a working PHP/MySQL/Apache environment working on my machine, and I’ve tried everything. Anyone with a familiar experience?
Permalink Comments (3 Responses) TrackBack