blog

In cooperation with our friends at Sync Creative, we put together a project for McGraw-Hill that was noticed by the Times. It’s always thrilling to see our work as a part of a bigger picture.

http://www.nytimes.com/2009/03/22/education/22textbook.html?_r=1

I am working this afternoon on a top secret project that involves a system to manage pages and pages of HTML content. I won’t go into anymore details, but I do need to work deeply with HTML documents. Anyway, PHPQuery is a cool idea, but after implementing it, I noticed I was getting some odd characters where they were not supposed to be. So, another solution had to be found.

I turned to the Document Object Model (DOM) class built into PHP, which I had not yet used. The documentation sucks, but it is actually a really powerful class. It is, however, lacking one vital function. The ability to get and set the HTML/XML contents of an individual node, that is, the equivalent of the innerHTML property of JavaScript DOM.

I googled for a solution but came up empty. So, I had to invent the solution myself, and after quite some time of tinkering around here’s what I’ve got:

function innerHTML(&$dom, &$node, $html = false) {

     ## if html parameter not specified, return the current contents of $node
     if($html === false) {

          $doc = new DOMDocument();
          foreach ($node->childNodes as $child)
          $doc->appendChild($doc->importNode($child, true));

           return $doc->saveHTML();

      } else {

           ## get rid of all current children
           foreach ($node->childNodes as $child)
               $node->removeChild($child);

          ## if html is empty, we are done.
          if($html == '') return;

          ## load up $html as DOM fragment, append it to our now-empty $node
          $f = $dom->createDocumentFragment();
          $f->appendXML($html);
          $node->appendChild( $f );
     }

}

Not sure if this is the most efficient solution, but from what I’ve seen so far, it works.

So, you’ve got a website. What exactly is it doing for you?

You might have an answer to this question. I hope so, at least. But does that answer directly address the bottom line? How has your website increased the value of your business in the last month? The last six? How does that compare to last year? Socrates said “the unexamined life is not worth living” - I’ll bastardize that comment for my own purposes and claim that the unexamined site is not worth owning. Not quite as eloquent, but it gets the point across.

Caveat: don’t just pay lip service to metrics and tell me how many visitors you’ve seen in the last month. That’s a factor, but not quite so important. Instead, tell me what you’re doing with those numbers - what they’re seeking - why are they looking for it - and how can we profit from it?

A website is imbued with the powerful ability to provide to the owner a whole helluva lot of information about site usage. Who’s visiting - when - even why and how. It tells you a lot about the interests and profile of your visitors. It’s whispering secrets regarding the way your business should move.

Are you listening?

So I got this idea the other day when I noticed that tinyurl.com was one character longer than dynamit.us. Sure it is no is.gd, but tinyurl.com is a legit URL shortening service. So with a shorter URL, why not make my own such service using our dynamit.us domain. It certainly cannot hurt to have our website address floating around the web more frequently.

Taking a page out of Leah Culver’s playbook, I did just that. It is not quite as efficient since I am using base 36 instead of base 56 as Leah suggests. Since I wanted to whip this up quickly (only took me about 30 minutes to get it off the ground), I used PHP’s built-in base_convert function which only accommodates bases between 2 and 36.

Anyway, you can now shorten URLs on us by visiting http://dynamit.us/url.

I am working on some basic statistics for the usage. Any thoughts on what would be cool to track?

Quality assurance, testing, debugging, bug hunting, etc. Whatever you want to call it, it sucks. It’s difficult to do, it’s not any fun, but it is an essential step of launching a web application.

It usually goes something like this: you write up your test cases to include actions that should work and some that should fail. You do black box testing and you do white box testing. Then, rinse and repeat.

Eventually you get to a point where you feel comfortable launching, but it does not stop there. Because this is web, we are not building software to be implemented in one company or institution or even across a single industry. Rather, when we decide it is time to launch a site, we instantly open ourselves up to a world of many different people with many different skill and experience levels.

Herein lies the difficulty. All of us internally, as well as the client, have a great understanding of the system and how it should be used, even if we have an opportunity to have some outsiders test the app, there is no way to predict how each individual will use it. Simply put, it is an incredibly difficult task to consider all the ways in which a user can possibly use each function of a web application.

Recently we launched an online store for a client. The client came back with one of their customers reporting that they got an error message when trying to checkout. After a good while attempting to reproduce this problem (and failing to do so), I realized that the user was using the site in a way that had originally never crossed my mind. Worst of all, the user’s actions were very logical. The site was designed so that there was no way to get to the final checkout stage unless you had items in your cart and you had entered all of your billing and shipping data. But once this was done, you were taken to a page that displayed your cart and a form to enter a payment method and checkout. I surmised that the user arrived here, decided they were not yet ready to purchase and bookmarked this page to return later. Like I said, a very logical action. However, upon return their session-based shopping cart and user data was gone, resulting in an error message.

Just one example of how quality assurance in web means being prepared for every user.

Note: I just wrote this article without mentioning the fact that we also must deal with things such as screen resolution, operating system, web browser, browser settings, plugins installed, etc. Yes, there are still people out there using Windows 98 and IE6 with cookies disabled and flash not installed. And, we’ve got to be ready for it.