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

Skip to Navigation

Tag Archive / web development

  • Charles is One Year(s) Old

    First Anniversary

    Actually, he’s a few weeks older, but who cares.

    I knew that it had been awhile until I started writing again in the Moleskin notebook I carry around. I wish I could say more but there was some much happening outside of the project that nothing was really done for about six months. Thankful, work has started again. In this case, I took a different tack and worked around what I do best: building and programming. So far, by using prototyping (IxD idea) to try out some of the ideas in the initial plans, I made some progress and new changes that should be an improvement down the road.

    A shout out to Todd Zaki Warfel for some much need inspiration.

    There is still a lot of work to think about and more concepts to play around with. I’m even examining a few ideas from almost five years ago because of one change that needed to be made for better functionality, which some refresher in PHP programming (long time…).

    As for the new design, that is still on hold. Finally asked another designer but he is busy as well (and just like me, can’t complain). But with the change in plans, that will wait until all the concepts have been played out.

    So basically, more work, changing ideas, better direction – which leads to a more upbeat tone about the project.

    BTW – Why the name Charles? I’ll tell all the worth while secrets when this is finally over, hopefully before 2011.

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

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