Oct 17 2010

JavaScript innerHTML v. outerHTML / DOM Engine Epic Fails

I was messing around with  javascript today and I recognized one major issue when updating the innerHTML of an object versus the outerHTML.  Namely, that objects updated with HTML content via outerHTML do not allow subsequent access to interior objects within that HTML content.  The DOM engine (at least in Firefox) will not recognize the interior elements when outerHTML is used, but WILL if innerHTML is used.

The Scenario

Suppose you have just created a div object dynamically in javascript.  In other words, you’ve created a div object in code versus its existence in the actual HTML document.  For example, this code:

var o = document.createElement(“div”);

Would create this type of HTML:

<div></div>

Next, imagine that you have a string of HTML that you would like to make up this <div> element.  For the sake of argument, pretend you have a variable ‘html’ and this contains the HTML you would like to make up everything of your new dynamically created <div> object including the tag itself:

var html = “<div id=’mydiv’ a=’1′ b=’2′><img src=’foo.jpg border=’0′ width=’5′ height=’5′ /></div>”;

At this point one may be tempted to make a call such as this:

o.innerHTML = html; // do not actually do this

This would be wrong to do, however, since that would result in the following HTML being created for o:

<div><div id=’mydiv’ a=’1′ b=’2′><img id=’myimg’ src=’foo.jpg border=’0′ width=’5′ height=’5′ /></div></div>

The better option (at least logically) would be to update the outerHTML of o which is supposed to replace the entire HTML contents of o including the tag itself:

o.outerHTML = html; // this should work… but

This does actually work, and and the DOM engine actually updates the entire o object with the appropriate content.  If that’s all you need, then you’re set.

But, there is a problem if you need to do more… If you need to access your <img> object programmatically a few lines after you’ve created o (note the <img> object is now  part of the <div>’s content) then you’re shit out of luck.  Any attempts to do the following will return a null object:

var i = document.getElementById(“myimg”);  // if you’ve used outerHTML the DOM engine won’t know ‘myimg’ exists yet

If you try to do this, after using outerHTML, the DOM engine will not recognize ‘myimg’ as having been created yet.  The DOM engine WILL, however, recognize ‘myimg’ as having been created if you use innerHTML!  So what gives!?

Whatever the problem is, my solution was to create my <div> object programmatically, have my HTML content just be the <img> tag itself, and then to update the innerHTML as the image.  THEN you need to programmatically update the attributes of the <div> object.  It’s a pain, I know, especially if you’ve streamed HTML content from an AJAX call, etc.  Anyway, a final solution would be something like this:

var html = “<img src=’foo.jpg border=’0′ width=’5′ height=’5′ />”;
var o = document.createElement(“div”);
o.innerHTML = html;
o.setAttribute(“a”, “1″);
o.setAttribute(“b”, “2″);
o.id = “mydiv”;
document.getElementById(“myimg”).src=”bar.jpg”;

I spent a good two hours dissecting the innards of Firefox’s DOM and just came up with, “Why?”  Anyway, I hope this helps people.


Jun 15 2010

HTML5 Geolocation on iPhone

The iPhone’s latest version of Safari supports HTML5 Geolocation Services.  To the average mobile phone user this might not seem like a big deal, but for web developers it’s huge.

In the past, web developers who needed to get latitude/longitude coordinates in Javascript were required to make server-side AJAX calls and base coordinates off of IP addresses and shaky algorithms.  The process was time-consuming (even using asynchronous calls) and burdensome to the server.  If constant updates were required, an ill-equipped server would overload.  Simply put, web browsers lacked the ability to support  robust real-time geolocation updates.

HTML5, the newest standards outlined by W3C, sought to change that with Geolocation Services.  Now, major website browsers (such as Safari and Firefox) come with the ability to retrieve latitude and longitude coordinates within Javascript as an integrated part of the browser itself.  This means that a programmer can now ask an HTML5 enabled browser to return coordinates without ever making an AJAX call.  The process follows this pattern: programmer makes request to the browser, browser pings its geolocation service provider, the geolocation service provider responds to the browser, the browser updates its Javascript coords object with the relevant information including latitude and longitude for the programmer to then work with.  The speed is incredibly fast compared to the old method, and is also incredibly accurate down to a few 100 meters.

Even more important, the programmer can register a callback function to constantly be executed asynchronously with updated positions.  This allows a lot of exciting things to be done.  For instance, I developed a very basic speedometer website (calculating MPH) at http://www.geigel.com/html5/speed.php that can be used on my iPhone.  To test this, open your mobile Safari browser to the website URL and then start driving down the road in your car.  Although the updated speed appearing on the website is not as precise or responsive as the MPH the car shows, the experiment illustrates what is now possible using HTML5.

What I find interesting beyond the mere technical/programming doors that HTML5 has opened is the behind-the-scenes battle from search-engine companies to be the exclusive provider of geolocation data for the major browsers.  After all, geolocation data doesn’t just magically come into existence simply because HTML5 says it should.  A company needs to process a request from the browser and respond quickly.  Obviously, Internet Explorer will rely on Microsoft as its sole provider of information (when, and if, IE decides to support geolocation).  Similarly, Chrome will use Google, however it is unclear if a Gears plugin will be required versus being natively built into the browser.  The real competition occurs when you begin looking at who will supply information for Firefox and Opera.  At present, Firefox relies on Google (http://www.mozilla.com/en-US/firefox/geolocation/).  Opera, on the other hand, seems to currently be going with a third-party geolocation service provider named Skyhook (http://labs.opera.com/news/2009/03/26/).  Whether these browsers will stick with these providers remains to be seen.

Whatever all of this means for the future of websites, the W3C, and major players is unclear.  What is clear is that users of the technology are going to experience a richer  browsing session with location aware websites.  Equally clear is that geolocation providers will gain significant amounts of anonymous technical data about user positions, trends, etc. which can be scary for privacy-minded individuals.  Thankfully, the W3C cared enough to require in their specification that browsers should warn users when their position is being tracked, and ask that these services be activated.


Jan 27 2010

5 Things iPhone OS 4.0 Needs to Include

1. App Groups

Initially, several screens filled with colorful app icons was fun.  Flicking around from left to right was just part of the experience.  Eventually, most users began to wonder if there wasn’t a better way to categorize their apps rather than just having them float around in random positions.  And if you wanted to make any sense of your screens by systematically positioning your apps; you were met with an never ending time-consuming process as soon as you added a new app.  Amazingly, 3 versions of the OS has not addressed this need.  Perhaps that’s why so many users jailbreak their iPhone to use a more user-friendly OS.  Take note Apple.

2. Safari Search

I’m not talking about searching for lions or tigers or zebras on an African plain — rather I’m talking about one of the most fundamental capabilities one needs when sifting through large amounts of text — TEXT SEARCH!  I can’t count the number of times I’ve ended up on a gigantic blog and need to find one snippet or comment only to give up after having scrolled the entire page and missing it.  On a computer I’d just hit CTRL+F and search.  A new iPhone OS needs this feature.

3. Merge Contacts

There are many ways we get duplicate contact information in our iPhones.  Whether we sync to popular contact management software, receive vCard profiles in MMS or email, or simply inadvertently create a new contact in the process of quickly trying to get an email out.  The point is that duplicate data creeps into our address book one way or another.  If you have ever attempted to clean this up you know that it turns into a time-consuming process testing the extent of your sanity.  A native function of the address book app should allow you to merge contacts on a field by field basis choosing which data to keep.  Not terribly difficult to do.

4. YouTube Account Management

The YouTube app is fun and useful… unless you have a YouTube account and want to do something useful with it.  iPhone 3Gs allows you to upload video taken on your device via your YouTube account.  A very cool feature.  But any attempt to edit details of your video — let alone delete the video — requires you to login to the actual YouTube website.  You might be saying, “That’s okay, I’ll just access my account via Safari on the iPhone.”  Sadly, both the Touch and Mobile versions of the YouTube website don’t allow this functionality either.  In order to make any meaningful changes to your videos (i.e. edit comments, edit tags, edit names, delete, etc.) you will have to view the Full version of YouTube within Safari.  Lame and/or fail.

5. Multi-Tasking

I personally don’t buy the argument that iPhone hardware isn’t capable of handling multi-tasking.  Even if users were limited to only 5 concurrently running apps it would be better than what we have now.  There are some things we do in one app that we would like to leave to a background process while we move on to another item.  For example, if we are waiting for a webpage to load we might want to check out Facebook.  When we leave Safari to go to the home screen in order to start Facebook; Safari stops working.  That means if I come back to Safari (even a couple minutes later) the page I had meant to navigate to will still be in limbo.  Am I really to believe that a few processing cycles can’t be diverted to a separate app?  Surely email I’ve “sent” in the mail app is still delivered even when I leave that app.  Why can’t the same be applied to other apps?


Jun 6 2009

Thank God

I’ve been debating what to write for my next blog post for some time.  There have been a few inarticulate ideas kicking around, but nothing inspiring enough to get me in front of the computer.  Then, this morning, it hit me.  I’m thankful for so many things in my life — not in a Thanksgiving-I-am-thankful-for sort of way — but sincerely thankful that certain things in my life are the way they are.  Here is a list (open to tweaking) in no particular order.

Thank God…

  1. I’m not married.
  2. I don’t have a kid.
  3. I have a mom and dad who love me.
  4. I have great friends.
  5. I’m a male.
  6. I’m intelligent.
  7. I’m creative.
  8. I’m my own boss.
  9. I went to college and graduated in 4 years.
  10. I’m going to law school.
  11. I’ve been to Ireland.
  12. I’ve loved at least one person in my life.
  13. I have my awesome car.
  14. I’m not a virgin.
  15. I have no disability.
  16. I am able to run.
  17. I am healthy.
  18. I make/have enough money to pay my bills even in this economy.
  19. Obama is our president.
  20. I have a sense of humor.
  21. I got through a difficult time with alcohol.
  22. I’m not a religious fanatic (not that religion is bad).
  23. I can keep a conversation going.
  24. My sarcasm sometimes goes unnoticed.
  25. I’m artistic.
  26. I can solve a Rubik’s cube.
  27. I can still take the derivative of an equation.
  28. I look really good with a tan.
  29. I don’t take shit from people.
  30. For computers and the entire IT industry.
  31. For movies and the entire movie industry (minus the MPAA — suck my balls)

May 12 2009

ONOSYS to Debut iPhone Restaurant Ordering App in Chicago

Placing an order at a restaurant can sometimes be a hassle.  We’ve all been there.  Waiters make mistakes, cooks can’t always read the waiter’s handwriting, and a great deal of inneficiency accompanies the entire process.  

Now imagine being seated at a restaurant that supports ONOSYS‘ soon to be debuted iPhone ordering app.  With the flick of a finger you can browse the entire menu, select what meals you and your family want, and place the order with almost no staff involvment.  This type of scenario would not only speed up the order-to-fulfillment process (which would make restaurants happy) but would also cut down on tons of human mistakes that invariably occur.  I also think this would become an extremely hip and cool app for people with iPhones to flaunt.  There are over 40 million iPhone users nationwide who use their device for everything under the sun — why not order food?

Stan Garber, of ONOSYS, will be in Chicago this week at the Marketing Executives Group Conference (MEG) and National Restaurant Association Show to debut the app.  I subscribe to ONOSYS‘ newsletter called “Quick Bites” which includes more details.  Here’s the newsletter in it’s entirety that arrived to my inbox this afternoon:

Got an iPhone? Get a pizza.

ONOSYS is taking the wraps off of the industry’s hottest iPhone ordering system in Chicago this week at the Marketing Executives Group Conference (MEG) and National Restaurant Association Show, and you can see for yourself how your customers can order anything from your menu with just a touch of their finger on the screen of their iPhone. 

With over 40 million phones sold, the iPhone has revolutionized mobile computing, and ONOSYS has harnessed that mobile power in a simple, elegant and powerful ordering system. 

Coming to Chicago this week? I’d love to show you the next wave in online ordering: mobile transactions. See how our mobile ordering system can help you reach more customers, increase order size and satisfy your customers who are on the go. 

Want to track me down? Email me (stan@onosys.com) to set up a time to get together, or call me on my cell (440-785-2870) if you have a few minutes of free time at the Show. 

Stan Garber 

P.S.: If you see a guy on the show floor wearing “ONOSYS Orange” shoes, that’s me. Stop and say hello and I’ll show you how mobile ordering works on the fly! 

Out of the thousands of apps currently flooding Apple’s App Store I believe this has real potential.  If the ONOSYS people get this right, and are able to prove a realistic ROI for restaurants, they’ll have a killer app on their hands.

If anyone in Chicago has video of this app in action please send it to me.  I’d love to 1) view it and 2) post it for others.


Apr 17 2009

Principal Component Analysis Research at Hiram College Inspires Computer Vision Project at The University of Hartford

Every computer science student at Hiram College is required to perform two research projects, called IRCs, prior to graduation.  Of the two projects I completed I am proudest of my Computer Vision project because it not only was one of the coolest things I’ve ever studied, but it also required an extensive amount of hard work to complete.  The satisfaction is still a source of motivation for me to this day.

The project’s in-depth details can be found at http://www.geigel.com/signlanguage/, however, briefly, I was able to employ computational methods, initially researched in the 1980s, to recognize American Sign Language letters within computer images.  (Note: The initial research performed in the 1980s focused on recognizing faces in images which have popularly become known as Eigenfaces).  The process is called Principal Component Analysis (PCA) and is widely considered to be a breakthrough discovery in the advancement of Computer Vision.  Much of PCA’s attractiveness comes from it’s ability to train similar, yet slightly different, images of a given class.  In my research, for instance, the classes I dealt with were signed letters corresponding to different hand orientations.  When it boils down to it, PCA is able to mathematically define (using Eigenvectors and Eigenvalues) the most important features of a given class (for example a fist for letter A versus the open cirlce for the letter O), and then when a new unknown image is presented to the system a calculation can be performed and a mathematically reinforced estimate can be made as to what class the unknown image belongs.

Ellen Walker, my Computer Vision professor at Hiram College, oversaw my research and offered help when I ran into issues.  Ultimately, I was able to develop/program/execute a fully functional PCA system in C++ for recognizing American Sign Language letters.  In fact, once the PCA system was trained, I was able to test it on 10 sample images with 100% recognition accuracy.  The project was a huge success!  Both in it’s results and in the lessons, knowledge, and gratification it left me.  Though Ellen has never explicitly said this to me, I think that she was also impressed and surprised with how well the results turned out.

This all took place in 2005 — the year I graduated from Hiram.  As the years went on I would occasionally correspond with Ellen and then on 11/29/2006 I received an email from her asking if my project could serve as a possible AI/Vision project that she would be submit to the University of Hartford’s “Machine Learning Experiences in AI” shared curriculum.  Of course I was excited and happy that my project would be the inspiration for such a project. 

A few years later I received another email from Ellen on 2/23/2009 saying that project was now appearing on Hartford’s website at http://uhaweb.hartford.edu/compsci/ccli/samplep.htm.  The project’s detail page can be found at this URL: http://uhaweb.hartford.edu/compsci/ccli/rasl.htm.  There’s also a PDF (http://cs.hiram.edu/~walkerel/RASLUPCA.pdf) that has in-depth details along with a credit at the very bottom stating that the project was inspired by my project!  In classic programmer speak — w00t!