@madpilot makes

New port80 event announced.

Port80 – the Australian Web Industry, of which I’m the membership officer has announced the next event – Ideas3.

The event features John Allsop from Sydney, who is a directory of Westciv, creators of Stylemaster; and Mark Boulton from the UK who is a noted typographer and designer who is currently working at the BBC.

For those of you who aren’t in Perth for the event on April 11, we will be posting the podcasts and photos after the event.

As an aside, the new Port80 site, which drives the event and memeber management systems was written by me in CakePHP.

Interested in starting a Port80 group in your local area? We are currently preparing an information pack. Port80 started as a way for web designers and developers in Perth could catch up in a casual, informal environment – usually at a pub. It is amazing how well it works – it’s a great way to meet other like minded people. You can read a better history on the Port80 website. Don’t forget to check out the port80 forums too!

Flogging a dead horse – technologies that don’t belong on the web

The web has come a long way since it’s inception. No longer is it a mismash of ugly looking static pages, posted by scientists. Ecommerce has gone nuts, allowing people to perform online banking and shopping. The advent of blogging has allowed anyone with a net connection to become an author and post their opinions on stuff. Web 2.0 social websites have brought the net back to the people – all in all a pretty exciting time.

However! There are some technologies that seem to be gaining steam because that is what everyone expected the web to do two years ago. The reason that these technologies will fail is because they are trying to force a paradigm where it doesn’t fit. This technique was fine a couple of years ago, but now that the web has started to find it’s feet, the incompatibility is becoming clearer.

One that immediately comes to mind is video-blogging (vblogs). Ever since people realised you could download a video off the net, on-demand video has been touted as the next big thing. Unfortunately, I don’t think it will happen. Why? It is an old medium. It is still one-way. You can’t interact with the video – you are forced to sit and watch and listen to the story. You can’t skim view it, nor can you do other stuff while watching it (You can almost get away with listening to it and doing something else, in which case, it would make more sense to listen to an audio podcast). Not to mention the speed issues – broadband still hasn’t gotten fast enough to really make it work. We young and part of the now generation – we don’t want to wait for for a video download only to find out it is crap.

Another is online newspapers. Sure, these have been around for a while but they have really missed the mark on the web. What is the point of setting up a newspaper to look and feel like it’s real-world counterpart? If I wanted to read my news like that, I would go and buy the paper. The way slashdot distributes it’s news is much closer to the mark. Give me tidbits from every story. That way I can make up my mind straight away if I want to continue reading. Trying to “flick” through a paper online in a traditional sense is too much effort.

What other technologies can you think that are being pushed, but don’t really belong?

Network issues yesterday

Apologies for those wanting to read my blog yesterday – my service provider managed to kill most of their users connection for about 12 hours :(

But I’m back online now which is the main thing…

Ruby, FastCGI and Virtualhosts

Now that that MadPilot Productions site is live, I wanted to run FastCGI. Even though the site is relatively low traffic, I was intrigued to see whether the speedup would be noticable. It is. Unfortunately, the literature I have seen hasn’t really made it clear how to set this up on a server that runs virtualhosts, so here is how it works.

To make a ruby on rails site run in production mode you need to add the following line to the apache.conf file:

FastCgiServer /path/to/site/public/dispatch.fcgi -initial-env RAILS_ENV=production -processes 15 -idle-timeout 60

However, putting this between VirtualHost tags fails. The solution is simple really – put it OUTSIDE the VirtualHost tag. You can have multiple entries in the config file. Since I split my virtual hosts into seperate files (ala Debian, even though I run a Gentoo server) I just drop it in bottom on the file below the closing VirtaulHost tag.

As an aside – Gentoo has a slight problem in that there may throw an error about User/Groups when starting. To fix, put the lines

User apache
Group apache

before the FastCgiIpcDir /tmp/fcgi_ipc directive in the [number]_mod_fastcgi.conf file that is located in /etc/apache/modules.d/ directory.

MadPilot is on Rails

The MadPilot Productions website now has a new look and a new scripting engine driving it – Ruby on Rails!

Leave your comments and tell me what you think :) 

Why web apps can get away with being in beta for a long time

An article was recently posted on the Wall Street Journal website entitled “WSJ.com – For Some Technology Companies, ‘Beta’ Becomes a Long-Term Label” which asked the question how can companies get away with leaving software in a “beta” state for so long. Google is notorious for doing it – Gmail has been around for at least two years and is still tagged as beta. In fact, many people are using Gmail as their primary email address. There are many real-world analogies as to why you wouldn’t do this in the article, so I won’t bother repeating them here.

It does bring up an interesting point though. How come web software can get away with, nay, thrive on, releasing beta software?

Traditionally, the main thrust of software was the underlying business logic. It has only been in recent times where user interfaces and user experience has become important. It is often impossible to know exactly how a user is going to react when they start to use an interface. Being in a constant state of beta allows designers to be constantly tweaking elements of the design. If things change drastically, users will put it down to the fact that the site is still in beta.

This is relevent when adding features. As a developer, you may find a new “must have” feature that you are sure that your web site requires. It is a more effective use of your time to build a version quickly, so that you can gauge it’s popularity, and then concentrate on making it robust if you know it is worth-your-while. You couldn’t get away with this without being in a beta state.

Obviously, this isn’t a mechanism for everyone. I would even think about using a security product that was in beta. But for web apps that aren’t doing anything mission critical then it should be fine.

Developing for Accessibility

Accessibility, as the name suggests is about making websites accessible to as many users as possible. Unfortunately, not everyone on the planet has 20/20 vision, or full use of their hands, which can make using traditional web sites difficult – why should they be disadvantaged by not being able to harness the plethora of information out in cyberspace? Even beyond that, there are many able-body web users that are using non-standard browsers and software to access websites. PDAs, mobile phones and hand held game machines (such as the Sony PSP) are examples of systems that have restricted screen sizes and memory footprints which makes packing a full blown web browser impossible. Another benefit of an accessible website is it makes the search engine robots’ job much easier.

Different ways of using the web

The web is no longer confined to the walls on universities, or geeky tech type people – 14 million people in Australia have access to the internet [Nielsen/NetRatings]. Even if you ignored 5% of that audience, that is potentially 700,000 people that cannot access your website. This is especially relevent to government websites who theoretically should be targeting everyone.

There is no way of guaranteeing that all of these users are using standard desktop setups either: some variations include:

  • Screen readers: These programs are used by sight-impaired users. They read in the HTML markup and read it out using a synthesised voice. These system tend not to understand JavaScript or Flash.
  • Braille readers: Again used by sight-imparied users. Very much like a screen reader, except they output the page in Braille
  • PDA/Mobile phone: very handy for those who are out on the road a lot. These usually have a reduced screen size, and limited memory. They also have different method of inputting data, so things like JavaScript menus will probably not work.
  • Slow internet connections: People out in the bush (Or even the suburbs) may not be able to get broadband, or reliable modem connections. So there may still be a number of people that try to reduce bandwith by switching off images.
  • Text-only browsers: Not really sure why you would still use these other than because you can – although, they can provide a good indication of what your site looks like to a search engine spider.

Accessibility and Standards

The basics of accessibility can be acheived by following the World Wide Web Consortium (W3C) standards documents. These standards are about creating semantic, structured layout that can easily be intepreted by any system that understands the standards. The standards break up the structure layer and the presentation layer, by usingl Cascading Style Sheets (CSS), which effectively gives the designer control over how an element looks without destroying the document structure. The names of HTML tags have been carefully selected to decribe document elements. Unfortunately, in the old days, many designers abused the default display properties of some elements, misusing them to present information in a certain style.

For example, an old trick to indent text would be to wrap it in tags. It is hard to image how a screen reader would handle this – it comes across some text it expects to be an un-ordered list, only to find a block of text. The correct way of doing this would be to wrap it intags, and use the CSS property padding-left to indent the whole block.

Before CSS, it was common to mix up the order of items in the HTML to fit the presentation of the page. This means that a user running a screen reader would have the contents read out in the wrong order… Not very usable at all.

Don’t rely on colour

Colour blindness is a condition that stops the sufferer for perceiving certain colours. This can create two potential problems for the web designer – foreground-background contrast and colour for notification. Any user with normal vision knows how hard it is to read dark blue text on a black background – because the contract between the two colours in not enough. However, there are certain colour combinations that would be fine for non-colour blind people, but would work for those that did have the deficiency.

To be continued… [I’ve to go to my exam now – this will be interesting]

Previous