After my general protection fault with the alarm clock, I did manage to make it into Code Camp for the day.  Got to meet a lot of awesome people & attended a few good talks.  Of all the talks, the one that caught my attention the most was by Jason Olsen on MEF.  I had read maybe 2-3 paragraphs on this in the past few months, but after seeing the presentation he gave and seeing actual code, I’m chomping at the bit to use it.

Since I’m not in a writing mood at the moment, rarity that this is, I’m going to leave this entry at this.

Thanks to all made this possible, I’ll definitely be helping again next year, which I understand starts now! 

This post is great so I just had to throw a trackback into the fray.  If you want to know a thing or three about IPhone Development be sure to swing into Code Camp this weekend and check out that session or any one of the dozens and dozens of others that have been put together.

It's free, there is no reason not to come, and it rocks!  Plus I helped put it together so you know it'll be good!  ;)

So check out Rory's post and be sure to check out Code Camp this weekend. 

Ok, I know, you’re thinking “WTF BBQ Ponies, U R INSANE!”  The first response to that concept, that a developer would do design, is often one of “whatever, I’ll do it if I need to” or “yeah, it’s not that hard, I can just roll something together”.  After hearing a few statements like this is there any wonder there are a gazillion completely horrid, unusable, piece of shit, unattractive, company busting, business failing user interfaces and user experience designs that get implemented?

No, it really answers a lot of questions.

Developers often say they don’t need to do the user experience or design work, they just work in the back end.  Often I can see this though, as there are lots of uber A-grade nerds that do everything except worry about what the user is actually attempting to do with the data being requested, the information that is desired, and the end process of the business need.

This is a recipe for continual failure.

Agile processes, legitimate and honest agile processes remedy a lot of this as it requires working software for the end user be built regularly.  With this a lot of problems are worked out because the end user is able to fix and get what they want built instead of being lumped with a pile of code spaghetti application trash.

But beyond just the working software requirement, the manifesto could state simply that working software along with UX paper prototypes be required.  Get those users working with prototypes but also have a UX guru do paper prototypes and arguably keep doing paper prototypes during development.  This is pivotal to making truly usable, exiting, forward thinking and limit breaking software!

On this statement, I’ve dug in and found a few books to read on the topics that our Webtrends UX gurus read.  These guys are a-grade UX geeks like there are a-grade architectural software nerds, rare and hard to find.  Hats off to @skylark64, @parrfolio, and @justinogarrity.  The books as suggested:

• Paper Prototype, The Fast an Easy Way to Design and Refine User Interfaces, by Carolyn Snyder
• Designing Interactions, by Bill Moggridge
• Making and Breaking the Grid, by Timothy Samara (also referred to me by @illusiodesign)

So with that written, I have my reading cut out for me.  I’m off to the books.

Recently I've posted an entry on the Webtrends Developer Network blog titled "REST Web Services Synchronous Request".  This is a good example of synchronously calling services for the Webtrends services or for any REST based calls.