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

Skip to Navigation

Tag Archive / web design

  • 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.

  • Search Patterns Book Review

    (Originally published on CDG Interactive/Innate blog)

    After a few months’ hiatus, the CDG Book Club is back. In this installment, UI Developer Ivan Wilson discusses Search Patterns: Design for Discovery by Peter Morville and Jeffery Callender.

    I first heard about the book Search Patterns during the IxDA Interaction 10 conference in Savannah, Georgia when I attended Peter Moreville’s lecture about The Future of Search. This brief book (less than 200 pages) interested me because it focuses less on technology and more on design. It’s not about Google or Yahoo, but on interaction designers and information architecture.

    That said, the main premise of the book can be summed up in the following statement:
    The problem of search is designing interfaces and processes that allow people to find things.

    Let us step back a moment. Is searching and finding two of the same things? Well, no. And that is a bit of a revelation to anyone, especially me who builds the front-end code for search pages.

    The book addresses two main points:

    1. Search is a not passive activity.

    What do we do when we go to a search page? Input term(s), click button, get results—right? But what happens when the results don’t lead to the information the user is looking for?

    The user isn’t some blank slate. Even if you’re just surfing around, you’re affected by a variety of filters–such recommendations from friends, past memories, etc. As users, we’re always judging whether a search result is right for us or just another dead end. If a user isn’t finding what he’s looking for, the problem isn’t necessarily an inadequate use of the search; it may be a user interface problem. In other words, the interface may not be adequate for what/how the user wants to find.

    2. Information need to be findable, not just searchable.

    Here, the authors approach the problem from the other end: those who create the content that is being searched. Especially on the web, content does not lend itself to being able to be found in an instant. It’s up to content producers and coders to make content searchable by using tools such as keywords or tags or database indexing. If you’re a business, you need to understand how to categorize products in a way that makes it as easy as possible for the user to find them via search (for example, adding information like ISBN numbers for books).

    Throughout the book, the authors detail different interfaces currently being used (faceted navigation, widgets, etc) in search. They also give glimpses into the future, with examples of search being tied in with social media like Twitter or Facebook. Also, the authors detail some of the methods the users take in searching for items whether in narrow or expanded focus.

    But in the end, designing for search engines will be about more than speed and accuracy; it will be more about having the process of finding easier. And that is what this book is about.

  • What One UI Developer Learned at the Opera

    (Originally published on CDG Interactive/Innate blog, edited by Jennifer Mayne Hoppe)

    Images of the Met production of Shostakovich’s The Nose, produced by William Kentridge –
    Google Search

    A lot of people think of user interface (UI) developers as “tech guys,” but I see myself more as a designer. At its base, design is about solving problems. So I’m really a designer who solves problems through programming. Like any designer, I have to think creatively—and I often find inspiration from the wide world OUTSIDE of my cubicle. (Yes, despite appearances to the contrary, I can function away from the office from long periods of time, like a cubical lungfish…)

    Take, for example, a recent Saturday I spent at The Metropolitan Opera. I watched a performance of an opera titled The Nose. Composed by Dmitri Shostakovich, in 1930, the opera is about an official who wakes up and find his own nose missing, only to find out that it has full life of its own (as well as higher status than he does). The music and the singing were well done, but was really got my attention was the production’s design.

    The design was conceived by South African artist William Kentridge, who is well known for his work with stop animation from drawings and paper cutouts. In this production, Kentridge melds his own aesthetic with historically appropriate references from the 1930s. Specifically, the set design follows the artistic strain of Russia a movement was about breaking and re-interpreting of artistic conventions like the revolution that spawned it.

    Kentridge enhanced the on-stage elements by projecting stop animations into the production. Projected onto the back of the set, the animations looked like early abstract shape animations of the same period in which the opera took place. Then Kentridge mixed the animations with live film and archive film footage. Rather than distracting from the action on stage, these elements truly enhanced the satirical nature of the opera.

    And that’s what really good design does. It frames the content for maximum impact and engages your attention. Great design happens when someone examines a problem thoughtfully and creates a solution that fits so well, it seems like the only solution.

    So now that I’m back “home” in my cube at Innate, I’m taking inspiration from my afternoon at The Met, and striving to find the most elegant, effective, and engaging solutions to the design and technical challenges that I’m working on.

    Such is the life of a UI developer!

  • 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.