The iPhone GUI PSD has been very helpful for designers / developers in mocking up their apps, although in some cases it’s proved a little too high-fidelity. For rapid prototyping we found we needed a more malleable approach. This is when we turn to the iPhone Sketch Elements AI. This collection of common iPhone elements in a sketch – like style allows us to easily and quickly mock up flows of custom wireframe screens.

Below is a quick example using YouTube of how we are using this quick sketch style to present flows to clients.

If you like it or use it, help us out by retweeting it.

Download The iPhone Sketch Elements AI Here (6MB)

(Font Requirement: To fully achieve the sketch style, you’ll need Tekton Bold — Freely available here)

Now that Apple has officially released the iPad we want to start designing for it. While Apple’s interface builder is great, it doesn’t really allow us to create custom UI elements on the fly. We decided to take a page from our iPhone GUI PSD and create one for the iPad.

The PSD was constructed using vectors, so it’s fully editable and scalable. You’ll notice there are a few new UI elements as compared to the iPhone interface. The workable screen design is formatted to 768×1024 so anything you design in the Photoshop file can easily be brought over to the SDK.

It’s 1.0 so I’m sure we’ll notice missing elements as we begin to use it. We’ll perodically update it to include new elements as we notice them or as they become available through any SDK updates.

If you like it or use it, help us out by retweeting it.

Download The iPad GUI PSD Here (24MB)

(Thanks to Finn O’Hara for the photo)

While attending FOWD last week in New York an overarching theme of Progressive Enhancement started to develop as more and more presentations preached it’s benefits. So what exactly is Progressive Enhancement? and how can we realistically use it and ensure our users and clients are happy with the end result?

Progressive Enhancement is all about delivering structured content to browsers and devices regardless of their capabilities, then adding layers of style and behavior that are progressively more complex. If you’re using a modern browser it will be able to render those complex styles and behaviors and deliver a beautiful rich experience. However, if you’re using a legacy browser or device, the content will be rendered to the best of browser’s ability with less complex styles and interactivity. The key here is that nothing breaks, it simply doesn’t look or behave the same in older browsers.

This probably sounds very similar to something web designers and developers have been preaching for years, Graceful Degradation. While they are similar, they have completely different objectives. Graceful Degradation has you building what the most modern browser can handle, and then ensuring that it degrades (or breaks) gracefully in older browsers. Progressive Enhancement on the other hand has you building for the lowest common denominator and then adding extra polish and functionality for browsers that can render it. Graceful Degradation has you looking backward, and Progressive Enhancement has you looking forward.

Why would you want to Progressively Enhance your website? Quite simply, you want to ensure that anybody who wants to consume the content you’re delivering can do so without getting slapped in the face with a broken unusable site. It will also lead to cleaner, semantic code which is easier to maintain and easier to upgrade (or enhance) at a later date.

Lets a take a look at a quick example. Here we have a pretty really basic nav with rounded corners, shadows, and a custom font. Normally we would build this using something like:

You can see we have code in there just to support the design, a div for the bottom corners, a class on the last list item to get rid of the last underline, and a container div to keep it all together. We would also have about 8 different image files for the corners, background, shadow and custom fonts. Don’t forget the PNG hacks to get everything looking properly in legacy browsers. All of that just to support a pretty basic design.

Ideally we would use something more like this:

Here we have clean semantic code with nothing but a class name (maybe) for the styling of this basic nav. No images are required for this navigation, we’ll let CSS take care of all the styling. Rounded corners, shadow, gradient background, custom fonts, and removing the underline on the last list item can all be taken care of with the latest CSS styles. I won’t dig into the CSS code for this today, but we’ll take a look at how this would look in different browsers.

As you can see, nothing would break and everything is still usable no matter which browser you’re using. If you’re using a newer browser you’ll see a little more polish than users with an older browser, and your experience will be a little bit better. Dan Cederholm used television as an excellent analogy for Progressive Enhancement. You can watch the latest episode of 30 Rock in glorious HD and surround sound if your home theater has an HD TV and a surround sound system. However, you can watch the exact same show on a 15″ black and white TV with mono sound. You’ll get the same content, and be able to talk about the same jokes around the water cooler regardless of what your home theater looks like. If you’ve invested in the latest and greatest TV and Audio gear you’ll be rewarded with a better experience. If you have a 15″ black and white TV, chances are you don’t care about that better experience, or at least understand why you’re not getting the best experience.

We need to use this type of analogy to explain Progressive Enhancement to our clients. Websites absolutely do not need to look the same in every browser. You can deliver an enhanced experience to users with the latest technology and not alienate users with legacy technology. The tricky part comes when you present a design with all the sparkle and polish to a client, and they can only see the basic lacklustre version of the final product because they’re using a browser that’s 10 years old. Finding a way to present the lo-fi and hi-fi versions in tandem will be key in selling Progressive Enhancement to clients, and moving web design forward.

Along with Apple’s official release of the new iPhone 3.0 software came a number of new graphic GUI elements. We’ve been holding off updating the Photoshop file until we could properly implement the additions. We built it using vectors, so it’s all still fully editable. Apple’s SDK is amazing, but when we need to mock up something quickly for a pitch we turn to this.

Some of the changes and additions in the 3.0 iPhone GUI PSD include:

• Map and map elements including curl
• Copy and paste elements
• Timeline bar editor
• Horizontal iPhone
• Horizontal Panels bars and keyboards

If you like it or use it, help us out by retweeting it.

New Version Available!

iPhone GUI PSD Version 4

(Thanks to Finn O’Hara for the photo)

h1. Magic Happens When You Give Smart

The 2008 holiday season was certainly a busy one for us and TELUS. Ads, ads, some more ads, a few signage pieces, and a little microsite kept us well occupied in the weeks prior to Christmas. Now, I won’t bore you with all the little details, but I did want to share a few of the pieces we created this past holiday season.

h3. Online Ads

The Q4 campaign was quite broad and required a large variety of ads. We created a mix of standard and rich ads, cross-talkers, a mini product-viewer, and even an ad where you can search Google on the phone… in the ad. You can see a few of the ads “here”:http://www.teehanlax.com/awards/telus_banners/, but we’ve also put together a little highlight reel to show them off.

h3. Microsite

I suppose magic doesn’t happen on its own… it’s really something that has to be manufactured, right? Enter the “Magic Machine”:http://teehanlax.com/awards/telus08/giftguide_site/index_en.html – a simple machine that helps you find the right smartphone.

Our internal team modeled and animated a number of scenes, all of which were dynamically assembled depending on the features you select at the beginning. We wanted to make the experience playful and if you use with the machine a few times, odds are you’ll see a completely different scene each time.

Check out this site for the Dutch Air Force. It’s not in English and therefore you’ll have to click around to really experience the site, but if you have the time to mess around, I suggest you check it out. Everything from the 3D transitions, the video integration, the photography… really well executed.

Credits
Concept and Project Lead by ARA
Design and Flash by Momkai
3D, Flex and Flash by IND

Source [cpluv]

One of the only UI elements in the past that allowed users to traverse multiple pages of results was pagination. There are few databases any of us interact that don’t use those “next” or “previous” links: Google, gmail, flickr, etc.

About a year ago I saw the guys at Unspace had implemented a nice alternative to traditional pagination. I should note that their work was based on something similar that was done by Humanized. These solutions load in more results as you scroll to the bottom of the page – No more next or previous.

As seen in the image below, the Mail application on the iphone displays a button at the bottom of the page that appends 25 additional results to it – an elegant solution.

What I like most about these solutions is that they are non-destructive, that is, when I select more results I don’t lose the ones I’ve already seen. I’d love to see more implementations like this.

Adobe’s latest and most compelling foray into rich internet application development, Appollo, is really interesting for a couple of reasons.

It combines proprietary tools and technologies—namely, Flash and Flex—with public domain stuff like AJAX, Javascript and HTML. The client-side component, a cross-platform runtime engine, allows developers to deploy RIAs that look and behave like desktop apps.

A few years ago, everyone was talking about how as browser-based apps became increasingly powerful and sophisticated, the OS might soon disappear. What’s interesting about this development is that it works in the opposite direction. Apollo makes the browser disappear—it does an en run around it. So my question is, if we don’t need the browser any more and the OS is also superfluous, what’s left?

The development stack gets a lot more complicated as technologies like Apollo make headway. Used to be that the browser layer was fairly abstracted from everything below it. Modern OSs now incorporate a range of web services-based APIs to bridge the gap; and again, what we’re seeing is a reciprocal move in the opposite direction. Apollo makes the Internet App central and allows it to hook into the desktop layer, presumably through an API-like model.

It’s interesting to speculate here on how Microsoft intends to compete. Remember when Lary Ellison was trumpeting Java as the great disrupter of Microsoft’s hegemony? It feels like history is repeating itself, minus some of the hubris that was flying around back then. Microsoft was able to effectively handle the Java threat, and went on to release its .NET framework and a RIA strategy centred around it’s Direct X suite of APIs. Part of Microsoft’s strategy was to let the Java thing run it’s course while focusing in the short term on promoting Javascript as a ‘good-enough’ alternative. Since then, Javascript and the community around it has matured quite a bit and now is a key piece in Adobe’s competitive strategy.

Another question: how will a development community that’s got somewhat of a proprietary feel for more open-ended technologies like AJAX and HTML feel about a corporate player stepping in to plug things together on their behalf? If Apollo gains support, it will certainly entail somewhat of a de-specialization or integration of specialization across the RIA dev. spectrum (e.g. bringing Flash designers together with AJAX and Javascript developers). I think that Adobe’s ability to do this will be a critical determinant in Apollo’s success.

One last thing—from a user experience perspective: what is the promise of a fully web-integrated dev stack that reaches right down into the core OS? What will these apps look and feel like? Part of the freedom that a separate web layer on top of the OS has enabled was the ability to re-conceptualize the UI. I’m not sure that the full scope of that promise has truly been realized, and wonder if it ever will as we begin to connect our web-based apps back into the desktop environment and paradigm. At the same time, we’re already seeing how web-based content hooked into the desktop can lead to a multiplicity of experiences (think media center’s UI, widgets and gadgets, etc.) co-existing peacefully. This is the prospect and maybe the promise of Apollo that excites me most.

Thoughts?