Norman Richards talked about his experience programming the iPhone app for the web site funmobility.com . What he discovered is that things that seem trivial to do in a UI (setting the background color of a table for example) are immensely huge problems to code… The golden rule for designers for now is to stick with what you can do in UI Builder. Another problem was that some of the designs assumed features that are not in the API… so designers, make sure that you know you can get the data you want. Also, some of the data tables that the customer wanted had to be customer coded even though they were not that complicated because the iPhone table classes could not render them.

Sam Griffith talked about the advantages native apps. Much faster, hardware access, event handling, multi-threading. Talked about core animation a lot (something I need to look into). And from a marketing standpoint, “People are not going to find your web app on the app store” .

Sam and Norman talked about multi-threading and how you have to be super careful about the UI and multiple threads.

One big limitation for designers is that you can only use one font in a text field/area. Otherwise you have to write custom code and it gets painful fast.

There is no Core Image on iPhone. This means you can’t do things like glow easily, which is something that is simple in Cocoa on a Mac.

Chris talked about his iphone app he coded for the iphone dev camp. One thing is has discovered is that there is a difference between speed on the iPhone sim and the actual iPhone. Also, best to do clean installs on the app each time you install your app on the iPhone.

A non-techie asked me the difference between iPhone web-apps and the new app-store apps. Seeing as how the Facebook web-app and native-app look so similar, the question is a good one.

The main difference is that native-apps can access all the cool features of the iPhone (GPS, acceleromoter, address book, camera, etc) while web-apps cannot.

The downside to native-apps is that they are far more complicated to develop unless you are a seasoned Cocoa developer. So wouldn’t it be great if there were a way to code a native-app using the more familiar web-app technology? Well, now there is!

At iphone dev camp, some guys came up with a framework called Gap that does just this. It basically allows you to run your web-app as a native app, and gives you hooks into the Cocoa stuff via javascript. Awesome idea! This will open up iphone native app development to a TON of new people with great ideas.

I was at the iPhone dev camp all day Saturday. After sitting through an hour of pitches from the event sponsors (funny, only one company seemed to give away schwag) we worked through a Cocoa tutoria.

My first impression of Cocoa programming is that it is a computer science major’s dream, full of references back to Smalltalk and C. They even talked about preprocessing in the tutorial. Ouch. What is exceptionally different about Cocoa is that MVC is built into the language itself. Java and Rails implement MVC in frameworks, but MVC is not built into the language itself. This was a very strange concept for me and made it hard for me to truly understand what was going on during the tutorial.

We spent some time with the Interface Builder tool, and that was awesome. This tool allows you to build desktop and iphone apps visually. It was extremely easy to use, but to bind data to the controls was really difficult. This was again most likely due to me not understanding Cocoa.

We then saw a demo by Norman Richards about how to take the tutorial application from desktop to iPhone, and that looked pretty straightforward (if you know Cocoa). He even put the app on the phone itself, which was very cool.

Overall I am impressed with what Apple has created for iPhone development. For web developers who are thinking about getting into this, I have to say that the learning curve for Cocoa looks pretty steep, so be prepared.

When I used to run cross country in high school, one of the things our coach taught us was to “run past the finish line”. What this meant was that we were to picture the finish line 10 yards past the real finish line. As a matter of fact, she would always stand there at the revised finish line and scream at us until we bolted past her . The reason for this was that she wanted us to finish the race strong and to not slow down before the finish line.

So what does this have to do with interface design? A lot, really. I see so many web sites and software applications that let you accomplish your task and then completely kick you to the curb, not anticipating that you most likely want to do something with the “thing” you just bought/created/etc.

For example, I recently tried out Screen Flow, which is a screen recording program that allows you to create amazing product demos and tutorials. I think Screen Flow is an amazing, best-of-class product. Really. It allowed me to create a great demo with ease. But then I needed to get the movie into a web page. Surely, there must be an export feature that sets this up for you? Nope. Nada (at least that I could not find it). So there I was, with a movie file and just no idea how to integrate it into my web page. This lack of an export feature made the experience frustrating, even though the software was amazing at what it did. Ironically, it would probably take a programmer a few minutes to add this feature.

Another example that comes to mind is my old Motorola Q phone. It had a feature that allowed me to connect it to my laptop and use it as a wireless modem (something the iPhone still cant do). This was an awesome feature, but incredibly difficult (if not impossible) to set up. Fortunately, an enterprising programmer saw an opportunity and created a program that simply set this up for you and charged $34 for it (which was totally worth it). Its funny to me that Verizon did all the heavy lifting but because they did not do the last 1% of the work, all the functionality was lost to their customers.

So the next time you are designing a feature, move the finish line a few yards past the “real” finish line; ask yourself “what’s will the user want to do next?”. Instead of “kicking them to the curb”, roll out the red carpet.

I worked with Phil a long time ago at Metacreations. He was the main interface designer (along with Kai Krause). Here is an interview with him about what brought him to Adobe – and what he learned from his time at MetaCreations designing rule-bending interfaces for software like Bryce and Kai’s PhotoSoap. He also gives some hints at some possible directions of the Lightroom UI, and his philosophy around the evolution of user interfaces in general.

I know we call work “work” for a reason, but a lack of play in the design process can lead to less-than-stellar software.

Most large software companies follow a strict waterfall methodology:

Requirements > Design > Code > Test.

In my experience, designing and coding cannot not be totally separated.
The idea that designers can design something in wireframes or high-fidelity comps completely is just wrong.

The problem for designers is that at most enterprise software companies, the code is too complicated for them to “play” with. There are build scripts, large and complicated databases, xml configuration scripts , etc. Even if the designer is technical enough to grapple with all of it, most of their mental energy and time is devoted to the technology rather than design and creativity.

A solution that I have used is to create a “lite” version of the software that does away all of complex business logic, ant scripts, xml config files, etc. Just a simple database, php/rails/etc and the interface. This gives me a sandbox to play and experiment in, and always allow me to come up with a better design than I had come up with in wireframes. As a side benefit, the server side programmers can grab my html/css directly from my prototype.

As a matter of fact, thats why I think so many small web 2.0 companies come up with such amazing stuff. The designers can actaully get in and code and play. And I bet that what we end up seeing is pretty different from what they started in mind with.

Imagine giving a kid a set of legos and telling him he has to draw it out and then build exactly that. That would be boring for most kids. Kids will start with something in mind, but through imagination and play they come up with something much cooler.

Let the designers play I say.

This guy recreates childrens paintings in photographs. Just beautiful.

I actually did some design for the HP touchscreen computer while at Frog Design… great to see its finally coming out!

As a side note, its cool to see that Gizmodo is giving props to Frog for its role in the product. I hope that in the future people buy digital products based not only on the brand name, but also on the interface and industrial design companies involved.

I have been working designing Flex-based applications for the past year or so, and in that time I have come to the conclusion that skinning Flex apps is simply too difficult for all but the most technical of designers.

To change the default appearance of Flex, there are 3 ways:

1. You can “style” the interface with CSS - with this method you can make superficial color and font changes.
2. You can “skin” the app using you own graphics; this allows you to make cool and unique
   interface like Slide Rocket
3. You can “programatically” create a UI (this is incredibly hard, time-consuming and impractical for almost all projects.)

So approach 2, or “skinning”, is the way to go on most real-world Flex projects. One of the major drivers for Flex was that most dev shops stayed away from Flash because of its timeline based UI and its proprietary binary file format (which meant you could not diff 2 files). Why then, is skinning Flex applications still highly dependant upon Flash “Symbols”? You need to create these symbols in Flash or Illustrator, and then map these Flash symbols to your MXML controls via CSS. Got that? What a mess!

Even though Adobe says that CS3 has integrated Flex Builder with Fireworks, Flash and Illustrator, the integration is just laughable. In my experience, trying to use these “features” makes the workflow more difficult and confusing because information is lost between the modules. My favorite integration feature is in Fireworks. You can create a basic Flex layout and choose your colors and fonts, and the new “feature” in CS3 is a link that launches the Flex Style Explorer that has existed for years… and then, get this, you tweak the Style Explorer to try to match the work you did in Fireworks! Lovely!

If you want to see how hard it can be is just to skin one button, check out this tutorial on making a “highly” customized skin.

There is a pretty easy method to making a cool, somewhat customized skin for a Flex app, go get this Illustrator-based skin template , use Illustrator CS3 to modify the colors of the skin, save the new vector artwork as a swf file, and then load the mxml file into Flex builder to see the skin in action. For more information about this technique, you can read the tutorial at Adobe. In my experience this is the easiest way to make a custom flex skin.

Luckily Adobe realizes skinning Flex apps is too hard for most designers and is working on Thermo, their next generation IDE for RIA interface building, but its very annoying when they market all of this as an integrated solution.

Ryan Stewart has a great post about how to add sound to user events in Flex. Sound is such an under-utilized media in web-based applications. When I worked at Frog Design we hired sound designers on various projects and it’s hard to convey what a huge difference it made. The sound design definitely made the applications easier and more fun to use.