“This is a pretty great moment for Zeitguys,” stated Senior Partner and Creative Director Tom Auger, when he received the long-anticipated award. “It’s fantastic that an app that’s such a good cause for hearing well-being is getting this kind of attention. Hopefully this will just increase the app’s profile and more people will download it and test their hearing.”

uHear is a scientifically accurate hearing testing tool, with three different tests based on standard tests used by audiologists. It delivers accurate results and features a cool touch interface that encourages younger people to try it out and test their hearing.

The app, which can be downloaded from Apple’s iTunes store for free has been ranked consistently high in the Medical Apps category in the North American iTunes store. It is currently climbing in France and Germany since the recent release of translated versions. Unitron Hearing also offers a simplified online version of the uHear self-assessment hearing test, created by Zeitguys in Adobe Flash.

Zeitguys hopes that this recent exposure will encourage more customers looking to create innovative interactive experiences to contact the Zeitguys team and start the dialogue.

–

Contact Zeitguys at 416-966-4345, tom[dot]auger[at]zeitguys[dot]com

Headquartered in Waterloo Ontario, the Laurence Group of Companies encompasses 3 lines of business: Financial Services, Merchant Banking, and Real Estate.  This compact Flash website is designed as the jump off site into each of the Laurence Group lines of business.

This compact site window provided instant access to Laurence Group news and media postings; at-a-glance summaries of the Laurence lines of business; and multiple, easy to find jump links to all the Laurence Group sister sites.

The Laurence Group parent website also features a collected news posting are with quick highlights of company-wide information and continued quick jump-off links to specific areas of interest.

When Zeitguys teamed up with Isocell North America to create the identity and product packaging design for GliSODin Skin Nutrients, Professional Nutricosmetics,  our main objective was to convey to consumers that this product was indeed a premium one.

GliSODin Skin Nutrients packaging is printed on  Ice Silver, Curious Metallic stock.

1. Original Cucumbers
2. Savory Garlic Cucumbers
3. Hot & Savory Cucumbers
4. Hot & Savory Mixed Vegetable
5. Savory Mixed Vegetables
6. Tangy Turnips

As each product was to be placed in a clear round jar the form of the packaging would come as labels to be placed on the upper top portion of the jar. Each label could be similar in its overall look but needed to contain slight variations in colour (to compliment the specific vegetable being featured) and visual reference (in our case this visual reference ended up being variations in the illustrations).

However, like every design project in the real world there were restrictions.

1. The label needed to be large enough to display all the info but small enough to allow the actual product to be visible through the jar.
2. The labels needed to have a home made feel to them without actually being home made, in order to blend in with there surroundings as they were to be sold at local farmers markets throughout Ontario.
3. The colours chosen needed to be complimentary to the actual products within the jars

Besides the above Hratch was up for anything! So, where to start….after doing some research on food labels we noticed that in order to give this product that true homemade, natural feel we would need to incorporate illustrations. Which fortunately turned out to be a double great idea as it made the actual vegetables that were cut up and placed in the jars more easily identifiable.

After a few rounds of sketches and numerous colour combinations we were able to decide on a final series of labels that we felt were straight forward, had a natural, homemade feel and complimented the actual product. We also found that our design also permitted us some space to add in a small blurb about the Middle Eastern treats and what makes them so unique.

Overall this project from start to finish was great and tasty! No really I mean tasty…we were eating Toorshi treats throughout the entire process! Enjoy!

This project (or rather, series of related projects) snuck up on us: what started as the design and layout for the Humber Institute of Technology and Advanced Learning primary recruitment marketing tool became a complete style and branding program for the entire 2008-2009 recruitment marketing communications: bookmarks, posters, postcards, even a 30-second digital ad for movie theatres! Once we established the overall aesthetic and the visual idioms that defined the 2008-2009 “look” in the initial Viewbook design, the fun was in figuring out how to create “consistent” variations within those parameters.

A View to a Book

A college or university Viewbook is the primary recruitment tool that gets sent out to any student (or parent, or guidance counsellor) making an inquiry at that school. As such, the primary audience (as with most of the Recruitment marketing materials) are college-age students. However, to discount parents and influencers (such as teachers and guidance counsellors) would be a grave oversight, so in designing the book we had to find a balance between youthful innovation and mature practicality.

We realized that the text in this book was written at times for different audiences. This gave us the opportunity to play with different “voices” – a practical, conservative voice that was expressed in the main information copy, and a freestyle, first-person voice that comes out in the student testimonials and “Profiles of Success”. Bridging the gap between the two, the “flavour text” for each main section mashes-up both typographic styles.

Mixing it up

We looked at a number of local and national competing institutions’ marketing materials from precedent years and decided that we needed a fresh approach. Photography of students was (and still is) the norm, and indeed our client also wanted to focus on imagery of real students through their “Portraits of Success” series. However, we wanted viewers to have a more personal relationship with the content, so we devised a mixed-media treatment both for the portraits, and more generally, for the entire page layout.

Mixed-media is a very potent metaphor not only for the diversity of the programs offered at Humber but for the diversity of its student body, and for creativity and exploration in general. In each custom-designed spread we feature hand-drawn vector graphics, auto-traced vector silhouettes, greyscale and colour photography, painted natural-media backgrounds and digital brush elements created from photographic sources. Each Portrait of Success image background is actually a complex hand-drawn collage featuring subtle digital brushes created from elements that are relevant to that student’s story. (In the example above, the background behind Virginia consists of children’s handprints and reversed-out alphabet-block silhouettes, which are appropriate to someone in the Early Childhood Education program).

The grid lines and washes behind the main copy are a whimsical way of deconstructing the page layout build process itself and serves to create informality in the context of fairly dry informational material. All the background washes were hand-drawn with digital natural-media techniques. Each page is completely unique, with many points of interest and graphical “easter eggs” throughout all the while remaining structurally consistent and easy to navigate.

A complete campaign

Over the course of the Recruitment campaign and into the 2008-2009 academic year we produced a number of ancillary marketing materials that all carried the overall design aesthetic across a variety of formats and media. The challenge was to be able to create a visual shorthand that referenced the original detailed Viewbook designs without requiring the same degree of page-level detail. We were able to distill the stylistic guidelines down to:

• a mixed-media “chalk outline” treatment around a perfectly clean close-crop of the main subject, with an additional “gouache” darker halo or shadow behind that
• a vectorized silhouette of a relevant architectural or outdoor shot
• strict adherence to the Corporate style guide including colours and fonts
• sparing use of vector-based ornaments
• the hand-drawn gridlines with their light background watercolour wash for pull-out text areas

With these guidelines in place, each subsequent piece of collateral felt like it was part of a year-round theme or campaign and created a unified brand identity for the Humber Recruitment drive.

Today, Apple has released uHear, a slick application in the Medical category conceived by Unitron Hearing. The application, for which we designed the user interface, is a scientifically-accurate hearing evaluation and testing tool, with three different tests based on standard tests used by audiologists.

This was one of the coolest projects we’ve worked on recently as developing for the iPhone / iPod touch hardware is a very engaging process. For one thing, the specific restrictions around UI standards, screen size, resolution and performance issues all provided parameters that informed the final design. That, and the tactile experience of using the iPhone / iPod touch made us really want to focus on larger, button-driven interactions.

Pushin’ buttons

The buttons that proliferate the application were all Photoshop layer FX stacks that we custom-built for this app. There is no “rollover” state on the iPhone (unlike websites), but we did want to have “down” states wherever possible to really give the impression that you’re pressing a physical object.

“Classic” iPod revisited?

In our opinion the coolest set of screens in this application are the screens for the Speech in Noise test. In this test you have to first set the volume of someone speaking, and then you have to set the volume of some background conversation (while the other person continues to speak) to the point where you can just barely make out what the person is saying. We could have accomplished this with a series of sliders but sliders are so 2009. As we experimented with different gestures for controlling volume it occurred to use that Apple had got it right back in 2001 with their ClickWheel design – the thumb works great to adjust volume one-handed. Well, at the risk of being accused of copoy-cats we felt that it was time to bring the clickWheel back to the Touch generation. In fact, this innovative / retro UI component makes this one of the more entertaining screens to just play with.

Going on Safari

Although most of the development of this iPhone app was made using Objective C and the Apple iPhone Developer SDK, we did get the chance to bring in some of our expertise from web development into the app. It turns out that writing for mobile Safari is a breeze and a ton of fun to boot. For one thing, you don’t have to worry about cross-browser authoring, multiple screen sizes, Mac vs. PC etc! You’re developing for a very specific, limited and controlled platform so everything works every time. Wow. What a treat. Furthermore, you get to take advantage of all the great webkit CSS and JavaScript features that are available for Mobile Safari. There are a number of limitations though (at least as of OS 2.2) that were very frustrating and surprising. In the end, we went with a very Apple HIG interface that is designed to look as much like the rest of the app as possible (even though here you’re just browsing a web page).

When Romeo Salon & Spa approached us to do a high-impact “brochure” site, we thought this would be the perfect opportunity to wrestle with some of the challenges that are inherent when you shift navigational paradigms:

1. ensuring that the user realizes that off-screen content can be accessed by scrolling horizontally rather than vertically?
2. rewiring the middle mousewheel to horizontal rather than vertical scrolling
3. finding a way to provide the conventional, ubiquitous nav bar (even though all “pages” are actually all on a single page) that is still search-engine friendly and is not dependent on JavaScript in order to function correctly (ie: degrades nicely)
4. providing horizontal flexibility in terms of page “length”, based on amount of content
5. use semantic and standards-compliant markup as much as possible.

Well, we succeeded in 4 out of 5 of these points. On the last one we had to make a few compromises for the sake of project timing (and our own sanity).

Semantic THIS

In the end we had to admit defeat faced with the massive incompatibilities of Explorer in particular, though Mozilla and Safari gave us some grief in their own way. After three days of head-banging, the entire web team had lost 50% of our collective hair. We were trying desperately to do something using DIVs that would have been dead simple back in the “good old days” of table-based design.

In the end it was decided that for the sake of our health and mental well-being we would adopt a [gasp] table-based structure for the outer “shell” that defines the separation between each “page” in the horizontal layout. Sometimes you just have to do what works, especially when taking into account project scope and budget. In the end, the table structure, while not semantic, is thoroughly robust, completely cross-browser, and provides the flexibility and ease of coding that we were looking for.

Only the outermost structure is table-based. Its role is to divide a single HTML page into “panels”, divided from each other by full-height separators. Each panel is the analogue of a complete HTML page, in a traditional vertical site. Obviously, we experimented with inline DIVs, inline-box models, floats. All got us close in 3 of the 5 browser platforms we test for, but that really didn’t cut it. At first Explorer 6 was the recalcitrant one, and then, surprisingly, it was Mozilla that proved to be the real show-stopper. We were all amazed that Safari (and as a result, Google Chrome) behaved rather demurely throughout. Opera was.. well, Opera.

Designing a Predictable User Experience

Aside from all the technical mumbo-jumbo, it was really the UE that was of prime concern to us. The site is for a hair salon – its clientele is not necessarily one comprised of veteran web-o-nauts who are comfortable adapting to new UI and navigation styles. We knew we were taking a risk with the horizontal approach. Our biggest concern was that people might not immediately realize that the site was horizontally scrollable, and thus miss out on all but the first page of content. As a result, we made sure that our wireframes and the resulting design always had the following features:

• a standard top-left navigation menu that would work just like any other (although it doesn’t)
• imagery and text placed in such a fashion that it would be obviously truncated when the browser it at any of the standard window sizes
• handy “forward” and “back” buttons in a consistent spot on every panel
• clear visual separation between “panels”

Far more than the cool technical features, this attention to the visual cues that site visitors depend on make for a smoother transition to the horizontal paradigm. Users can’t really be expected to notice that their bottom scrollbar’s thumb has become enabled and to draw the conclusion that this should then be their primary navigation tool (although, in its purest form, that’s exactly what a horizontal website does, which is why this site works so well using thumb-scrolling gestures on an iPhone in landscape mode).

Poppin’ Wheelies

I don’t know about you, but I’m a mousewheel addict. Ever since I got my Logitech MX Revolution mouse (I actually made sure everyone at the office bought one!) I’ve been free-wheeling my way through web content. (Well, until the middle wheel gets stuck, which appears to be a pretty common problem unfortunately). So the first thing I expected to be able to do on the horizontal site was to scroll using the wheel. One would think that the browser, detecting that only one scrollbar was active, would map the wheel to the active scrollbar. That, as it turns out, is not the default behaviour. So I went about writing one.

Of course a lot of people have already done this. PPK in particular was very helpful (as always) and thorough (as always) in identifying incompatibilities. What is different here is in the way acceleration is handled. Generally, mousewheel scrolling is linear – for each “tick” of the wheel, say 5 lines of text are scrolled. Well this is great when you’re using the wheel to read down a page. But when you want to use the wheel to quickly scroll to a completely new panel, we’re either talking about a lot of scrolling (hello carpal tunnel) or some really fast scrolling (hello vertigo).

Acceleratin’

Acceleration addresses this: if you’re just trying to see what’s in the next column of text, a short scroll will do the trick. To get quickly to the next page, just keep scrolling a bit longer and the whole page flashes by. obviously everyone’s mileage will vary here, but we tweaked the values a bit and I think we got it right.

The algorithm is a simple one. Each “tick” of the mousehweel fires a discrete event. So, once a mousewheel event fires, we set a scroll multiplier and we store the exact time the event was triggered. If the elapsed time between this event and the previous mousewheel scroll is within a certain tolerance (we settled on 150 ms), the event is considered to be part of the same “gesture” and so the scroll multiplier starts to increase. As the scroll mutliplier increases, the distance each “tick” scrolls the page increases. So, as we get deeper and deeper into a gesture, our scroll velocity goes from one character at a time all the way to one panel at a time.

Cross-browser Issues

Well, no JavaScript would be complete without its share of cross-browser tomfoolery, right? This one is no exception. In fact, different browsers store the mouse delta in different properties of the event object, and to make things even more interesting, different browsers post different scroll amounts in said properties. So you have a bit of decoding to do.

IE, Opera, Chrome, Safari use event.wheelDelta

Moz uses event.detail (why, FireFox, why do you have to be the black sheep here? though frankly I prefer the use of the more generic property here).

The wheelDelta gang mostly post a fixed delta of +/- 120 (120 what? pixels? sheckels? this deserves a solid wtf), though Opera has a reversed polarity from everyone else.

Google Chrome posts a delta of 1200. This is pure foolishness. I expect that to change without warning at some unspecified future update.

Firefox posts a delta of +/- 10, and the polarity, like Opera, is reversed from the others.

So this is a mess. Obviously, we want to reduce this to a single unit to be able to perform our tick acceleration calculations. The following code does all that:

// figure out the direction of the wheel scroll and reduce to a unit delta
    var d = 0;
    if (e.wheelDelta) { /* IE/Opera. */
        d = e.wheelDelta / 120;
        if (window.opera) {   
            d = - d; // Opera is whacked
        } else if (navigator.userAgent.match(/chrome/i)) {
            d /=10; // you wouldn't want Google Chrome to be perfect, would you?
        }
    } else if (e.detail) {
        d = - e.detail / 10; // Firefox
    }
    d = - d; // (down is positive)

The last line reverses the polarity because I felt it was more natural to scroll right by mousewheeling down rather than up. Don’t you agree?

Smooth Scrolling and Smooth Degrading

The best JavaScript is unobtrusive – in other words, if your browser (and your preferences) will take advantage of it, great, it’s eye-candy, otherwise, everything should still work. When the GoogleBot comes to pay your site a visit (ignoring all JS) then you need to let it crawl around using standard markup, hyperlinks and all that good stuff.

So we first made sure that the the whole scrolling, menu, forward/back button thing worked with just plain hyperlinks. Named anchors on each separator did the trick, ensuring that when you jump to panel 3, you start with the separator aligned with the right-edge of your screen.

Once that’s all working, we come back with some JavaScript sugar and sweeten the dish.

The trick here is that we need to find (after the page has loaded) all the hyperlinks (your <a> tags) that link to a named anchor on that page. All other hyperlinks should be left untouched. Well, in order to differentiate hyperlinks that link to named anchors on this page as opposed to hyperlinks that may link to an anchor on another (external) page, I decided to start by building a “database” of all the named anchors on this page. If some hyperlink that we run across links to a named anchor that’s in our “database”, well that’s money. If not, we leave it alone.

The first thing to do is (once the page has loaded), parse through the document, looking for all named anchors. These will be things that we want to scroll TO, so we create an associative array (JS objects are all hashes in some sense so we use the old Perl trick) of all these named anchors. This is the “database” I was rather grandiosely referring to above.

var namedAnchorsObj = new Object();        

var linksAry = document.getElementsByTagName("a");
for (var i=0; i<linksAry.length; ++i){
    if (linksAry[i].name) namedAnchorsObj[linksAry[i].name] = linksAry[i];;
}

The cool part is “namedAnchorsObj[linksAry[i].name]”. If the name is, say “panel1″ then this goes into namedAnchorsObj["panel1"], which is also namedAnchorsObj.panel1.

Right. Well, the next thing to do is to go through all the anchors on the page that actually link somewhere, and see if they contain a reference (#) to any of our local named links. Conceivably we might match a false positive if some other external link happens to have the same named anchor, but hey, caveat implementor, all right?

The magic, my friends, is in the RegExp. If you don’t know Perl, well, learn Perl, but even if you think Perl sucks, you gotta love Regular Expressions. JavaScript supports RegExps since version 1.2, so we create a beautiful little RegExp like this:

var matchLocalLinks = new RegExp("#([^.]+)$");

And we use it like this:

// now, let's go through all the links on this page
// that actually link to the named anchors in the "database"
for (var i=0; i<linksAry.length; ++i){
    if (linksAry[i].href.match(matchLocalLinks)){
        if (namedAnchorsObj[RegExp.$1]) {
            var thisLink = linksAry[i];
            var namedAnchor = namedAnchorsObj[RegExp.$1];

            var linkClickHandler = function(a){ return(function(e){return localLinkClick(e,a)})}(namedAnchor); // encapsulate namedAnchor

            if (thisLink.addEventListener){
                 // correct DOM way
                thisLink.addEventListener("click", linkClickHandler , false);
            } else {
                // crappy old-skool IE way
                thisLink.onclick = linkClickHandler;
            }
        }
    }
}

And what we’re doing here is attaching the event method “localLinkClick(namedAnchorObject)” to every anchor on the page that links to a named anchor also on that page. You can define localLinkClick() to do anything you want it to do. In this case it starts a frame timer loop that scrolls the page to the position of that named anchor.

The line that defines linkClickHandler is a doozie, and I apologize for that. It’s something called an “encapsulation” and it’s necessary when you want to pass a parameter to an event. I’ve been using this technique for a few years now, through “creator” methods, but I’ve come up with this compact, inline form which, although it looks quite obfuscated, is actually a lot cleaner IMHO.

Finding Scroll Position

Ahh, another doozie. Luckily, greater minds than mine have been working on this issue, so I’ll just post the code and let you read the theory elsewhere.

function findScrollPos(){
    var x,y;
    if (self.pageYOffset) // all except Explorer
    {
        x = self.pageXOffset;
        y = self.pageYOffset;
    }
    else if (document.documentElement && document.documentElement.scrollTop)
        // Explorer 6 Strict
    {
        x = document.documentElement.scrollLeft;
        y = document.documentElement.scrollTop;
    }
    else if (document.body) // all other Explorers
    {
        x = document.body.scrollLeft;
        y = document.body.scrollTop;
    }

        return {x:x, y:y};
}

Well, I hope all this is useful and gets you on your way to creating interesting, usable, horizontally-scrolling web sites!

– Overclocked

The programs rollover pull out tabs make finding your way around the applications and making selections very easy.

Upon choosing and aid and the colour of the aid the user is able to select a model that most resembles them and view the aid on the models ear to see how the aid will sit when being worn.

The program also offers 360 degrees rotation to view different angles of the aid when placed on the models ear.

The zoom feature allows viewers to not only see the aid in detail but also see its placement on the ear.