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

Menu Skip to Navigation

Archives for Category / Web

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

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

    No. Really.

    Basically, it originally started as an idea for me to do something close to work but outside the office.  However, there are a number of ideas that need fleshing out. Not just about work (dealing with bad HTML code) but also about ideas about Charles, TWP, front-end developement, and IxD.

    And linguistics.

    More news to come.

  • Storm and Stress

    After three weeks of work and vacation (which was almost like work), I got a free weekend.

    One in which I got to do nothing.

    Now this week, a hopefully(?) slow work will allow me to do the following:

    • Write two blogs entries for CDG – one on the book Search Patterns by Peter Morville/Jeffery Callender and the other about The Nose (The Met/MOMA)
    • Started prototyping work on Charles, which I started Sunday, first bit of work in a couple of months
    • Starting more blog entries here, including a brief one about the last three weeks

    I have a number of things to do before things speed up again at work. There is also the next two trips in May, which I need to get ready for.

    First, NYC again for another Met performance – instead the Russian satire of The Nose, it will be the dark, German expressionism of Lulu.

    Then this will be followed by my yearly pilgrimage to the Pacific Northwest again (Seattle, WA/Vancouver, Canada).

    Lots to do, lots to see. Just need to do more than one blog entry per month.

    Later.

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

  • Blog Entries for CDG

    This week, my second blog entry for my employer, CDG Interactive, is up. Called The Well-Dressed Submit Button, it is my story about web development and dealing with usability.

    My first one, UI or UN? The Life of a Front-End Developer, is also up. I don’t know if this is true for all UI/Front-end developers but the comparison does kinda hold up at certain times.

    I would like to write more blog posts, especially for this blog, but my schedule really gets in the way. However, doing this will be one of many different things that I will be doing in the course of 2010.

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