Category: Programming

  • Design and Usability: Part 3

    If the two words design and usability are mentioned together
    you can be sure that user testing will follow within a few sentences
    or paragraphs — at most. But what about the steps taken before throwing
    your design to the lions? Starting a web project implies collecting and defining
    nonexclusive factors that will influence how things will look, feel, communicate
    and function.

    You Don’t Start With Usability Testing

    I’m not talking about user testing (or user needs specifically), but
    rather generic topics that influence the level of interactivity, functionality
    and eventually usability. (Un)fortunately there’s no golden rule or set
    of axioms which can be followed or implemented during the development of any
    given web site or user interface — each project has different requirements
    (on all levels). For example: a news site is not an online shop and a weblog
    is not a search portal.

    Not having a preformatted or standardized list of (all) elements and details
    to implement at your disposal during the design phase, does not mean the entire
    process should be unstructured. I think a collection of global denominators
    can help structure the process and make sure the design fits the purpose of
    the web site (goals). Before I mention some of these generic factors which guide
    and direct (to a certain degree) a design process, let’s look a bit closer
    at how such a process would apply in practice:

    Structure, Guidance and Direction

     

    How Design and Usability Relate

    As depicted above — generic factors originate from external
    entities and variables (i.e. the world). I don’t think many projects
    would end up being successful if internal factors and preferences were to be
    taken into account exclusively. Design and usability flow from a sensible and
    balanced mixture of both internal and external information. Drawing from my
    own experience, discussions and projects with Dan, an academic article entitled
    What
    Is Beautiful Is Usable
    ” by authors N. Tractinsky, A.S. Katz, D. Ikar
    and comments
    made by Andrei
    Herasimchuk
    (who currently works for Adobe
    Systems
    and has worked on the interfaces for Adobe Photoshop, Adobe Illustrator,
    and Adobe InDesign), I’ve come to the conclusion that indeed “the
    perceived aesthetic quality of an object or subject is intrinsically locked
    with how users experience functionality and usability” (adapted from a
    statement
    previously made by Andrei). But I disgress…

    Dude, What About Your Generic Factors?

    I’m confident that every designer worth his salt has already come up
    with a few generic factors that influence design and usability decisions. Design
    and usability are eventually about communication and interaction (HCI).
    Below I’ve summed up some of the factors that could be taken into account
    starting a project:

    • Goals — What are we trying to do, both internally
      and externally? More marketing, more sales, more traffic, improved ROI, minimize
      costs, add value, inform? Know why you are communicating and interacting!
    • Audience — Who are we doing this for anyway? Teenagers,
      seniors, computer savvy, women, high-income, disabled, (or combinations).
      They all have their own characteristics. Know who your audience is!
    • Products/Services — What are we promoting or selling?
      Commodities, luxury products, information intensive objects or subjects, complicated
      services? Know what you are communicating!
    • Technical Requirements — What channels and tools
      will be used? Offline or online? Software, application, intranet, broadband,
      slow connection, mobile? Windows, Apple, Linux? Internet Explorer, Mozilla,
      Safari, Opera, all? Know how you will be able to communicate and interact!

    Above I’ve tried to answer four questions: Why? Who? What? and How? These
    generic factors will enable the definition of how design and usability will
    be implemented throughout the project. Does this mean we’ll get it right
    from the start? Not likely. We’ve merely established a hypothesis —
    we think or assume it might work out as planned. It’s at this
    point that you throw your design to the lions (the beta testers or an external
    pool of users). The latter is a process of trial and error — discerning
    and adapting elements that did not work as expected (back to the design phase
    and prototype) and keeping elements that have a positive or intended effect.

    This Is Not an Exact Science

    Naturally I’ve abstracted some elements or steps in the process. Furthermore
    design and usability are not exact sciences. Thus 1 + 1 often does not equal
    2; it’s more along the line of 1 + 1 equals something you didn’t
    expect
    . Feelings, opinions and perceptions play an important (if not decisive)
    role, but they’re subjective (difficult to structure). The best thing
    we can do is work towards an effective outcome. An outcome that is unfortunately
    constituted of factors, elements and drivers of which most are (partly or completely)
    unknown.

    So what’s your take on the subject? What factors do you take into account?
    Did I miss any? Where do you put the emphasis: aesthetic quality or functionality
    — or is there no trade-off necessary (both being intrinsically linked)?

  • Of Navigation Lists

    After finding Accessify’s terrific new tool List-o-matic, I decided it was about time I updated the primary navigation of this site to reflect my high opinion of unordered lists as navigation. In most browsers, you should not notice any change at all (unless you are viewing this site in a text-only browser, with style sheets off, or with a screen reader), however: if you are using a Mozilla-based browser (Firebird, Netscape, Mozilla, Camino, etc.) you might very well notice the same (minor) display glitch I’m getting on my test machines.

    The bottom of the navbar has a 1-pixel border on most browsers, but for some reason I can’t get it to work properly with the Mozilla family. This shouldn’t be rocket surgery, but I’ve now spent 3 hours trying everything I can think of to fix the glitch, to no avail.

    Part of the problem is styling the new markup to look the same as the old div-based markup, without breaking the rest of the existing layout. I just can’t understand why I can’t track this thing down (heck, it’s even working properly in IE5/OS 9!).

    If anyone happens to know what I’m missing, please send your suggestions my way. Feel free to just drop a note in the comments.

    UPDATE: After finding what I thought was a solution, then realizing the error of my ways (damn IE6, damn it to hell!) I have (for now) used a cop-out fix: I added a class to the first H3 in the sidebar, so I could treat it differently in all browsers. If anyone has a better solution (e.g. one that doesn’t require changing the markup) please let me know.

  • View Browser Source (AppleScripts)

    Our set of AppleScripts was mentioned yesterday by Zeldman, and was coincidentally updated to version 1.3 — for those of you in the dark, Webgraph’s View Browser Source AppleScripts (created by yours truly) fill a still-glaring gap present in all OS X web browsers: the lack of an option to view web page source in an external editor of your choosing.

    Our scripts solve this problem by using the AppleScript hooks built into most OS X web browsers, as well as a few clever uses of Unix apps like cURL, to pick up the source of the site you are viewing, and insert it into a new document in your text editor of choice (actually, the text editor must be selected from the list I chose to support, but I’ve covered pretty much all the usual options, including command line editors, and I’m willing to add text editors to the list upon request).

    They are really wonderful, if I do say so myself (I use them every day), and for folks like Zeldman, these scripts provide a much-needed feature not seen since the days of OS 9…

    Download your copy today, and let me know what you think — I’m always open to suggestions.

  • Zeldman’s DWWS Mini-site Bug

    If you check out Zeldman’s Mini-site for Designing With Web Standards with IE 5/Mac, you will notice a few differences when compared to the same site viewed in just about any other current browser: the secondary navigation (an unordered list displayed inline) aligns the text to the left, and each button’s clickable area is restricted to the link text, not the entire visible area of the button.

    I figured I could fix this, without requiring a new version of IE 5/Mac, and so I tinkered a little: Zeldman: DWWS BookSubNav Bug Fix.

    The fix above reduces the navigation to just the UL and its parent DIV, and in my testing it works in all browsers except Opera 6 (which breaks when viewing Zeldman’s original layout anyway).

    What did I do to fix the issues? I simply added a <span> to the button text, like so: <span>Home</span>

    That’s it! Now the buttons display properly on all browsers, since this addition does not alter the way the other browsers render the CSS.

    I’ve sent the changes off to Zeldman, so hopefully this post will soon be rendered obsolete.

  • CSS Layout Generator

    Two new layout tools have been released to the market, except these tools are free, and web-based: A 3 column CSS layout generator (float-based) and a 3 column CSS layout generator (absolute positioning).

    These tools allow you to adjust major settings in the layout, and provide you with the finished code to copy and paste when the layout is to your liking.

    Both generators produce Netscape 4-compatible CSS (for those of you still unable to wrestle free of its wretched grasp), and both incorporate a header and a footer into the layout.

    (via Zeldman)