The Wilson Project
Blog of Front-End Developer/UX Engineer Ivan Wilson

Skip to Navigation

Archives for Category / Front-End Development

  • HTML5 for Web Designers Book Review

    (Originally published on CDG Interactive/Innate blog)

    It’s back-to-school time, so here’s a pop quiz on today’s new buzz word: HTML5.

    1. What is it?
    2. Should I care?
    3. Should I worry?

    Answers: 1) see below, 2) yes, 3) not yet but soon enough

    So, now that you’ve taken the quiz, may I suggest a textbook? Specifically, HTML5 for Web Designers by Jeremy Keith.

    Now, I’ve known about HTML5 for a while (and some of the preliminary work around it). But when I heard about this book, I was curious how much more information could I gleam from its pages about HTML5. Judging by the title, I thought that it would be just an introductory text for web designers (not necessarily for experienced web developers).

    But, I took a chance. I ordered a copy and waited. And the package arrived.

    And when I first opened the box and held the book, the first thing that popped into my head was “Wow, this is a pamphlet!”

    OK, not a pamphlet but a brief, concise book (under 100 pages).

    However, from the very first page, it was evident that conciseness is the intent of the author. What Jeremy Keith does, with good effect, is to give the reader a brief synposis about HTML5, bypassing W3C language. (Alert: W3C documents are so precise, they could turn a cake recipe into a DVD instruction manual.)

    Of course, he starts off by answering what HTML5 is and is not–not a new version, but a much-needed upgrade for building future web applications. This means it not only adds/removes features, but also adds more semantic meanings attached to the current set of tags (important for Internet devices like mobile phone or screen readers.)

    For the remainder of the book, Keith highlights some important features and gives bits of advice for the newly introduced. The best thing is that he engages the reader enough to encourage further study in HTML5, which is not easy. This book could have easily become just another five pound dictionary. Of course, he remarks that there are others more experienced with this and points to some online resources. (As I am writing this, a number of new HTML5 books have popped up in the stores.)

    In the end, the author does what he planned out to do – give a nice gentle push in the right direction towards HTML5.

    Now, if you don’t mind. I have a list of HTML5 books to read.

  • The Well-Dressed Submit Button

    (Originally published on CDG Interactive/Innate blog)

    Hello, again. This is CDG User Interface Developer Ivan Wilson with another lesson gleaned from the top of the snowy, white-capped mounds of work that keep me busy every day. As I explained in my last post, my job is about building the bridge between design and technology. I need to create things that function perfectly, look good, and are useful for users. Here’s how I tackled a recent challenge on-the-job.

    One of our clients, Mondial Assistance, is a large multinational provider of travel insurance. We’re in the midst of revising each of their national B2C sites—more than 20 sites in all, in a variety of different languages. Our core website needs to work as well for consumers in Germany as it does for consumers in Japan—and everywhere in between. And as every web pro knows, content is key.

    But what does content have to do with me, a developer who doesn’t deal (directly) with the spoken language? Allow me to explain!

    The truth is, content is inextricably tied to both design and technology. Think, for example, about the humble button on a web form, like this one. As a UI professional, I need to make sure that this button looks right from a design perspective, and also functions perfectly regardless of the browser or language.

    The simplest solution would be to just take that graphical image and turn into a submit button via HTML code. Or would it? Remember, this little button has to function across 20 sites and in multiple languages. Just imagine the following conversations…

    “Nice button. Nice style. Can you add it to the German site? Oh, don’t forget. The French site is launching next month. We need to use the same buttons there as well.”

    OK, open up Photoshop (or insert your preferred graphics program) and change the text to German. Done. Fine.

    Repeat again…this time in French.

    Repeat again…this time in [insert local language here]

    Before you know it, you’re creating 20 versions of the same button. And that’s just one button on the site. Take into account all of the other buttons that reside on the site, and it becomes an algebra problem: (# of buttons) x (# of languages) = massive headache.

    Let’s take a step back and look at the problem again.

    We need a submit button that is:

    1. Editable – It needs to be easy to translate and manage across sites
    2. Usable – We do not want to create problems or lock out the user, preventing them from finishing their task

    Graphical buttons are out. Sure, I could always use a linked image with a Javascript function to submit data upon clicking. But what if Javascript isn’t switched on? (Surely it won’t be on screen readers and mobile phones). Not good enough.

    The challenge is creating a default state for the button, which functions for everyone, and an enhanced state that looks perfect for top browsers.

    In the end, here’s what I did:

    1. Used an old fashionedHTML submit button
    2. Along with the button, I added an extra bit of code that displays the enhanced state:<span class=”startquote submit”><span>Start Quote</span></span>In this code, I’m using CSS to turn two tags (spans) and enclosed text to appear as the prior graphical button. And by adding Javascript, I can make this “button” act like a regular submit button.

    OK, but now we have two “buttons”. Here is where the magic comes in…

    If you load up the page (without CSS or Javascript), you are the “default” state and the standard HTML submit buttons shows up.

    Now, if you are using a top-of-the-line browser, you have Javascript and CSS well supported. That means that you are ready for the “options” state. When the HTML button loads up, you will get this functional stylized button. All along, the “default” button is still around, just hidden from sight.

    And as the topper, since the text is only text, it can be changed with a couple of keystrokes. Done right, it can stretch to accommodate different word lengths due to translation or editing. As seen below:

    Why only the Latin alphabet? What about Cyrillic? Japanese? Chinese?

    Everything works beautifully. (Well, actually, IE6 has problems with hover states…but it’s IE6, of course.)

    So, there it is. Highly stylized yet functional submit buttons – well dressed for any occasion. And best of all…useful.

  • UI or UN? The Life of a Front-End Developer

    (Originally published on CDG Interactive/Innate blog)

    Hello.

    My name is Ivan Wilson and I am a user interface (UI) developer for CDG. I’ll be a guest author on this blog, posting every month or so.

    When I first asked about contributing to the blog (and I’m still wondering whether it was a good idea to agree), I thought it would be helpful to explain exactly what I do. After all, outside the tech industry, front-end/ui developers are a somewhat unknown breed.


    UI Developers, in Plain English

    UI developers aren’t full-time designers (though I had a three-month stint as one), but the best of us know enough to have a good conversation with the designers. And we can do more with Photoshop than just adjusting the image brightness/contrast.

    We don’t do full-time back-end programming (though I spend the great deal of my career doing PHP programming), but the best of us know enough to make things easier for the programmer and do some programming ourselves in a pinch.

    Basically, we’re like UN interpreters. We know how to speak multiple languages and if we are really good at what we do, very good things happen.
    Like other interactive agencies, CDG develops many dynamic, database-driven sites. My job is to build out the layer that you see and use every day on your computer or web-enabled mobile phone.

    That means I take all the graphics files from the designers, wireframes from the information architects, and build templates in HTML (or XHTML), Javascript, and CSS (stylesheets). I also have to create web-ready graphics from those same files. In some cases, I might even need to break out some Flash skills or work on other interactive features.


    “Well, That Doesn’t Seem Too Hard . . .”

    It sounds easy.

    Everything is easy before testing.

    And testing requires…six browsers in two platforms…or more.

    Still sound easy? (I hear a few plates dropping…)

    And it has to look good and function without a hiccup.

    Did I mention all this has to be done before passing it on back-end programmers?

    And if I move a pixel in the wrong place, the designers have pitchforks with my name engraved on ’em.

    High stakes, indeed.

    Yes, it’s definitely like being a UN interpreter.