Jan 29 2010

First Rule of UX

Found on 52 Weeks:

“You cannot not communicate. Every behaviour is a kind of communication. Because behaviour does not have a counterpart (there is no anti-behaviour), it is not possible not to communicate.”
—Paul Watzlawick’s First Axiom of Communication (link)

This idea has been running through my head since I first read it. EVERYthing we do as people is some form of communication, and as a UX Designer (I do not in any way claim to be one) every inclusion and every omission — every single one, is communicating something to your audience.

Never forget this. Thank you Joshua Porter and Joshua Brewer for this reminder. Keep bringing the pain.


Jan 28 2010

Javascript, A History Lesson

I had the privilege of heading over to Yahoos HQ’s URL’s Cafe to listen to Douglas Crockford give a history lesson on Javascript. Despite the lack of a personality and the very monotone presentational style, I found the information presented extremely interesting. This was the first in a series by Doug on “The Javascript Programming Language”. He’s previously done these sessions and didn’t expect the videos to be as popular as they turned out to be.  This new series is an expansion and revamp of the old videos (you can find the videos on the YUI Blog).

The Early Years, 1801-1890

“The people who should be the first to recognize the value of an innovation are often the last and obsolete technologies fade away slowly.”

Throughout the session, Doug kept coming back to this idea. It started first with the Jacquard Loom in 1801. This mechanical loom was invented by Joseph Marie Jacquard, by adapting player piano technology with the rolling “script” to create a loom that would automatically create a design on a textile based on what it was given in the “scroll”. Rather than use this rolling script, Jacquard found it far easier to create “punchcards” that he would then sew together to create the design or pattern for which the loom would then create the textile from. Since automating this process increased productivity a hundredfold (or more), it started putting master weavers out of business, which caused great frustration. This beautiful invention also created the byproduct known as Industrial Sabotage by the sheer fact that these master weavers started trying to think of ways to destroy Jacquard’s loom.

It wasn’t until much later that the Jacquard Loom entered into mainstream textile weaving. This time frame seems to correlate with the passing of a generation of time — 20 years. More on this later. The Jacquard Loom plays an important part in the history of computing because it was the first machine to use punch cards to control the operation of “program”.

The next machine to take it another step further was the Hollerith Card Tabulating Machine of 1890. This simple machine was used during the 1890 Census to track the location and other information  of U.S. citizens based on rows and columns of holes punched onto cards. The cards sat over pools of mercury that corresponded to the number of holes in the card. When wires were pressed down on the card, the wires that passed through a hole in the card dipped into the mercury, thereby completing the circuit and sounding a bell to let the operator know the card had been read. This complete circuit also allowed for a receptacle to open that corresponded to the information presented on the card. Compared to the Census of 1880, which took 7 years to complete, the Census of 1890 “…finished months ahead of schedule and far under budget.”

The Middle Years, 1950-1980

It wasn’t until the 1950s that this punch card technology started making its way into the corporate world to record data such as invoices, purchases, personnel, and any other record-keeping needs that a company would require. This introduced the idea of punch cards as we know them (or at least, have heard of) which eventually led to the Rise of the Mainframe, and the concept of the “Stored Program”. The Stored Program was a program that was “stored” on a set of cards and then ran through a machine that read the sequence of holes in order complete a task. Eventually, it wasn’t enough to just read one program, but we wanted to do things in “batch”, so we built machines that could handle multiple stacks of punch cards at a time, reading them into memory, and then processing the set of tasks. This again was a serious advancement in how things were done at the time — a significant hardware advancement. Programmers took time to catch on; about 20 years in fact.

Due the the lack of any organizational structure between the analyst writing the specs, the programmer coding the program, the keypuncher punching the program, the verifier checking the punches and the operator running the program, if a bug was discovered, a meeting would be called to find out how it was introduced.

The First Bug

As a sidenote, the first (recorded) bug was discovered by Thomas Edison:

Mr. Edison, I was informed, had been up the two previous nights discovering a bug in his phonograph.
– Pall Mall Gazette, 1889-03-11

This “bug” was probably some sort of chirp that sounded like a bug when he was listening to his phonograph. The idea of the “bug” was furthered along by Grace Hopper just after WWII while working on a Mark II Computer at Harvard. She and her associates found an actual moth stuck in a relay, which was causing issues with the computer. She then said something along the lines of needing to “debug” the system.

The Later Years, 1980-Present

As the need for computing power rose, so did the complexity of the architecture required to power these “behomoths”. This led to the introduction of the 8-bit generation of chips (Intel’s 8080, Zilog’s Z80, Motorola’s 6800 and MOS Technology’s 6502), which powered computers like the Apple II. These computers were considered breakthrough devices because it finally allowed the consumer (some would argue the prosumer) access to a computer, which was previously unattainable for people of the time. Computers exploded onto Main Street and many people still have fond memories of their Apple IIs and the programs they created on them. These 8-bit chips then gave way to their predecessor, 16-bit chips, which then gave way to Moore’s Law.

Moore’s Law (Hardware) and Programmers (Software)

Moore’s Law says that the number of transistors that can be placed inside a chip doubles approximately every two years. This law was named after Intel co-founder Gordon Moore and this “trend” has been continuing on for more than 50 years and isn’t expected to stop or slow down until 2015 or later. The reason this concept is important is due to the impact hardware improvements has on software improvements.

Generally speaking, hardware developers have a tendency to improve the quality and performance of their device with an efficiency along the same lines/path/trend as Moore’s Law “predicts”. They are incredibly efficient at building systems that use the best/most current technologies and work most efficiently.

Software developers, on the other hand, tend to be slower on the uptake than do hardware developers. As big of a game we talk, you would think that we’d be different, but we tend towards being “traditionalists” and not very forward-thinking. It takes about a generation of time (20ish years) for the ‘old hat’ ways to die off and allow the most current way of programming/building our application to come through.

This has been evidenced over and over throughout the history of hardware/software development, and is evidenced by Intel’s 8086 (and following) chip architecture. Intel developed the 8086 to be incredibly efficient and use the latest technology, but no one wanted it because it wasn’t backwards compatible with the 8080 architecture as well as costing more. Intel nearly collapsed because of this blunder and from the 8086 all the way through until after the Pentium chip has been based on the old 8080 chipset technology because we programmers don’t know (or want to learn) how to be progressive in our ways. Stuck in a rut we are.

Another example of this is with Procedural vs. Object-Oriented (OO) programming. For years and years and years, (software) developers thought the best way to program was in a procedural fashion. Only recently (within the last 5 years?) has OO programming become more mainstream.

Programming Languages

Once programmers started getting hardware that actually had the capacity (and ability) to handle “high-level” programming and weren’t stuck in building applications in Assembly Language (“low-level” programming), the number of languages at their disposal simply exploded. Fortran, COBOL and ALGOL all started building upon and stealing each other’s good ideas to create a language that was easy to read and understand.

Eventually, these three languages gave way to PL/I, CPL and ALGOL 68, which then gave way to BCPL and Pascal (finally a familiar name!). Fortran and BCPL finally gave way to B and B + Pascal = C, the root of every program and/or application.

You may be asking yourself at this point, what does all this have anything to do with Javascript’s history? I was in the same boat about this time as well. “You’re just going over the history of computers and programming languages! How does all this relate to Javascript’s history?” Douglas’ answer to my question came up in some of the next slides. There’s a lot more that he went over, but I’ll skip the slides that talk about how Smalltalk and C met, fell in love, and had 4 children (Objective C, C++, Eiffel, Ruby) and 2 grandchildren (C++ eloped with some unknown language. Java was the firstborn and then came along C#). I’m also not going to talk about the first ever game console because that would be another couple paragraphs, and I’m sure you (as I was) are starting to fade. I’ll say this though, the VCS was the first system that is credited with popularizing microprocessor-based hardware and cartridges (from which we get the rise of Nintendo, Sega, Sony and Xbox — they can all trace their roots back to the original Atari 2600).

The very basic root of Javascript can most likely be traced back to the original Macintosh computers and their simple, yet intuitive user-interface and a way of display information called “Hypercards” (sound familiar?). Hypercards were a simple way of displaying graphical information based on database entries that created a “user-modifiable interface”. Bundled with Hypercards was HyperText (sound familiar again?). HyperText  drew upon the “user-friendliness of languages like SmallTalk (which was used in educational settings and looked very much like pseudo-code or even the Ruby programming language). HyperTalk used human-readable syntax to accomplish a set of tasks like click a button, enter text into a field, check a box and a few other items. Here’s the syntax:

on mouseUp
  put "100,100" into pos
  repeat with x = 1 to the number of card buttons
    set the location of card button x to pos
    add 15 to item 1 of pos
  end repeat
end mouseUp

“Hey, that looks kinda like Javascript!” you might be saying. And you’d be right! “on mouseUp” got it’s start here in HyperTalk — pretty cool! From this idea of Hypercards and HyperTalk we also get Tim Berners-Lee’s idea of the WWW (sorry, not Al Gore’s idea), which leads to innovations like the Mosaic browser from whence we get Netscape and Spyglass (who is eventually purchased by Microsoft and becomes Internet Explorer). We have now entered the “Age of the browser” and we shall not return. Everything is different from here on out.

Javascript was written by Brendan Eich while at Netscape and its first version was written and deployed in just 10 days! Douglas challenged any language developer to build a language from the ground up in 10 days..heh. Brendan Eich relied heavily on languages such as Java, Scheme and Self to define Javascript and its syntax.

And that pretty much concluded the History of Javascript. Like I said at the beginning, not at all what I thought, but entirely interesting and informative.

What do you think P52ers?

UPDATE: If you are interested, here are some photos, full video and the slides.


Jan 11 2010

I am An Artist (and How I Got There)

Yep, you heard me. I am an artist. Just like Michaelangelo’s Sistene Chapel, DaVinci’s Mona Lisa, Shakespeare’s sonnets and plays. The tools of these artists included brushes, canvas, paper, pencils and buildings. They were commissioned by the wealthy, the Church and royalty to create these wonderful masterpieces that are now known the world over. As a web developer, it is my job to create works of art. The tools of my trade are the browser, my hands and my trusty text editor of choice.

I had the privilege of attending An Avent Apart in July and one of the recurring themes was that of craftsmanship. From speakers like Dan Cedarholm, Jason Santa Maria, Jeffrey Zeldman, Kristina Halvorson, Andy Clarke and many others. These are some serious “heavy hitters” in the game today — all of which create amazing pieces of work from amazing design studios, and in each one of their sessions, they spoke of this theme.

The analogy they drew from is that of a woodworker who spends years and years perfecting his craft, first as an apprentice under a trained master craftsman. In time, this apprentice would become the master craftsman and begin training an apprentice himself.

As I began to think about this process and how it applied in my life, I realized that the analogy of an artist/master craftsman applies not only to woodworkers, but also to my life as a web developer. We should ALL strive for this attitude of becoming a master craftsman in whatever field we find ourselves in.

Becoming A Master Craftsman

So you might be asking yourself, “How do I become a master craftsman?” I don’t claim to have all the answers, but I know what has worked in my life.

Read.

There are so many good books on web design, techniques, tips, tutorials, future-proofing your site and so many varied ideas on how to “do” web development. If you aren’t keeping up on the industry, how can you contribute and therefore become a master craftsman? The first book I ever read was Zeldman’s Designing with Web Standards (1st Edition). I am now reading the 3rd Edition (I’ll be getting back to this a little later). This book pretty much launched me full-bore into the wed development industry — and I only read the first 20 pages of the book! Since then, I’ve picked up several other books on HTML, CSS, Javascript, PHP, MySQL, design, typography…you name it, I most likely will have (1) read it, (2) heard about it or I’ve (3) read tons on the subject. I’m saying this not at all to “toot my own horn,” but to make a point — you can’t learn without gaining knowledge, and part 1 of that venture is reading about it.

Listen.

Listen to what the master craftsman are saying. Do what they do. If you don’t understand what they’re talking about read more, dig deeper. VIEW SOURCE! The day I found FireBug was the day my life changed forever. I was finally able to “listen” to what a the code was saying to me. “Inspect Element” (whether in Firebug or Web Inspector) is by far my favorite tool. I have never been able to listen to a website better.

Not only can you listen to these master craftsmen’s code, you can actually listen to them. Drink in everything these master craftsman have to say or write. They got to where they are now because they listened to their master craftsman and continued to build upon their knowledge.

I highly recommend going to conferences. There are so many to choose from! An Event Apart is probably the creme de la creme, but there are so many other great conferences these master craftsmen speak at. If you are at all interested in raising the bar of your own skills, going to a conference and listening to what these people have to say can give you an incredible influx of creativity, rejuvenation and a plethora of new techniques and skills.

Study

Remember when you were in school, and you had all that homework? I certainly do. I also remember thinking to myself, “Why do I have to do 10 of these dumb math equations? I already know how to do it!” Well, repetition is part of the process of studying and committing all this new knowledge that you’ve just read about and listened to. It’s time for you to start studying the techniques of the master craftsmen; rip apart their code; study it. Chances are, you’re not one of those people that just “gets it” — I know I’m not. The beauty is that its okay! That’s what trial and error is for.

Check out your local community college — the one I live by offers tons of classes in web design and development. If you’re a beginner, this is a great (and cheap) way of gaining some knowledge and expertise in the field.

Do

As it is with any industry or area of life, if all you do is read, listen and study without doing, you’re not gonna get any better. The exercise would be futile! A great example of a master craftsman who continues to “do,” is Andy Clarke. Whenever he starts studying for a new book or a new speaking engagement, he starts tweeting like mad about all the different techniques he’s using — it’s really quite hilarious — but enlightening. This is a master craftsman who is not ashamed to admit when he botches something. :c) Now that’s a personality I can relate to!

Repeat

Finally, the last step is to repeat everything we just went over. Without repeating everything we just went over, you fall back into your old ways and stagnate. RESIST IT! Please rinse and repeat! Make the web a better place, and repeat!

—-

Interested in hearing more? Follow me on Twitter.


Jan 1 2010

Why jQuery Died

jQuery as many of you probably already know, is a widely accepted javascript library with a focus on making javascript development easier and faster for designers. Prototype has also been a library that was made popular by Ruby on Rails and CakePHP developers since the library was not only included and made easily accessible by these frameworks, its acceptance in the web development world was fast and thorough. We’ve recently gone through an exercise to standardize on one javascript library to be used across the company in all our future development work. The battle for which library should be used had begun. The short of it is jQuery lost…but not without a fight, nor without much discussion, debate and frustration.

Pertinent Background Information

At work, there are two departments that focus on the website(s); the Creative team (of which I’m a member of) and the Engineering team. While the Engineering team is focused on the features and user-experience of the ecommerce side of the company (card selection, personalization and customization, form processing, checkout, etc), the Creative team is focused primarily on the marketing and front-end/UI side of the company (pretty images, SEO modifications, promotional banners, ease of navigation, site design and colors, etc). Creative’s development cycle has an extremely fast turn-around, whereas the Engineering team is slower, but releases more…substantial changes. As you can see, both departments are essential to the overall success of the company and as such we are very complementary — one cannot exist without the other.

When I first started a little over a year ago, the Creative team was small and relied pretty heavily on Engineering resources whenever there was a need for any javascript development as no one knew how to write (good) javascript code. This put an unnecessary strain on Engineering to help us whenever there was a need. We were equally (and unnecessarily) burdened, so a decision was made to start implementing the use of jQuery (which I knew) to help rapidly deploy some quick enhancements to the site (like image rotators, input clearing, and other similar tasks).

As you can imagine, this was going to eventually lead to problems with the $ (jQuery’s and Prototype’s) sign (what’s the dollar sign for?) as both Prototype and jQuery like to use this guy…it was just a matter of time.

A fellow developer summed it up perfectly like this:

As far as these two go, I think the main difference is that jQuery offers a cleaner DOM selection/manipulation experience, as well as a large base of library and community plugins/widgets. I find it to be more of a designer’s library, where with very few lines of js you can achieve very good results for enhanced UIs.

Prototype, on the other hand, may be a bit more verbose (selection, chaining and so on) but I find it to be more of a programmer’s library, it seems to  offer a more complete environment where more complex applications can be developed (a class mechanism, a nicer binding mechanism for closures). In many ways Prototype seems like an attempt to transform javascript in to a more standard OO language while providing a good starting framework.

Put jQuery into noConflict() Mode

You might be asking, why not just put jQuery into noConflict mode? That was my argument as well! That would solve just about everyone’s problems and jQuery would still be used. The only issue it wouldn’t fix, is the one where we wanted to standardize on one library.

Business Objectives and Compromises

Since both libraries accomplish the same tasks with essentially the same speed and efficiency (learning-curve not included), the decision was made that for the betterment and longevity of the company, the library to be standardized on would be Prototype.

In the end, the decision didn’t come down to which library is better or worse, or what does the industry think or say is better or worse, but  what makes the most sense for our situation. As the company continues to grow, and more widgets and technologies are tacked on to make things better, it just made sense to standardize now on one framework so we can use widgets created from either side of the company on other pages.

Additional Thoughts

This brings to mind a similar thought regarding other choices made in life (maybe expanded upon in another post…?). Often, as people we choose one thing over another based on personal choice without figuring what the best solution really is. In this example, the argument could be (and was) made that the majority of the web developers in the world resort to jQuery as their library of choice (I would venture to guess around 60-70%). Though this does lend credibility to the maturity and stability of jQuery as a potent framework worthy of serious contention, it doesn’t necessarily equate to what is best for the business. There has been significant time (and money) invested in developing features in Prototype and would require another significant amount of time (and money) to reverse this and change everything over to jQuery.

Regardless of this decision, jQuery is still my library of choice and will continue to be used in all my personal projects outside of work… Long Live jQuery! Please, if you have any additional thoughts, let your comments be heard — I’m interested in what you all think!