We are the dead. Short days ago
We lived, felt dawn, saw sunset glow,
Loved, and were loved, and now we lie
In Flanders fields.

Take up our quarrel with the foe:
To you from failing hands we throw
The torch; be yours to hold it high.
If ye break faith with us who die
We shall not sleep, though poppies grow
In Flanders fields.

Lt.-Col. John McCrae

Proximity marketing with QR codes is not a new idea. Every mobile phone sold in Japan plays nice with QR codes. There are none in Canada just yet, but it’s not too hard to enable your mobile phone to decode QR codes. (Here’s a demo on YouTube).

I’m sure many reading this might be wondering just what a QR code is. It’s like a barcode that can hold more than just a number. The cool thing about QR codes is how they’re read. You just need a mobile phone with a camera. You take a picture of the QR code, and then the magic happens.

The very first campaign in Canada that used QR codes (with great success) was for Vespa. Posters in the GTA for Vespa had QR codes in them. Passerby’s could snap a pic of the QR code, and then get offers sent to them on the spot. It got more foot traffic into the dealers.

There’s another great usage of QR codes just launching called The Voice of the Street. I like this one. Artists can sign up for their own QR code which they then use on their artwork, whether it be a poster, graffiti, on screen, whatever. Passersby can snap a picture of the QR code and get more info about the artist. Tres cool.

I think we’ll be seeing many more marketing campaigns that take advantage of QR codes in 2008. Keep you eye out for them, I know I will be!

This is all very new still. I’m hoping they stick it out, but I wouldn’t be surprised if one or two of the new additions bail on this effort if things don’t go their way; I certainly hope that’s not the case though.

I generally ask questions when I blog, using those questions to come to conclusions. This time around, I’m going to start with two important conclusions:

1. Webmasters never really existed;
2. We don’t need web designers.

I’ve had many conversations over the years regarding both statements, so let me explain what I mean by them.

Webmasters Never Really Existed

I’ve always hated the term webmaster - especially when I held the title. My problem with webmaster is that no one really knew what it meant; it didn’t clearly explain the roles & responsibilities of the position. You’d see job postings for people who knew everything from HTML, JavaScript, ColdFusion, Java or CGI/Perl to people that knew Photoshop, Illustrator (eventually Fireworks & Flash too), web design and copywriting. Not to mention knowing how web servers worked! Each post would be a hodge-podge of various combinations of these skills, and sometimes employers expected them all!

I always understood the definition of a webmaster to be someone who took care of the web server and performs the maintenance of content; it’s not the person who programs the website or designs the website.

The term “webmaster” is very much like the terms “DHTML” or “Web 2.0″ - there is no clear definition. They aren’t single things, but a combination of things that people like to lump together because they don’t really understand them. It’s great to have resources like Wikipedia that act as a central repository for defining such things, but even there, the current definition for webmaster is quite vague & broad.

Luckily, now that the world wide web is over 17 years old, we’ve grown up; we know that building a website takes more than one person, more than one expertise. Take a look at blogs. The engine behind the blog sites is written by very competent developers. The creative “look & feel” is usually contributed by professional designers. The navigation & functionality are designed by information architects. Only the copy is written by the blogger. This in addition to many other roles you find in web application development today.

So back to my point - webmaster never really existed. What did exist, were professionals that were really good at their chosen field (many of them self-taught) who learned enough about the web as a whole to get by on their own. For me, webmaster is a fictional title given to these people by the folks who didn’t understand the web at the time.

I hope to someday see the definition in Wikipedia to reflect this fiction.

We Don’t Need Web Designers

I’ve been telling people this for quite some time now, just in casual conversation; I think the time is right to put myself on a limb on this one. And I’m happy to say that the agency I work for holds many of the same ideals.

When I started developing for the web (roughly 1993), I started working with designers. It was inevitable that the designers came from print, since web design didn’t really even exist yet. As I learned more about the technical side of the web (HTML, CGI/Perl, Java, ColdFusion, etc…), I started to get really frustrated with the total lack on understanding traditional designers had of the web medium. But instead of giving up, I figured I’d try to help them “get it.” It was never easy… not once.

As time went on, people started calling themselves web designers; these were people who supposedly could design for the web. I saw two trends with web designers:

1. They were traditional designers who knew a little HTML;
2. They were self taught people who knew HTML, but had no design background.

In most cases, they still sucked.

The people in #1 came up with some great looking designs that were simply impossible to execute (Fireworks helped with these designs when it came out… thanks Macromedia, RIP). Because they “knew” HTML, they would argue that it could be done - they’ve seen it done. What they often failed to see are those subtle little differences in design… the difference between an outstanding design that just blew people away, and the design that looked like a print brochure and had to be one big JPEG or GIF. Yuck!

The folks coming in from #2 certainly knew how the web worked. They knew HTML inside out and backwards, they were intimate with the challenges of table-based design techniques (thanks to CSS2 for ending that nonsense), they knew how it all fit together. The only problem: their designs stank! Sites were always built from the HTML up, which just didn’t work.

Yes, there were the very rare designers that had just the right mix, usually with a strong design background and an open mind. These were the people developers worked with, not against. These were the true web designers. They started creeping into the scene in the mid to late 1990’s and continued into the early 2000’s. It was a great time for design on the world wide web.

Enter 2008. The web has been around since 1991 (conceived in 1989 I think). Seventeen years old! My how it’s grown. We now have a very mature medium in the world wide web. Advertisers and marketers are taking it very serious, so much so that advertising budgets are being shuffled around to include less television & outdoor and more on-line. The web is something that most folks interact with on a daily basis - they get the medium, they understand how people use it.

The common body of knowledge in relation to the web is at the point where it truly is ubiquitous (I’m nowhere near the first person to say that). There certainly was a time when we needed specialist designers - web designers - to come up with great web creative. I would argue that that’s no longer the case; we just need great designers!

There is very little that cannot be done on the web today; the limitations we once faced are gone. Let the creative ideas flow, let the designers do what they do best. Let the web production artists and web developers execute the designer’s great designs.

When the Zend Framework (ZF) was released, I was pretty skeptical. I had researched the other PHP frameworks quite extensively and found that they were often too complicated to use in the ad business. I took the time to explore the ZF a little, and was pleased to find that many of the ideals we held as important in our proprietary framework were also found in the ZF! I was sold.

The decision was made in the summer of 2007 to use the ZF as the core for the EF. There were still features in our framework that didn’t exist in the ZF, but we simply had to extend the ZF and add in our extensions. So far, it’s worked out great!

By using the ZF, we’ve been able to focus our efforts solely on adding in the features that we’re used to having available. My goal has always been to relieve the developers of the mundane tasks they often have to repeat for every project. Luckily, the ZF has some great built-in classes already. Here’s what we like about the ZF:

1) Zend_Controller: We had implemented our own MVC model. We used a front controller (what ZF calls the bootstrap) that instantiated the classes that ultimately routed the request to where it needed to go. Generally, a request got passed to a module, which then handled the request and returned the final XML fragment (what we called the Action Document) to the view. The ZF handles a request in a similar way… we were quite happy.

2) Zend_DB: We had our own Data Objects with our framework. After looking at Zend_DB, we realized that they’ve built something much more useful and extensible than what we had. The best feature is that the objects initialize (and cache!) themselves. This saves us lots of time from creating not only the data object classes, but all the fields found in the database tables. The main benefit here is changes to the tables. If we add or change fields, we don’t have to worry about the data object classes since they update themselves. Also, there’s some great simple functionality for dealing with common simple queries, but we still have the ability to whip up those crazy long joins we sometimes need (we tend to use views & procedures now though).

3) Zend_Auth & Zend Acl: We had our own way of authenticating sessions & providing access to functionality, mainly based on module/action. Auth & Acl was almost a mirror of how we did things, so it refactored quite well into the way we managed this.

4) Zend_Json: We use the YUI for most of our JavaScript needs. The YUI plays nice with Json, and Zend_Json is a nice simple implementation (Zend_Json::decode() & Zend_Jason::encode).

5) Zend_Session: We wrote our original session handling from scratch, largely database driven (which had some DB optimization issues). Zend_Session again fit very well into our framework’s design. We extended it to be compatible with our session database structure, with the added benefit of cached session data. Spend things up tremendously.

6) Zend_View & Zend_Layout: Our equivalent was what we called Renderers. A module would return a fragment of XML that got transformed and added to an overall template. The template was then rendered into something that could be viewed by a viewer… a web browser in most cases. We extended Zend_View to fit into the way we like to code our web apps, taking full advantage of Zend_Layout to help us along.

On top of this, we’ll be building in the automated form validation we had in our previous framework (EF v2.0). Form validation is more than just data validation (something the ZF does very well). In the action script for a module, we simply create an instance of a form field and specify how it needs to be validated. The back-end works out the validation, either letting the form submission through, or returning the original pre-populated form with validation errors displayed.

All new sites that we build moving forward are using the Euro Framework v3.0, which is built as an extension to the Zend Framework. We’re currently doing a complete rebuild of the Home Hardware website (currently built on EF v2.0) and building a microsite for Fidelity. If we can dictate the web platform, we might also be building microsites for Kraft & Reckitt Benckiser using the EF v3.0 (we might have to use .NET).

So, why are we using the Zend Framework? It already matched the way we developed web sites (lets hear it for design patterns) but in a better tested and efficient way. It also adds in many features we simply could not implement as an adverting agency, like the various web service APIs (Zend_Service), the tie-ins to Google (Zend_Gdata) and the many useful utilities that make our lives as developers easier (Zend_Pdf, Zend_Feed, Zend_Mail, Zend_Mime, etc…).

Above all, we know that the Zend Framework is supported by a great community of PHP professionals.

“Who do you think will fall first? Google, or Microsoft?”

The answer doesn’t really matter, what does matter is that history shows us that all good things come to an end… all empires fall, new empires rise. What if we took the idea of history, and applied the concepts of design patterns? We can easily map out how a civilization generally rises and eventually disappears. We can map out how carnivores generally interact with herbivores. We can map out the generalities of human behaviour. It’s this last one that got me a thinkin’.

Lets travel back in time to when humanity lived in villages or small communities with a few dozen people, maybe a few hundred. These villages were central to the way we lived and the way we’ve evolved. Humans are communal creatures, we like company, we need friends, we have a better chance of survival in groups. These tight-knit communities all knew each other and lived together and died together.

Lets come back to today. Although there are many villages today, most of the population lives in cities with thousands, hundreds of thousands, even millions or people. Now to my point… or maybe it’s a question.

Do people in very small tight-knit wired communities use social networking? Do they even need social networking? Could the very success of social networking be attributed to the lack of “village” in our daily lives? Does Facebook replace the sense of village that, in the very core of my humanity, I miss? I’m curious. I’d love to find stats that show percentages of population in small communities who are active in the social networking and compare that to the big cities.

I’m not saying this is a bad thing, it just kinda proves my point (if I’m trying to make a point). History shows us that humans adapt. With the lack of the village, perhaps we’re finding new ways to make those tight communal bonds using the virtual world. Social networking keeps me in touch with the people that matter most to me in ways never before possible. Little snippets of friend’s and family’s lives are delivered to me. I can comment back. I can easily communicate and share pieces of my life. I think that this is what we’ve stumbled upon here. Social networking is filling a deep down need that’s just difficult to find in the large urban environments we’ve built around us. Continued success in social networking will be dependent on identifying the patterns in life, and applying those patterns to the online world.

Today on my TTC ride home from work, I was listening to an episode of Ideas on CBC Radio. In this episode, titled “Second Life and First”, cyberspace researchers Abby Goodrum and Kirsten Pullen explore the confusions and contradictions of online identity, and ponder how the virtual world may be altering our sense of community, and of ourselves. The hosts mention that they are “digital immigrants” as they didn’t grow up surrounded by technology as our kids are today. They consider kids of today to be “digital natives”. While listening, considering my background, I’m putting myself in the digital native pile.

Now back to the 10 year old…

My son, while driving home from a school event tonight, starts telling me about his friends playing a game of tag. Great, tag, we all know and love tag. Then he starts explaining how the people who are hiding use their Nintendo DS’ to let each other know where the person looking for them is. What?!? That’s awesome! Using the DS to text each other wirelessly during tag!

Then my mind brings me back to the radio show I heard earlier. It was then that I came to the sad realization that I am indeed a digital immigrant. I’ll never experience technology the way my kids experience technology today. They’ll never be in a world without the Internet, without wireless, without mobile. They don’t have to learn about these technologies, they just use them… to play tag no less! Using a DS to play tag is as natural to my kids as using walkie-talkies was for me when I was 10.

So here’s to all my fellow digital immigrants! It’ll be interesting to see where the digital natives take us ten years from now.