Personally, the ones I’ve fallen victim to most recently are shortcut notations. Having a Java background, I always wanted to create new Objects and Arrays using the “new” keyword and constructing. During the writing of Getting Started with Dojo, Peter Higgins (the technical reviewer) pounded in my head that today, objects are created like var foo = {} and arrays are created like var bar = []. Christian discusses this in the article (and a bit more in detail).

Using JSON as a data format is another one I can strongly relate to, especially with his mention of using arrays and delimited strings in the past. Today, there will not be a project that goes by where I need data brought in and I will always choose JSON if it’s available due to its native support in modern day JavaScript.

I personally am always looking for ways to make my JavaScript run faster. As developers, we so often get caught up in the moment of getting something to work and simply implement a solution in a way that just came natural and was easy, we don’t go back to see if we can make it more efficient—especially in terms of browser memory usage. There have been many times I’ve seen a simple for loop accessing data in a way that is calling another method to fetch the data, instead of caching the data once and accessing the local cache. Christian brought up another way to make your page more efficient in terms of events that I had not thought of. His example perfectly illustrates a situation in which you want to listen for the click event on a set of list items inside an unordered list. Instead of looping through each list item and adding an event handler, you can simply add an event handler to the parent of this list (the ul). From here you can determine which li was clicked. This assuming that you understand that events in the DOM roll up from the bottom when an event occurs. This means that if you click an li,if that click is not handled on the li, it will roll up to the ul and so forth.

Finally the last few points on anonymous functions with the module pattern, configuration, interacting with the back end, and browser specific code, I cannot stress enough to read and understand these the best you can. These four points that he clearly makes are utterly important in ensuring you are an efficient JavaScript developer. This will set you apart from being a good JavaScript dev, to an excellent JavaScript dev—proving you know how the language works and how to best control it and use it as it should be used.

I highly respect Christian’s articles and his advice and I recommend you head his comments where you see fit. You can read the full article on Smashing Magazine below:

http://bit.ly/amJ8sj

Some new form input types that we get are:

• search
• tel
• url
• email
• datetime, date, month, week, time, and datetime-local
• number
• range
• color

Along with that, some validation. But what browsers are supporting this new functionality? Check out the litmus tests here: http://cl.ly/4Bq

Update: See if your browser passes the HTML5 “Acid” test: http://html5test.com/

The problem is that it was meant for the business to be creating these tests, not the developers, however, it turns out that the developers were tasked with creating them instead which is a “maintenance burden”.

Shore now believes that automating the acceptance testing is not a good idea, summarized by the following two points:

1.       The real planned benefit of an automated acceptance tool, like Fit, was that the business folks (“customers”) would write executable examples themselves. History has shown that very rarely occurs. In a few cases testers do, but in the majority of cases these tests are written by the developers.

2.       These tests often become a real maintenance burden, as they are slow and brittle, and often hard to refactor. On this point, that end-to-end “integration tests” present a higher cost than they are worth, JB Rainsberger has a great series of articles explaining his rational why.

What do you think?

Full article on InfoQ: http://bit.ly/a2002q

With that, here is my comment to Brian’s response to this debate:

I agree with you, Brian, in that his post may have been partly about the aspect you allude to. However, I also feel there is a real frustration in what he is really expressing with OO and CF. I noticed this same type of demeanor with some folks over the years when I strongly worked with CF. I myself have a Java background and as such tried to make CF follow the patterns and paradigms in the way that Java did. At the same time, I also recognized where CF fell short and thus worked with CF in it’s capacity as opposed to trying to get it to fit into the same context that Java is in.

With that, I encouraged other folks who worked with me to learn the better structured concepts of OO and MVC patterns and using the right mix of frameworks, such as a MVC, ORM, and IOC framework. The problem is, if you don’t understand these concepts from a fundamental level from the beginning without ever mixing CF in, they can be very overwhelming and start to crush the positive attitude that a CFML programmer may have.

Much of the time I also felt that parts of the community were pushing the use of so many patterns it was ridiculous and I think this is the storm that perhaps Marc was feeling.

To reiterate, I do feel that what you mentioned could be an underlying tone and perhaps fueling of anger and frustration, but at the same time I know from other CFML developers that I used to work with, his feelings at that show on the surface are valid and understood.

I think that most of the expert CFML developers in the community know and understand the limitations of the technology. Keep in mind, however, limitations is defined by what the requirements of a project are. Projects’ requirements should be written around the technology being used. Perhaps ColdFusion doesn’t have limitations in the sense of the word when it comes to “industry standard patterns”. From it’s beginning, it has always defined it’s own set of patterns that work for the CFML workflow. Developer’s need to understand to not try to redefine something that doens’t need to be redefined. If they have different needs in a project that are strong enough to fully set the project’s scope outside the circle of ColdFusion, then they need to choose a different technology.

CF continues to have a strong closely-knit community, something I have always enjoyed about it. Embrace the community, but don’t forget that at the end of the day, it’s up to you how you want to program your applications. And yes patterns are good, but don’t overdo it. Allow yourself to focus on the tasks at hand as well as having good design at the same time. True, not EVERYTHING needs to be “OO”.

Finally, change rarely comes at the perfect time. As web developers, the past 5 years or so have been changing very rapidly with new languages, patterns, frameworks, libraries coming out every day it seems. Don’t focus on being up to date on every single one and figure out how you can use each of them in your next project. Pick and choose what you want to learn and learn it well. In a time such as now, stick with what you know cause you need to hold on for a little bit longer, there are some rough winds up ahead.

I’m serious when I say don’t redefine something that is not meant to be that in the first place. I always uphold innovation in it’s highest regards, but there is innovation and then there is redefinition. They are NOT the same thing, so stop!

• Uses multi-threaded processes to isolate page executions, allowing for better performance and quicker, more reliable memory freeing
• Built off the WebKit code base (used by Safari, Adobe AIR, Nokia, iPhone, Android mobile platform [Google’s mobile OS) due to its impressive speed
• Faster and rebuilt JavaScript virtual machine called V8 (Virtual machines provide safety and platform independence)
  • In V8, as execution goes on, objects that end up with the same properties will share the same hidden class
  • In Chrome, JavaScript is not interpreted, it is compiled to machine code for faster execution in the browser
  • Precise garbage collection
  • V8 is independent of the browser so other projects can use the engine
• Better URL bar interaction design
  • URL box (coined Omnibox) is a apart of each tab (rather than the browser window)
  • Omnibox not only handles urls, but also suggestions for searches, top visited pages, and popular pages you haven’t visited
  • Full text search for your historical pages
  • Smarter URL completion
  • Searching sites like Amazon or Wikipedia, captures their search boxes on your local system, allowing you to search those sites later on straight from your URL bar
• New “home page” when opening a new tab displaying your nine most visited pages and the sites you search on
• Incognito window for private browsing
• Pop-ups are scoped to the tab they came from and confined there. If you do want a popup to occur, just drag out a graphical area to open it’s own window
• Webapps can launch their own browser window with a minified chrome without the URL box and the browser toolbar
• Sandboxing to keep page processes from being able to write files to your hard drive or read files from sensitive areas on your computer
  • User must initiate actions requested to run by the browser
  • With one exception, plugins, can run at higher levels than the browser itself.
• Plugins are now run in their own process
  • The rest of the page can still be sandboxed
• Chrome continually downloads lists of harmful sites, one for phishing, one for malware, presenting the user a warning if they stumble upon either
  • If a user visits a site with malware, Google notifies the owner of a website to let them know so they can clean up their site
• Google Gears is built in
• Completely open source

Designing Web Navigation: Optimizing the User Experience helps you lay the ground work to achieve a great user interaction experience. This full-color O’Reilly book clearly explains the full process of designing web navigation in three parts: Foundations of Web Navigation, A Framework for Navigation Design, and Navigation in Special Contexts.

In Foundations, the author writes an adequate analysis of various types of navigation systems, such as the search model, browse model, or the liquid information model to name only a few. He describes why poor navigation design will turn away users and may actually decrease the credibility of your website. Furthermore he touches on topics such as banner blindness where your users may not truly notice intentional site navigation, simply because back in their minds it looks like a vertical advertisement banner.

In Framework, Kalbach evaluates different forms of navigation for different types of sites. He talks about the need to engage your users to help determine what style will work best for your target audience. Moreover, he discusses types of technologies that may be implemented such as back-end technologies and front-end technologies like CSS and JavaScript.

James Kalbach does an excellent job describing every facet of this complex and sometimes daunting process in a very detailed yet easy to comprehend fashion. He backs up all the research he has done with references as well as providing great additional reading and other resources. The full-color diagrams and case studies of existing navigations on real-world websites prove invaluable to the reader. One small complaint I have is that for a book on designing navigation, the page numbers are quite small and difficult to glance at when you are flipping through the book. Aside from this small glitch, as it were, this book is a must have in every web developer or designer’s library. Even if you consider yourself to be an expert at web page flow, you cannot go without learning a rule or two, and perhaps some great what not to dos in this book.

The test consists of varying amounts of CSS, JavaScript, HTML, and tests with PNG images. Browsers are ranked on a point score based on how each one graphically renders the different use cases.

The overall results for each browser are as follows:

• Firefox 2.0.0.12: 50%
• Firefox 3.0b3: 61%
• Opera 9.26: 46%
• Safari 3.0.4: 39%
• WebKit Nightly: 87%

Run the Acid3 test for yourself

Acid3: Putting Browser Makers on Notice, Again. [The Web Standards Project]
Acid 3 Ships; WebKit praised [Ajaxian]

The experience was less than exciting and I didn’t see a huge benefit of it at the time in the manner that it was implemented.

Since then, I have come a cross a few sites that I actually use that have added OpenID integration. Only one of those have I actually linked my OpenID account: Plaxo. As for the others, I just didn’t care enough to do so.

As of recent, I have noticed a few large big adopters to the OpenID standard, namely, Yahoo!. With a large brand name like Yahoo! supporting the OpenID standard, I can see the benefit of other sites using it as a means of providing users account access to their sites. Yahoo! enabled all 248 million registered users with OpenID accounts; that is a huge user base! Curious, I used Plaxo as a test case for logging in with my Yahoo! OpenID. The process is great, simply click the “Sign-in with Yahoo! ID” button and it redirects you to a Yahoo! OpenID page informing you the website that is attempting to access your account and some other details. From there, you simply click “Let me In” which will prompt Yahoo! to send Plaxo your unique OpenID URL. This is the step that is better than using a service like myopenid.com. With Yahoo! being an OpenID provider, you simply use your Yahoo! Id when accessing OpenID services and Yahoo! will deal with the actual sending of the unique OpenID URL to the requesting service. Now that my Yahoo! OpenID account is associated, anytime I go back to Plaxo, I click sign in with Yahoo! ID, it does a quick redirect, as mentioned above, to Yahoo! and then I click “Let Me In” and I am immediately logged in (provided that I am already logged in with Yahoo!, you get directed to a Yahoo! login page if you are not already logged in). The benefit here, is that the only username and password you need to remember, is your Yahoo! one. That’s it.

Another thing that should encourage developers to look into this and give OpenID a try, is the amount of resources to help in implementation and use:

• Yahoo! OpenID
• A Recipe for OpenID-Enabling Your Site
• Yahoo! Gallery of OpenID sites
• OpenID for non-SuperUsers
• OpenID Code Libraries
• Popular OpenID provider (you don’t need this if you go the Yahoo! route)

Overall, now that I have seen where the OpenID standard is today and with some large adopters like Yahoo! and Plaxo on-board, I think I will take another look at this attempt to unify the web and provide people with the ultimate single sign-on method. Standards like this are very difficult to get into the mainstream. I was weary of OpenID taking off with it’s initial push, but today when I saw how Yahoo! did it, I felt much better about OpenIDs continuing success. Even so, if an average user is prompted on a registration screen to either register with the site or use their “OpenID account”, they will probably use the site’s registration for lack of knowledge of the benefits of OpenID. One way that developer’s can push this revolution in a more specific direction is to only allow access via an OpenID account. Assume users are stupid and only give them one option to sign-in to your site.

I would love to hear your comments, opinions, and constructive criticism on this topic. I think it is very relevant today and is the right time to introduce such a standard. Also, if you have other resources to share, please do so in the comments or send me a message.

As I was looking at the example sites that he posted, to my sheer surprise, mine was one of the examples. Looking at some of the others and reading his article inspired me to take the brown feel a step further. Yesterday I mocked the style that I wanted my site to have in my head. This morning, I went ahead and laid it out in Photoshop.

Last year when I redesigned my site, I made sure that I used proper CSS techniques so that if I ever did want to update the look of my site, I could do it easily. It only took me about 3 hours to do (which included the actual designing in Photoshop). I thought that was quite good! The actual implementation of the changes in the site maybe took about 45 minutes–which is about 30 minutes too long. This has to do with some things that I would have done differently to make it more effecient. No big deal.

I also designed the new look with in mind that I was going to keep a lot of the same elements. The navigation bar was NOT one of them however. Yet, once I placed the header on the page the navigation bar was just a little below the header this time (as opposed to being a part of the header as it was before), and I decided to keep it this way and tweak it a little.

Finally, everything else pretty much fell into place. I changed the colors a little of the text and links, but for the most part everything else is the same. It’s amazing how much just the background and the header of a page can change the look of the whole site.

HTML, XHTML, semantics and the future of the web