A rant

I have tried hard not to fill this blog with random off-topic rants. I am about to break that rule. If you do not wish to read my rant, please move on - normal service will be resumed shortly.

There is some (tenuous) relevancy about this rant. I will mention user interfaces!

My rant is about iPod's. No no, sorry, its about iPod users and iPod headphones.

I use an iPod. I use it because it was given to me and is 8Gb whereas my MP3 player of choice (a Creative Zen Stone Plus) is only 4Gb. It is a 3rd gen nano and is truly wondrous to hold and behold. I find the sound quality lacking in comparison to the two Creative players I have had, but it serves my needs adequately.

I am not such a fan of using the iPod. I often find myself getting frustrated at the imprecise and slow controls - I just want to move to a position within a track and change volume without waiting for the interface to allow me!

Anyway, I was sitting on the train this morning - not listening to my iPod - and the woman sitting next to me was listening to hers with the rather poor, but iconic iPod headphones.

She felt she had to have the volume turned to maximum just to be able to hear her music through those rubbish and very leaky headphones! This resulted in the whole carriage "enjoying" her music along with her. And I got the brunt of it.

In short - if you have an iPod, buy some decent headphones!

</rant>

Browser wars

To finish up this little series of posts about browser standards, I wanted to refer to the browser wars and ask this simple question:

Do we need another browser war?

Well? What do you think?

I think we cannot have another browser war in quite the same way. When it was Netscape vs Internet Explorer, every user spoke (or perhaps didn't speak) and chose (or perhaps was simply given) Internet Explorer. What then happened is that all the proprietary features of IE could be safely used whilst knowing there was a very high support rate.

Since IE6 came out and the browser war ended, there was a little stagnation but really what happened was that people got a bit bored and wanted more. So Firefox came along as a viable competitor. That was the time to have a browser war. The moment has passed.

Right now there is too much competition (or maybe none - its hard to tell) between the browser vendors. The market is too segmented. We now need the vendors to follow a standard spec. And so we get into the sordid world of the W3C and standards.

Standards?

Yesterday, I posted about some of my thoughts on web standards. It raised some questions for me. It was a post I was reluctant to make but only because I could not reasonably say in one post how I feel and what I think about the current state of affairs. I don't want this blog to descend into a series of rants about the W3C and standards etc etc.

I will attempt now to clarify my thoughts on where we should go from here.

Firstly, I think we do need to make progress. We need to move things forwards. We cannot stagnate. We must find ways to innovate. However, I don't think we have even scratched the surface of what is commercially possible and viable given today's technology. The browser has proven itself to be a remarkable platform capable of producing almost any sort of UI.

So here are some thoughts for each proposed standard:

1. HTML 5
   I am unconvinced by large parts of the spec and I think it is far too large a specification. I want to see greater interoperability between the various browsers and as such I believe simplification would be better. I also strongly believe that the next spec should enforce an XML type syntax. Its easier to maintain and easier to find errors. I would encourage the browser vendors to simplify their parsing engines, not force them into more complicated solutions.
   


2. CSS 3
   The power of CSS is in its expressive simplicity. This will not be lost within CSS 3, but do we really need much more on top of CSS 2.1? Do we need to have 4 rendering engines in wide use which are trying to implement a load of new CSS properties that will not be widely used? Are we not better off getting the current specs properly implemented with perhaps a few additions (multiple background images comes to mind) which can be progressively applied using the principles of progressive enhancement?
   


3. JavaScript 2
   I do not think JavaScript should gain classes and I do not think the language should be greatly extended. Interfaces may be a useful addition, but generally I just think a little tidying is needed. Its in the DOM that work is required. Lets get the DOM objects of the various browsers to be more closely aligned with each other.
   

What I am generally advocating is a simplification of the specs to make them manageable for browser vendors. Lets give the browser vendors an easier task to get themselves up to scratch and then lets ask them to add new features. As always these new features should be able to be applied using the principles of progressive enhancement.

The savior for us all could be JavaScript libraries. They transcend the browser differences hiding them conveniently. Of course that creates a level of ignorance about those issues amongst some, but they are undeniably popular and successful.

But the world of JavaScript libraries is amazingly similar to the early world of the browser. They all do basically the same things but in quite different ways. Some libraries do some things well, others do other things well. Funnily enough, libraries need to converge on something of a unified API. Just like the browsers.

So for the foreseeable future, the web developer will continue to bridge the gap with ingenuity, cunning, blood, sweat and tears. Its OK for me, but will it still be OK in 10 years time? Will we still be in the same situation in 10 years time? Sadly, I think yes. Does this dull my passion for my job? Absolutely not! I enjoy dealing with these vagaries and having to think on my feet every day!

Surely though, we can sort this out, one way or another...

Standard nonsense

My thoughts on web standards change on an almost weekly basis. I now consider myself a sceptical evangelist! I believe in web standards as an end but I do not agree with the means by which we seem to be getting there. I think we should be using web standards, but I live and work in the real world where web standards remain nothing more than a laudable goal and an occasional convenient excuse.

Currently, we have HTML 5 and CSS 3 and JavaScript 2 as the shining examples of where we are heading with web standards. I am aware that JavaScript 2 is no more (the end of a great folly in my opinion), however, these three serve to demonstrate my point.

The vast majority of users on the web, and surely its the users who are most important - not us developers, are using Internet Explorer as their primary web browser. IE is a fine product for browsing the web today and I suspect it fulfills the needs of those users in the vast majority of cases.

A good proportion of users are using Firefox with many using Firefox 3. This too is a fine browser. As is Safari which dominates the remaining small proportion of users.

At this point, others may launch into a diatribe about how users should switch browsers. Some may wish to analyse the statistics on a deeper level. But I wish to just re-iterate that for users, their current browser works fine! Why are we - the developers - getting so upset about users not changing their browser?

HTML 5, CSS 3 and JavaScript 2 are (or were) all meant to be innovations and additions to the interface developers toolkit, allowing us to do exciting new and innovative things. Creating new types of web pages, allowing the user to interact in new and exciting ways. Hmm. Writing that makes me think of AJAX. AJAX was meant to be an innovation and an addition to the interface developers toolkit allowing us to do exciting new and innovative things. AJAX was meant to allow us to create new types of web pages, allowing the user to interact in new and exciting ways.

Why did it work with AJAX? Its because support was already in the users browser. When AJAX started to become popular, there were some older browsers in use almost as much as Firefox 2 is in use today. Well, those older browsers disappeared as users could not access the websites that used advanced AJAX techniques. The other very helpful factor for AJAX was that computers became very cheap and very powerful and so users were upgrading more easily and more frequently. Most users only change browser when they change computer.

I believe there are the following 3 main reasons that HTML 5 and CSS 3 are not in common use today and will not be for at least 5 years from now:

1. The W3C
   A large slow moving organisation that seemingly cannot decide in which direction to lumber. There has been some progress over the last year, but they have absolutely set the pace. The gap between HTML 4 and HTML 5 being proper standards will be mirrored by the gap between users using browsers which implement those standards.
   


2. The browser vendors
   More slow moving organisations. The era of co-operation never began and never will be. There seems to be more effort being made to improve the performance of existing browser features rather than in implementing anything new. This in itself is a positive, but it does not really move the game forwards. This is the vendors playing catch-up so the websites we already build can run in a more reasonable fashion.
   
   There appears to be so little real competition in this market that vendor specific features are becoming acceptable again within the web development community. As developers we just want something shiny and new to play with!
   


3. The Users
   The only group that should really matter. Users have not been given any real incentive to change browsers or to support those vendors attempting to implement and push forwards new standards. Users will only shift their position on this in response to catastrophic security issues or a family member who knows better and has a convincing voice.
   
   Users still use older browsers such as IE 6 and Firefox 2 because there is nothing that the newer browsers offer which is compelling enough to make the change. Users are not technically savvy and nor should they have to be. Users only demand reliability, usable performance and security - even IE 6 can provide that.
   

Ultimately, there is no business case for building a website implementing new standards. Indeed, the opposite is true - it is better for businesses to ensure their websites work on the widest cross-section of browsers out there which means implementing old standards.

So is this all a cause for depression? Absolutely not. Do we need new standards? Not really! Wow, that was a controversial statement. I would like new and more appropriate standards, I would like those standards to be adhered to so I don't have to deal with cross browser issues. But, I am still doing really exciting and innovative work, I still find new bugs and issues with the browsers and I am yet to see a design or specification for a website which I could not build with today's existing technologies.

The Quiet

Its been pretty quiet on this blog for the last 6 weeks or so. I have been very busy working on an interesting, fairly complex and fairly large JavaScript application during the day and then recovering from it at night! I also had the pleasure of a lovely week away in this period of quiet.

I have also recently got my hands on a rather sexy new phone - an HTC Touch Diamond - and have spent a lot of time playing with that. Its a Windows Mobile PocketPC and its been an interesting experience, particularly Opera 9.5 Mobile which is the default browser.

Browsing on a handheld device has been a new experience for me. My phone comes with Pocket IE installed as well, but that is rather archaic. I have done all I can to avoid using it.

Opera Mobile however is a fantastic browser. Its fairly fast, pretty standards compliant and renders most pages rather well. It has also given me a useful insight into a different type of user agent for browsing the web. Its quite a different experience and its easy to see which sites are well designed and which are not.

I have taken away a couple of important lessons from my experience. Firstly, clear interface design is very important on this type of device. The browser can zoom into pages but when a page loads, it is zoomed out and most text cannot be read clearly at all. However, a site with good design is very usable as I can zoom in on just the right area. Clearly defined navigation really helps with browsing on a mobile device.

The second lesson I have learnt is that the easiest sites to use employ a liquid or semi-liquid layout. My phone has a resolution of 480x640 and if a site can flow its content to fit into either of those widths, that helps greatly. If I were designing a website today, I would definitely ensure it works in a browser width of 640 pixels!

The final lesson I have taken with me thus far is that the size of elements on screen really matters. I use my finger to navigate a website and having links tightly packed together with a small font size makes life very difficult. Having small form fields or form fields with a small font size and another link right next to or just underneath the form field can make it difficult to select the element I want to interact with. Finally, having heavily styled buttons, especially image buttons makes submitting a form harder than it needs to be, particularly if pressing enter on the keyboard does not work.

For me, the most noteworthy new aspect of interface development that I will carry with me is the importance of keyboard interaction with a form - never ever stop a form being submitted with the enter key!

There is much more to say about this phone and browsing the web using Opera, but at least for now, the quiet is no more!

Another JavaScript pattern - private members shared between object instances

In this post, I will introduce another pattern to add to my previous post about my JavaScript patterns. In fact, this is an extension to those patterns and combines both patterns together! This is a singleton pattern that creates a constructor!

In this post I will also make use of some aspects of JSquared, so please refer to the JSquared website for more information on those.

So, private members shared between object instances. What does that mean? What it means is that I want to have some private variables and functions which are accessible to multiple instances of a constructor but without them being part of the constructor or the objects the constructor will create. A fairly well known way of achieving this is by making the prototype of my constructor an object built using something similar to my singleton pattern. This would allow public and private members on the prototype of my object. But that will not give me all I wish to achieve this time and it can be a clumsy syntax.

The code I will use to help explain this concept is designed to be a simple panel object. The object will manage a series of panels on a webpage which are linked. Only one panel can be open at a time. Typically one would construct this with a singleton object which finds all instances of the panels in the DOM and adds some handling to each DOM node accordingly. I will do this in a different way. This code example is of course merely a skeleton.

var Panel = new (function() {

 

    //add a DOM load event

    addLoadEvent( function() {

        //get all DIV elements with a class of "panel"

        document.getElementsByClassName( {cssClass: "panel", tags: "div", callback: function() {

            //create a new instance of the Panel constructor for each panel

            new Panel(this);

        } } );

    } );

 

    var panels = [];

 

    function closeAll() {

        for (var i = panels.length-1; i>=0; i--) {

            panels[i].close();

        }

    }

 

    //return the Panel constructor

    return function(panelNode) {

        this.open = function() {

            closeAll();

            //perform the open logic

        }

        this.close = function() {

            //perform the close logic

        }

        //add this instance to the all instances array inside the closure

        panels.push(this);

    }

});

Lets step through each part of this example and see what it does:

var Panel = new (function() {

Create a new variable called Panel using the singleton pattern.

    //add a DOM load event

    addLoadEvent( function() {

        //get all DIV elements with a class of "panel"

        document.getElementsByClassName( {cssClass: "panel", tags: "div", callback: function() {

            //create a new instance of the Panel constructor for each panel

            new Panel(this);

        } } );

    } );

Using JSquared methods add an event handler for when the documents loads. The handler will use another JSquared method to find all elements in the document which are DIVs with a class of panel and for each one run the supplied function which will create a new instance of Panel passing in the DIV node with the class panel that was found. (see the JSquared docs for more info on how getElementsByClassName is used)

    var panels = [];

 

    function closeAll() {

        for (var i = panels.length-1; i>=0; i--) {

            panels[i].close();

        }

    }

These are the private members which each instance of Panel will have access to. We have an array of panels which will get filled with each instance of Panel that is created and we have a closeAll method that loops through each instance of Panel and calls its close method.

    //return the Panel constructor

    return function(panelNode) {

We are going to return a constructor (using the standard constructor pattern). The variable Panel that we created at the top of the code example will now take the value of this constructor. In other words, Panel becomes a constructor which we can create instances of using the new keyword.

        this.open = function() {

            closeAll();

            //perform the open logic

        }

        this.close = function() {

            //perform the close logic

        }

Create open and close methods which will perform those actions. In the open method, we first want to close all the panels ensuring only one can be open at any time. To do that we call the private closeAll method which is available through the closure around Panel.

        //add this instance to the all instances array inside the closure

        panels.push(this);

Add this new instance (this line of code is still part of the Panel constructor) to the private panels array also available through the closure we have created.


To recap, we use the singleton pattern to execute some logic before returning a constructor which is then available to us later on in the page execution. We can use the closure this creates to make private members, declared inside the self executing function which is the singleton pattern. These private members are available to each instance of the constructor but the members are not available anywhere else within any JavaScript - as is usual for a closure of this type.

This can be a very powerful and useful pattern. When building a large application, I believe it is good to keep public members of all objects to a minimum and I also prefer not to use the prototype of an object unless I am using inheritance. This pattern achieves both of these aims in an elegant and encapsulated way.

Google Chrome

So, its finally happened. Google's next step towards world domination is here, and its a web browser! Its also pretty clever. Indeed, I am writing this post in the new browser.

Its called Google Chrome. The Google Chrome chrome is extremely minimal and I like it. The tabs have certainly taken center stage and got a nice feel to it. It is extremely fast to use and the JavaScript engine appears to be fast and well, I am impressed!

Its well worth a download and a play, and dont forget the developer tools - yes, they are included in the browser.

I wont go into any technical details as Google have done a good (if somewhat unusual) job of explaining things. Check out the website for more information.

My favourite feature so far is the way the browser remembers searches you perform on other sites and makes it so easy for new searches to be performed.

If this is how Google are approaching their application development - and lets face it, no-one expected anything different - then I have high hopes for Android. On that subject, I have recently become the proud owner of an HTC Touch Diamond which is a Windows Mobile phone and I am keeping my fingers crossed that Chrome Mobile is coming soon!

As an aside, being a Webkit based browser, I was hoping that JSquared would "just work". However, I will be doing some testing and you can expect another report soon, especially given the new JavaScript engine.