domReady version II

A domReady function handles DOMContentLoaded events in your browser. The DOMContentLoaded event allows you to add behavior or change the HTML of a page after the HTML has loaded and before the onload event which happens after the complete page, including images has loaded. This allows you to add menu, tree behavior, AJAX functionality or anything else without having to wait for all items on a page to load. You may have experienced the need for a DOMContentLoaded event on a page that includes drop down menus or a tabbed interface which doesn't work until all images have loaded. Using the DOMContentLoaded event allows you to add the behavior before images and objects have loaded, giving a better user experience. The domReady function is similiar to the jQuery ready method without requiring jQuery.

Back in 2005 I modified code from Dean Edwards that had been modified by Tino Zijdel and added a DOMContentLoaded event. This is what is commonly known today as a domReady event. In 2008 I created a separate domReady module using Object Literal Notation (OLN). With time, code styles and methodology change. Even though the code still worked, it was time to for an update. With about an hour of time, I modified the domReady code to use private functions, delete code for KTLM browsers, and clean up the code.

I changed the code to leave only the domReady global function. All other functions are private to domReady instead of the previous two global varibles. With the OLN object, all methods could be accessed globally, those methods are now private. The code needed to not create itself if the js file had been loaded multiple times and to reveal only the domReady function. Here's where I started.

// Create the domReady event handler once.
if(typeof domReady !== "function") {
    var domReady = (function() {
        // Array of domReady event handlers.
        var events = {}, domReadyID = 1, bDone = false;

        // Function that adds domReady listeners to the array.
        function add(handler) {

        // Function to process the domReady events array.
        function run() {

        function init() {

        return add;

Continue Reading "domReady version II..."

Do You Really Want to Install That App?

I read a rant by Jeff Atwood on websites that nag the reader to install their app every time the site is accessed. It doesn't matter if you've selected "No", these sites keep nagging you to download their app. The post is called App-pocalypse Now. It is very good and I suggest reading the post.

I run into this all the time when a website links to a website (usually a news site) that everytime asks me to download their app. It is frustrating. I just want to read the article and be on my way. I don't visit these sites often and don't see the point in downloading an app to view their content every six months or so and a link will always send me to the website not the native app, so what's the purpose of downloading their app? In the post Jeff writes:

Let's start with the basics. How do you know which apps you need? How do you get them installed? How do you keep them updated? How many apps can you reasonably keep track of on a phone? On a tablet? Just the home screen? A few screens? A dozen screens? When you have millions of apps out there, this rapidly becomes less of a "slap a few icons on the page" problem and more of a search problem like the greater web. My son's iPad has more than 10 pages of apps now, we don't even bother with the pretense of scrolling through pages of icons, we just go straight to search every time.

Which got me to thinking. Other than games, just what benefit does an native app give over a website? What value does a native app give that a website can't give the reader? Notifications can just as easily be replaced with an email message. If you download the LinkedIn app you get notifications and email notifications. Maybe an app is better formatted for a device, but websites should be responsive to the screen you're using.

I thought personally, why have I downloaded an app over a website and what apps do I use most. Facebook, though with the exception of notifications, I can't really think of anything that the app does that can't be done in a website. The twitter app has a great feature where it remembers the last tweet you read and returns you to that tweet in the list of tweets. That makes it much easier to read my twitter feed, but why couldn't twitter do that on their web page? Geolocation is supported, though badly I think on mobile devices which might be a reason to download an app such as Yelp. Most apps I've downloaded I don't even use.

My credit union app allows me to take a picture of a check and deposit the check wherever I am which is useful since my wife has several different employers, none of whom direct deposit her paycheck. The native app has an option to eDeposit that the website doesn't have.

mobile-ebanking-home-1-1.png mobile-ebanking-home-2-1.png

I don't know, but I believe the image of the check, for performance reasons, would have to have the program reduce the image's file size before sending it to the server. I did about two minutes of searching on Google and found HTML5 photo upload and tested it on my phone and it was able to reduce the file size of an image on my phone. I know the code is a jQuery plugin and jQuery might not be used on a mobile website, but I'm sure with a little more looking I could find code that will scale an image or rewrite the plugin so that it doesn't require jQuery. This is by no means an exhaustive test as I only tested the web application on my personal phone. This tells me that the eDeposit feature could be added to the website.

From a company's point of view, I would think that it would be less expensive to provide a mobile website solution instead of a native app. Look at the credit union app, with the exception of eDeposit, it is the same. Your app programmer would have to know iOS, object C, Android, Pascal, Firefox OS, and every mobile operating system's language of choice. Most likely this would not be one person, but multiple people. As a company, to what platforms do you provide an app, iOS, Android, Windows, Blackberry, …?

Now I'm beginning to think that the only reason for downloading an app is because the website hasn't been programmed with features in the app or been made responsive. What do you think?