We're hiring

At Gottabet we're looking for a 'web application designer' to join the team. The job entails a range of web dev, from helping design various sections/features of the website to implementing them in HTML and CSS.

There's a full job spec on the website, so if you're a developer who's big on web standards looking for an exciting, fast-paced job working on a big social website, check out the job spec and get in touch with Wim and Bertrand (email addresses on the linked page).

YSlow for Firebug

Just spotted (via Simon Willison's blog) that Yahoo! has released an extension for Firebug, called YSlow.

The extension adds more performance data to Firebug, grading various speed issues A-F like a school exam. It seems rather cool on a brief test, though one bit did immediately stand out as potentially bad advice: YSlow suggests you should move as much Javascript as possible to the bottom of your document (to stop it slowing down your page load times).

This is good advice looking purely from the angle of increasing page load times, but goes against the web standards approach of trying to keep JS out of your body code (the whole unobtrusive Javascript thing).

It's not a major thing to have JS include tags in the body of your document compared to actual inline JS, but it might have been nice to see a note somewhere providing the other angle to just speed.

Frames live?

As I mentioned in my previous post, at work we're moving a lot of clients to new hosting. Due to a very silly system at the old hosts, that means we have to transfer the domain names to a new registrar as well as they won't let us just point at another host's servers. We're using 123-Reg to transfer the domains to, and today I logged in to find a new site design.

It's quite a pleasant design, but what really got me is that it still uses frames. The layout is such that frames aren't even a natural thing to use. It looks like what's happened though, is that while their front-end site has been re-designed in nice tableless code with CSS to handle presentation as should be, the back-end domain management area isn't so easy to re-code/-style. So they stuck it in a frame.

I'm hoping that is the reason and that they're working on doing the management area properly, because if they've actually chosen to use frames on a fresh build, especially with the new layout they've used, it's madness. It does (hopefully) drive home the point about writing semantic, valid code though. If the original site was written semantically, they could just write a new stylesheet and have their new design implemented much more easily and quickly (aside from any actual content/functionality changes of course).

123-Reg have made a good step forward with their new site, the main 'sales' part being mostly valid HTML, with 'skip to content' links, etc. so they (or their designers) do seem aware of the need for standards-based coding, let's just hope the job gets finished :)

Seconded!

Philipp Lenssen just posted a nice short piece on how Google's homepage would stack up in filesize when written in XHTML Strict compared to its current invalid HTML, Google Strict vs. Google Deprecated.

I have to second what he says - any argument for keeping deprecated code based on filesize is quite silly. Valid XHTML (almost?) always reduces file size and both download and render times. Philipp's XHTML version comes in smaller than the current live Google version at 2.86k compared to 3.08k. Not a big difference, but multiple it a few million (billion?) times for all the traffic Google gets and it mounts up.

Where I think you'd see a much bigger difference is on the actual search result pages. With much more data (all in tables, which beef up code size quite a lot), the difference should be much more marked. Aside from that, I imagine that the results pages are seen much more often than the homepage. With more and more browsers having search bars alongside their address bars, people will increasingly not use the actual front page of search engines as they go from a small input box in the browser itself to the results page.
The results page would be harder to code in XHTML with CSS and still degrade properly in very old browsers (something Google has to think about more than most), but I'm sure it could be accomplished. Things are mad at work as we move a couple of hundred websites to a new server, but if I get the time and inspiration before someone else does, I might have a go at it as it's very interesting.

Disability Warehouse open for business

As part of my work at Net Effects, since Christmas last year I've been working on a new online shopping system wherever other client work allows. For a good few years, Net Effects have run an online shopping site called UK Shopability but when I joined the company last year they had already started getting a bit fed up with the old system.

The old Shopability suppliers stopped doing online mail order recently, having been bought out, so the decision was made to start a new site to re-launch the whole thing, working with the main distributor of disability products. And thus was born Disability Warehouse, an online shop for disability-related products.

We opened the site up to orders a couple of days ago and already a few have been coming through despite not advertising the site yet, so it's looking good.

The site uses AJAX in places (mainly for adding an item to your cart and admin functions), though this is a site aimed at users with disabilities so it degrades properly if JavaScript is turned off and just submits a form the old-fashioned way. Some bits of the site are still being fine-tuned (e.g. product images that are missing), but the site is ready to go which is why it's now open to sales without much fanfare - we'll get a low volume of real sales to start to make sure everything really does work (it does so far!) before we ramp up to inviting all the many customers over from the old Shopability site.

 1 2 Next →

About

User