Thank you everyone for coming out. Welcome to the Content and Media Track on the Content and Media Track DRI. My name is George Areola. I'm one of the senior project line managers for OS X product marketing. It is my absolute pleasure to kick this portion of the track off, which we're going to be dealing with more design, Cocoa and web related sessions and we have the distinguished honor of having Kelly Goto, principal of gotomedia and Garrett Murray, senior developer of Blue Flavor, to give an interesting and in depth presentation on iterative Cocoa and web application development. So at this time, please give a large and loud round of applause for Kelly Goto who'll kick things off. Thank you.

Thanks George.

Thanks you guys for getting up so early. Well you know, just to start off, it's kind of interesting because Garrett and I come from different spectrums and I'm gonna approach this a little more as the project manager type. The person that's dealing with enterprise size teams, and I just wanted to get a quick show of hands, how many of you guys are here representing a large team that has to deal with Legacy systems or roll outs of application development over time? How many of your are enjoying your job right now? Okay, now how many of you represent the independent developer and you're here just kinda doing cowboy coding and cutting it out? Yeah? Okay, so we've got a little bit of a half and half here and we hope this session is fulfilling for all of you because, there's gonna be things that you say duh, I know that, but just like vegetables and working out, you know you're supposed to be doing these things right and so we wanna make sure that we reiterate some of the key points and tools and tips that we think are very important in this process. So just to get started this whole theme in the last year, maybe even more has been innovation and it's interesting because I look left and right and see covers, this is a cover that I picked up on an airplane coming into town.

Newsweek you know just, Business Week, everything innovation, innovation, innovation. Of course, Apple is at the top all the time and what are the secrets that these companies that innovate? What are they doing? How are they actually succeeding in this space? Now there's a couple things that come up, but one of them is really about listening to your customers.

So the other key thing that I'm gonna try and convey as I'm speaking quickly in the first part of this session, is that you need to listen to your customers. Now once again, you know this, right, but how many of you actually get out there and undergo either one on one interviews or usability tests with your customers on a regular basis? Please raise your hand.

So for the rest of you, as a take away, please remember that one of the goals is to iterate within their customers' space and continue to get feedback. This is kind of a great quote by the guy who start 3M and he's not started 3M, but he works for 3M, and he said, we listen carefully to what our customers didn't say and observed what they did.

So this is the other key thing, is that as we get into lifestyle design, we're not just designing for the web anymore, we're not just designing applications, we're not designing just for kiosks or for mobile phones, we're just designing for a lifestyle experience and so more and more, we need to get into the actual mindset of your customers and understand how they really live. And that's the other key thing that I wanna leave you as a take away. So just you know, some convergent technologies as you've got Apple merging with Utube, we've got content that's coming from different places and shapes and forms.

We have to think about placelessness and that's kind of a fun term that we're dealing with these days, is you're not just dealing with people sitting at their desks anymore. You're dealing with people that are gonna be watching your content at home, on the fly, on the road, on their phones and in every which way. There's also a lot of match ups going on in the 2.0 environment, not to belabor that because we've been hearing it hammered over and over this 2.0 world, what's going on.

But Google keeps announcing new ways and shapes and forms of allowing us to access our content in new and interesting ways and we keep passing the bar and keep going up and up and up. Well what's next? How do we actually integrate these products and services in a way that's gonna make our lives smoother and easier? Because we're actually not trying to complicate it so much.

So this is a diagram that we came up with about lifestyle design. Now the goal is really to be lifestyle driven, exceed expectations. But often times, you have these pesky investors or business drivers that make you hurry up a little bit faster and generally you have an app that's ready to launch but I don't know if it's ready to hit mainstream or if it looks great.

Now the goal with iterative development is to move up the scale towards the end result which is lifestyle oriented design that iterate carefuller during the process and I have to say that we like to evoke a lot of usability testing, contextual inquiry and research into the process until we get to this point where you hit lifestyle driven design and that's really the goal.

It's not just to make something useful or easy to learn, but it's to really effect people so that they want to, they encourage people to use things because they desire to use it, because it's fun. Because it's friendly. Because it's easy and it's simple. Getting to that point is pretty challenging.

So I kind of talk a lot about research and we do that a lot at our office and we started off just by talking to people and that's great. Talking is good, going out there, doing focus groups. I don't actually have any bad, anytime you can get feedback from customers is good, but we generally stay away from focus groups because we're just kinda getting people's opinions. Now how many people wash their hand when you leave a bathroom? Excellent.

Well that's a focus group. You guys think you wash your hands, but when you're hurrying to get into this session it's like oh no the line's long, you'll run in, they'll have a camera in there and actually you know, four out of five people do or three out of four or something like that. So what you think you might do in a situation, is a focus group.

So taking it to the next stage, asking questions, okay interviews, fantastic. Any time you can get in front of your audience, ask questions, one on one is way better. You're actually getting some questions now, getting into a little bit more contextual questioning is better because you're actually sitting with them at their desks or at their workplace or even at a cafe where they might be working. That's really great. The next stage is really watching.

Watching people as they go through their daily routines, spending a little bit more time with them, understanding why is this project or service that I'm trying to launch, why is this important to them. So many times we assume that our website is bookmarked, is the person's homepage. But as we get into a little bit more detail, we realize, oh, they have thirty bookmarks. This is not the first thing they do when they sit down at their desk every morning. We wanna actually observe and find out what they're doing, which is this, which is ethnography.

Now it's not true ethnography, I'm not a PhD in cognitive psychology or in social science, but what we try to do is introduce methods that are quick and easy and can be iterated quickly into the life cycle of the product or service that you're launching over time, so that you're actually getting into these people's lives and this is just a quick snapshot of a study that we did on mobile devices and this is the, you know, Singapore site of it.

But we actually did a study recently where we were in Finland, we were in Singapore, and we were in the US and we were actually watching and learning over a one day period and then we followed up with a five day photo diary where the people took pictures and recorded their thoughts and then we follow up with a two hour interview and you know, within one week you can get a snap shot of global products and services. Now how many of you guys are actually releasing things that are outside of the US? So it's interesting.

More and more of us are getting to that point and so we need to think about outside US thinking and it's really hard because we're so used to the way we do things, but even in a place like Japan or China, if you have a wireless device that goes within your house, how big is a house in the US? Twenty two hundred square feet, something like that. And if you go into Japan or China, the size of a person's household is about a quarter of that.

And so you have to start thinking about things also about desktop. We have desktop metaphors, well they don't have that. They use their kitchen in different ways. So it's very interesting to get context around the products and services that you're creating because your head's down into code and you need to look up and actually watch and observe people using your products or devices.

So what we try and evoke is this combining of agile and user centered design. UCD is a you know, an acronym of user centered design and really the goal is to merge those two practices. And I don't know how many of you guys are you know, currently kind of working in an agile environment, any of you guys? Agile you know and Scrub, any of you guys using Scrub right now? Any of you guys you know, just sort of winging it? So you know, we're gonna get into, Garrett's gonna get into process a lot more but, we don't really care what process you use, just as long as you're using it to communicate effectively with your team and also outside into you customer base.

So whatever process you use and whatever you can do to create a way of iterating through the normal process of agile, which is to do things within a short time frame, to keep your features and specifications light so that you can actually execute, to keep your documentation low and at the same time you are gathering input from your customers in every way, shape or form. Recently we did an interface for a Japanese client and it was a product that was released in Japan and all over the world and they came to us and they said, you know Kelly, we'd love to do testing in America and we said great.

You know, you know, we can recruit all these moms and grandmas and do all this, we said why in America when you're global? And he says well, you guys are the lowest common denominator. So we figure if you can use it in America, you can use it anywhere.

So that's great, because you know, we can return anything anytime, you know, we don't read instructions, all kinds of things. So it sort of turns out good. Now what we did with them is they had a life cycle of eight month development period and they still had a product to roll out. Now this was a hard product, this wasn't something that could iterate over time as a launch, soft launch or an application online.

And what we ended up doing is we iterated seven rounds of prototyping and testing, usability testing with five people, over a seven week period, seven times and then the eighth week we handed off our specifications to their team. Now I'm not saying each of you can do that, it was a lot of work and we had people running around like crazy, but we did the slam end user feedback during that very short cycle, knowing that we couldn't push it, push it, push it way out by months. And after the project ended, our Japanese client came to us and said, you've really changed the way we think about our process and we're gonna do things differently from now on. So that was pretty effective.

So today we have designers here. We have developers here. You know in the old world before CSS really came out, we used to have designers and coders that lived in different spaces and places, but really what we're merging towards more and more is a hybrid and Garrett is one of those hybrid designer, developer types that's able to think, but if you guys have a large team or even a small team where you have to take the design side, the UCD, user center design principles, and merge it with a development practice, we need to think about communicating in a new and different way. And that's also why iteration and process is so important, whatever process that you pick, because, you need to communicate effectively with people that think very differently than yourselves.

So it's an interesting conundrum that we're facing these days, as we get into rich application design and development and we start to move towards this new era of you know, 2.0. We don't call it 2.0, I'm calling it now web nouveau and web passe. Because I don't really like the term 2.0.

But anyway, you kind of have this rich application development and that's really the goal. So the end result is to think about your process as merging the best of user center design principles with agile development, iterating all along that life cycle and then coming up with a new process all along the way.

So that's sort of the take away, the beginning that I wanna get into from a high level and have you understand that there's many, many ways to skin a cat right, there's many ways to approach this. But what we would like to leave partially with you and Garrett has a lot more to say, is we want you to get feedback from your customers.

We want you to iterate and not do as much documentation but, to still during that time period communicate clearly with your team, and in the end, evoke a process that's gonna work within your organization or within your own mentality so that you can create the correct kind of products and services that are gonna merge with people's actual lifestyles. So that's my take away. And so I'd like to introduce Garrett, a rock star and Garrett has a podcast too, which I encourage you guys all to listen to but, he's gonna talk about process.

Thank you.

Yes, I'm gonna start with process. Good morning. So Kelly talked a lot about thinking kind of in a different way about products and this lifestyle driven development and really thinking about your users. I'm gonna hit a lot on thinking, which is kind of a weird thing to say. But I'm gonna talk a lot about thinking a little bit differently about how we develop applications, how we develop software, who we're developing for and kind of how iteration can make this process a lot easier.

Now, part of this is a little bit of a buzz thing and everybody here I'm sure has heard agile about five million times in the last year. And things like getting real and so there is a lot of buzz and it can be a little bit you know, when you start to consider should I change my process to fit these more agile methods, am I signing onto something that's more buzz driven? And the reality is there is buzz, but if you cut through it, you can get a lot of stuff done. So we're gonna talk a little bit about process to begin with here.

We'll start off with the waterfall. So how many of you are familiar with Waterfall? Okay so everyone. That's good. So a lot of people use the waterfall. Waterfall's a really common methodology, very commonly used, especially in large teams and so we talk about the waterfall, we talk about this pattern right here. We're talking about requirements, design, implementation, verification, maintenance. And the waterfall is, it can be successful. People use this all the time, it's very common.

So when we talk about iterative development, we start to talking about what's wrong with current processes. When we're using the waterfall, what are the problems that we encounter? And the most common problems that I've found using waterfall and that I've heard from other people is that waterfall is locked into absolutes. It's locked into long term planning and I don't know about any of you, but I'm a terrible long term planner. Especially when it comes to work. Work changes all the time.

So when we plan a whole development cycle, when we plan a whole design cycle, we plan a whole implementation cycle, we're making a lot of plans. So when we go through this app, what happens if during verification, we've got our full app, it's beautiful, it's been designed and we're in verification and somebody says, you know, this doesn't work the way we had planned or something didn't go right.

So what do we do? What's, what's the, what do we do now? Well a lot of the problem with the waterfall is it requires now that we go back to teams that are probably on different projects that have finished their work and we have to redo a lot of work and it's, it's, it's a waterfall effect quite literally even in this case.

Because when we go back to requirements and we make changes, we affect design, we affect implementation and we are not guaranteed these resources even to begin with. These people may be on a different project and on top of that, we're redoing a lot of work. So it's dangerous to have, to make everything one big plan.

And the truth of the matter is and what I'm getting at is you can't plan for everything and what this means, quite literally, is that your plan are very rarely equal to your users' plans. And things are very rarely equal to the way that you thought they'd be six months ago and your client's preferences almost never equal yours in the long term.

You know, your preferences when you're developing an application or you're making a large scale website, you preference is to have a good product. You're gonna develop a good application, you're gonna develop good code, you're gonna do a great job and you're gonna give it to the client and the client's gonna be happy.

Your business is development. Your business is application development. You client's business might be yoyos, you know. So as far as their concerned, all they care about is selling yoyos. So when you are looking at your development cycle and you're saying this is going perfectly, your client might be saying you know, we're not selling enough yoyos with the work you're doing. So your preferences are not, you're not aligned and even when you try to align your preferences, it's impossible.

Because you have different goals and your goals are to develop different product and their goal's to sell yoyos. And your plans are never equal to your user's plans and I know that this happens all the time, especially in software and non-web application development, is that people use your apps for things you never thought you would.

You know, people will release, spend a year on an app, release it and all of a sudden they'll get feedback from people saying this doesn't work the way I thought it did and the immediate reaction is well you're not using it the right way. But then what you realize is it may not be the right way, it may be totally different than your users may use it.

Your users you know, you may provide an Apple Script support and they may start doing crazy things with your app and asking you for support. So if you plan that everything's gonna be peachy and from the beginning it's all gonna be right, then you're gonna find yourself in a bad situation. So this hits on assumptions and assumptions are a big part of development. It's a requirement you know.

We write specs, we do RFP's, we talk to clients, a lot of assumptions are made. And there's a big difference between safe assumptions and unsafe assumptions. So we'll talk about some unsafe assumptions. The database won't change right. Everything's gonna be great. You know, I spent a week on this database and it's sweet right.

I got like fifty tables and it's perfect and then I'm perfect that's it, I never have to do it again. That's a crazy assumption and still happens all the time. I've made this mistake plenty of times. Features are locked is another assumption. Well we've got 1 point 0 set, got like twenty pages of documentation, so there's no way anything's gonna change. At least not until your user sees it. There's gonna be five users. The scalability is a huge assumption. Like oh, well this is an app design for a small internal team, so it'll never get any bigger.

Well what happens if the you know, the company starts selling lots of yoyos, I'm gonna keep hitting on that by the way, keeps selling lots of yoyos and then their team gets much bigger. You can't assume that it's gonna be a five user app and of course you can't assume softwarewise that you're always gonna be using something like Apache. If this app is dependent on one thing, it's an unsafe assumption.

And then of course there are safe assumptions. There is gonna be a database. If you're developing a web app, this is almost guaranteed that there's probably these days, gonna be a database in a web app and since there's probably gonna be some sort of an administration section, you're probably gonna have many users, maybe many more than you believed that you would have and it may be a safe assumption as well, as to say you're probably gonna use all open source tools right. Almost always, especially now, you can pretty much guarantee that.

So what we're driving at here is the core iterative development. We've talked about processors, talked about the waterfall, but there are many processes for iterative development. In fact, when I was doing research for some of the processors here, I was actually amazed to find you know, thirty, forty common process models developed for iterative development. But there is a core that we're driving at here and it's three parts. It's planning, which is requirements, analysis and design.

And then there is a broken, there we go, then there's development right. So this is the implementation and the deployment and deployment's a big part of this. Development in this case also includes pushing this out to users, to testers and then of course that gets to testing, which is evaluation. Now this in and of itself, is kind of like the waterfall. You've gotta you know, you've got a pattern, you're doing things in a processed way, but what's key about this is that it's cyclical.

Okay? So we're not talking about planning everything and we're not talking about developing everything, we're not talking about testing everything, what we're talking about is focusing on one thing at a time. One or a few, very few things at a time. We're talking about working on it in a cyclical pattern, planning, developing, testing, releasing to users, testing, testing, testing, feedback, more planning, development testing. And so there's many versions of this process, but the core of this is that we're gonna focus on one thing at a time.

And this is kind of one of the important parts, is that people are why process fails and what this means is that if you have fifty people planning one project, everybody's got different ideas of that. And so what being agile is, is it's about being flexible. Your customers are gonna change their minds about things, you boss is gonna change his mind about things, if it's just you, you're gonna change your mind about things. If you're anything like me, you're probably gonna change how you're doing it several times alone, just because you feel like oh, I found a better way to do this.

Things are gonna change, it's inevitable and attempting to plan and hope that things won't change, is gonna get you into a situation where you're out of options. So if people are why process fails, then we have to create processes that take into account the fact that these are people, right, that we're dealing with people. We're all people and everything's gonna change.

So what's great about, excuse me, iterative development, is that it allows for narrow scope. Okay and narrow scope is key here. And when you break things down into small pieces, they're easier to accomplish right. So as far as I'm concerned, focusing on things to me, equals productivity. I get a lot more done when I'm focusing on small things and I'm doing a lot of them. And productivity equals profit and profit equals vacations, which is kind of the goal right. Like I wanna go to Italy, I don't wanna sit in front of my computer twenty four hours a day.

And I think Apple requires that I say not a guarantee on vacations, because it's not. But the point here is that you, allowing for narrow scope and focusing on one thing at a time, allows you to get a lot of work done that may be overwhelming when you sit and you say I've got, here's my entire spec, here's everything I have to do within the next few months and when you break things down, suddenly it's a lot easier to accomplish things.

So ways to iterate. We're talking about the iterative development core, we've also talked about processes and there are a lot. Like I said, million might be a little high, but it's kinda close. So I'm gonna click through a couple of these and I'm, some of you may have seen these before, some of you may not, cleanroom, RAD, I like that name. Spiral, I think a lot of people have heard of before. RUP, I think is how you pronounce that, I'm not sure.

It sounds very scientific. XP is very common thing talked about when you talk about iterative development. XP as in extreme programming not as in Windows XP, which I don't think was done iteratively. I'm pretty sure.

You would see some of that stuff while you were testing right.

And scrum which is also and Kelly hit on scrum. Scrum is actually kind of becoming very popular and scrum's an interesting one and I'm not gonna talk a lot about it. We can get to it in Q and A maybe if we have time. And then there's cowboy coding right, which is like going nuts, I love that animation by the way. I spent like three hours on that.

It's difficult. So cowboy coding is really fun. Because you just don't think about anything right, you just go oh, here's version 2, here's version 3, here's version 4, your user's are like, what the hell's happening. ( laughter ) You know, like the testing part of it is almost people going stop, stop, stop, I can't figure this out.

You change things like twice a day and you don't even know what's happening sometimes, so you look at your code and you're like what was I doing yesterday.

Cowboy coding I think a lot of times comes also with drinking.

So you just sit in front of iChat, talk to people in code and release stuff. Cowboy coding can be a little dangerous, it's fun I don't know if any of you have done it, I actually recommend one you know you just try it one time just to kind of mess with everybody you're working with. Cause no one else can do their jobs by the way when you cowboy code. People are like do you need design, I don't know. No I don't care.

But what's interesting about cowboy coding is it's kind of, it's taking iterative to a level that's even extreme, which is that you really don't think about anything. You don't plan, you just work, work, work, release, release, release. So it's a little dangerous, but we're getting at here is that there's a huge spectrum of processes right and the difference you know, some are more predictive, which means they have a lot more structure and some are more adaptive which means they don't have any structure.

Obviously cowboy coding, line should probably be about five times higher. But what we're looking for here is we're to find something that works for us. Right? So part of the assumption saying here as well is that you can't assume that going into this, cleanroom is even gonna work for you the first time.

Coming into a project thinking this is exactly how we're gonna do it beginning to end, is almost as dangerous as assuming that there's gonna be a database with ten tables. Because I don't know, depending on the size of your projects and depending on the size of your teams, but you're not always even guaranteed you're gonna be on the project end to end.

Something may happen, you may need to leave, something you know may change, something may go wrong, you may need to bring ten more people on. So making assumptions about processes is that they're gonna last forever and this project you know before we even get into it, we're gonna use cleanroom beginning to end, is almost as dangerous as making other assumptions. And what we're getting at here is that you have to be flexible, even with your process selection right and being agile means that there is no lock process.

There is no I'm not cleanroom, I'm not stuck with clean room this whole time and especially if cleanroom isn't working for me. I don't have to stick it out. I don't have to suffer, the project doesn't have to suffer for me to get through cleanroom. You know, if we're in spiral and we're all feeling like it's out of control, there's no reason that you have to stay with spiral and part of being agile is deciding it's safer for us to make, to change things.

So I wanna talk about, a little bit about what I called in this slide the movement, which is a kind of a weird term for this, but part of what's great about agile development is there's a lot of, there's a lot of stuff happening right now to make our lives as developers easier and I've been developing for the web for about nine years and I've done some Cocoaa development and I've played in some windows development and I remember a time where it was very, very difficult to get into these higher level concepts. It was very difficult to learn programming languages. They were a lot more cryptic. And so what we're talking about here is we're talking about the movement, it's not only about processes becoming easier and agile development, we're also talking about people helping people get stuff done.

And everybody is just gonna know every single one of these frameworks and the reason for that is not necessarily even because of buzz, but because of how powerful this idea is becoming. That if we simplify the work that we're doing, we can actually get a lot more work done. So tools for rapid prototyping and building right.

Appkit. If you go back you know, fifteen years, you were doing a lot of work on your own. Appkit does a lot of work for you and WebKit might even be a better example right now, because of how popular bundling the internet is and how powerful the internet can be and building you know, web apps and using Java Script and all these things. And so WebKit allows you to drop a browser into your app and you know, you go back, I'm not sure which year WebKit was released exactly, but if you go back five, six years, people were writing their own browsers all the time.

You know, if you have an app that you need web browsing in, you're either gonna have to license something like Mozilla or you're gonna have to build your own web browser and so we've got five thousand different web browsers, just in OS X alone that are bundled inside of apps and each one of them renders slightly differently and each one of them handles you know, standards differently.

And so you look at tools like WebKit and you say okay, this is gonna remove the necessity for doing this work over and over and it's going to streamline the process and it's gonna make a lot of assumptions right. And this go back to safe assumptions. Safe assumptions, WebKit has features that most people who need the internet are gonna have you know. It's gonna have copy and paste, it's gonna have all the system level features, but it's also gonna have web features. It's gonna you know, it's gonna support CSS, it's gonna support Java Script and these are safe assumptions.

We're beyond rails is another very popular framework right now and there's a reason for it, it does a lot of the listing that you had to do over and over and over and it does it for you. And it's open source, so you you know, you're not, you can look at the source and you can continue to add to it and Django as well. Again in that same vein, web applications, building web applications, more rapidly with less rewriting and such.

CakePHP is on the PHP side. So there are many more than this, I picked just a few. And then there are tools for releasing also. Because releasing is a big part of iteration. So when you're developing your app and your rapidly iterating, you have to have a way to get this to your users and that way has to be as simple as possible and that's a key part of iteration, is that if your users have to do a lot of work to test your app, you're gonna get less good feedback.

Right? So making it easier for users makes it easier for them to submit feedback, which makes it easier for you to iterate, makes it your app better in the long run. So Sparkle is a huge thing right now and I remember you know, just going back even two or three years, if I wanted to find a new version you know, I'd go through my applications folder, excuse me and I'd be like oh I wonder how many of these apps have updates? You'd have to go one at a time.

You'd have to go to websites, you'd have to figure out what current version was or you'd have to, the app developer himself would have to he or she would have to build their own updating mechanism and how many of you by the way, are Mac OS X application developers? Okay, how many of you have written an updating mechanism of some sort? Yeah, that's what I thought. Okay, so like eighty percent of you. Now how many of you have used Sparkle? Okay, so the other twenty percent.

You guys should all talk. So Sparkle is great because it's this really easy to implement module and it does that work for you. It's very simple to update. All you have to do to update you, to update your build, is you drop a new version on the server, you update like an xml file I think it is now and that's it and it pushes it to users and what's great is that not only does it make it easier for you, which is key to development, it makes it easier for your users. Because all they have to do is click, install and we all know that installing apps on the Mac is easy right? Just drag and drop, that's great.

But, if you can cut out even the easiest part of it, then it's even easier. Users are gonna upgrade all the time and you're more guaranteed to get people testing newer versions. You know, one of the hardest parts about being an application developer is legacy support right. Supporting everybody who's using these old apps and trying to, trying to deal with that. But if you can push new apps and your throughput on pushing apps is much higher because of your tools, you're more likely to have users using your newest content.

And RubyGems is another example of this. It's not directly related on Ruby on Rails obviously because it's a ruby thing, but rails hits on RubyGems a lot. Because it's an easy way to create gems and push them out to everybody. And what we're talking about here is we're talking about the reality which is that rewriting things causes errors. Right? Every time you do something again, it's dangerous.

So talking to you guys again, how many times, does anybody in here write PHP at all? Okay, how many times have you written an SQL function or a class or something to handle dealing with SQL? Okay, just about everybody who's PHP developer. How many times have you done that over and over and over? Every single project, you take the same code, you tweak it, whatever? None of you? Oh okay, there we go.

Okay and then how many times have you written an SQL class or anything in Rails right. It's like zero times. Occasionally you'll have to add to it, but you very rarely have to write this stuff and in Cocoaa post-WebKit, how many times have people written web browsers right for their apps.

And what we're driving at here is this, you don't have to redo this work and when you do, you are reinventing the wheel and reinventing the wheel is extremely dangerous. It's dangerous monetarily, it's dangerous sanity wise. There have been plenty of times where I've sat in a room for a week doing something I've done a thousand times before and I'm thinking, why am I doing this, this is dangerous. I'm wasting my time and wasting my client's time. So if you don't have to, then you shouldn't and what we're talking about here is using commonly used tools to save time and time is key.

So part of this is, is trends towards human-riendly languages right. What we had is, before, languages were easier for computers. You go back twenty years and you try to read programming languages and it's, you have to be a scientist right. You have to know math, which I guess you don't anymore, right, no you don't. And you had to, you know, you had to, you had to really, you were like interfacing with the computer.

It's a little crazy, writing to memory directly, you know, you're doing all these swaps and it's very complicated and if you try to explain it to a layman, they were like, I don't know what you're talking about. And what we're realizing over time is that this is kind of a silly way to approach things,right.

So what we have now is we have program languages and tools that are easier for people to use. And the point of this really is that computers are built for processing. Why are we making it easier for them? You know, they can't leave the house, they can't go to Italy.

I can. So why are we making, this, a Mac Pro is specifically designed to crunch numbers, to do math, to do this work for you. So why is the trend to make languages that are harder for me? They should be harder for the Mac. And that's what we're starting to see now with languages like ruby, with popular frameworks with things like WebKit is.

Why are we forcing ourselves to do work that a computer's built to do? And the truth is, you can't upgrade your brain, but you can upgrade your Mac Pro right. It's like I can throw now like what it is, five hundred gigs of memory into a Mac Pro or something, it's out of control. But my brain's not getting any smarter. In fact, I think I'm kind of going down as time goes on.

So why am I sitting in a room struggling with a computer and begging it to do what I want it to do when I should be bossing it around. That's, that's the future right. We're telling them what to do. So the point here is that things need to be easier for us and that trend is beginning and it's getting stronger and it's very good for everyone who develops applications.

So let's talk about some real-wrld examples. So as I said, I'm a developer. I do mostly web development but, we're gonna talk first about some Cocoaa tuff. We're gonna talk about iGTD. I don't know if anyone's familiar with getting things done, it's a very popular movement. So iGTD is a Cocoa application, written by Bartek Bargiel, I believe is how you pronounce his last name and the point of this is to, is to you know, help users focus on their work.

And it's been downloaded many, many times and the reason that that's number is on there is it's kind of important and the reason that it's been downloaded so many times is that Bartek has a really open iteration policy right. So he builds like crazy, almost to the verge of cowboy coding in the fact that he's building so frequently and he's pushing it out to users all the time.

So he's getting constant user feedback and he's getting on the scale of you know, fifteen to twenty thousand users a month and that's a lot of user feedback and that much user feedback actually allows you to very, very quickly make changes that everyone's requesting and try new things and get a lot of user feedback.

So iGTD kinda has a built in ambiance which is great, it's great for Bartek at least, because iGTD, because GTD is such a huge movement right now. So here's just a really quick example of how iteration can be really powerful and this is a design example. And so this is iGTD as of I think two and a half months ago and at the pace that he develops, it's probably completely different now.

But, so we look here, we see a date functionality here and Bartek's a developer and he's a programmer and he thinks kind of more in a programmatic thing, so when he created this calendar functionality, he did it almost a way a developer would do it you know. People can write in their start date, they can write in their recurrence, they can you know, they can do it themselves and he pushes this update to everybody and his users immediately are like this is too complicated, I don't think the way you think.

And so what we're seeing here is we're seeing some research. He looks at the problem, he decides this is how he's gonna do it, he implements it and he releases it to users and testing begins and testing almost immediately gives him feedback right. So a couple weeks later or however long it is, we've changed functionality and this is based directly on user feedback. User feedback and testing.

Now what's also important about this is that this is not how he planned to do it right. So his plan, this is how I'm gonna implement the date and this should work and then he gives it to users and users say that doesn't work for me and it should be closer to like an OS X you know, standard the way that the calendars look in most other applications.

And what you have here is you have planning and you have design and you have development and you have testing and then you also have assumptions being changed right. I assume that it's, that every user will understand this and then you realize that users don't and then users need it a different way. So it's really easy for him, based on all this user feedback, to make these changes. To make them quickly.

So I'm gonna toot my own horn and I'm gonna talk about xPad. I wrote xPad in 2003. It's a universal binary now and the and xPad is focused on doing one thing and doing it well. And the point of xPad, for anybody who's never seen it before, is when I first switched to the Mac, I think in 2001 in early 2001, it's been like six years now, when I first switched to the Mac, I was doing a lot of work for various companies, various web development companies.

I was fixing a lot of old code and I think like half of you raised your hand about legacy applications earlier. So we're all in the same boat here. And I was fixing a lot of applications that were old, a lot of them were ASP based called fusion, things like this. Lovely, lovely languages.

And I would end the day, I would take chunks of code, sorry, I would take chunks of code out of applications and I would have, you know I would keep them because I was nervous as far as if I need to reuse them again and this is before a lot of my the places I would work would use SVN or what not and I'd have all this code and I'd have, I'd end the day with thirty open text files right, each with blocks of code in them that I wouldn't remember what they were, I wouldn't remember where they came from.

At the end of the day when I went to leave, I'd realize that if I wanted to keep these snippets, if I wanted to reuse them, I'd have to save thirty documents and I'd have to name every single one of them, I'd have to find a location for them and then in the morning, if I need to look through them again, I'd have to open thirty documents.

So I realized as a developer is I shouldn't have to do this at all. I need something that's gonna open my documents, I need something that's gonna save my documents, I need an easy way to just throw stuff into an app and be done with it. And this is around 2003 when the whole notepad thing in OS X was not very popular. So there wasn't really a solution for this.

So I decided I would look into creating one and initially I was gonna create one web base, cause that was my field and then I realized that the developer tools with OS X are free, which is kinda crazy when you're coming from a Windows world right. Cause visual studio costs like thirty thousand dollars or something crazy.

And you're paying for it and then you look at it and go, why did I pay for this. ( laughter ) So I look at my OS X disk and I say oh, Xcode is free, I think it was project builder at the time and so I installed it and I looked at it and I was like oh okay.

So I'm gonna lose nine months of my life and I did. And I just started working on doing this and what's interesting about this is I did not know coco at all. I did not know objective C at all and I used really simple iterative techniques to develop this application.

It took me about nine months and I learned Cocoa and I learned objective C and what I did is I focused on doing one thing at a time and in this case, it's an extreme example because, I didn't know how to do anything else. So when I was working with NS text viewer, when I was working with table viewer, when I was working on you know, features like mini bars and preferences, I was literally working for the first time in this technology.

I had no idea how to accomplish these things. I was reading tons of tutorials, I bought lots of books. And I iterated you know, in a way that was extreme. I focused on literally one thing at a time and sometimes it would take me days to get one thing working. But when I did, one more thing was done. So this was what xPad looked like in it's first public beta.

Like I said, it's extremely simple and you can see a couple of things here, this modified dates in a funky little view and it's kinda difficult to look at and then is version 1.0b. This is a couple of revisions later and it's a little more cleaned up. The bottom bar actually got more complicated, which again, this is user feedback and they wanted to know what category their document was in.

So I thought oh great, I'll just throw it in the bottom there, that should be fine. Well what you realized and what isn't in the screen shot is if you have a full document in this window, you have text lined up right along the bottom of that and all of a sudden it becomes very difficult to read the bottom line of text and that and also, how frequently do you need to know when you last modified something, especially in like computer language.

You know, with like a full date in a format that most people in the US don't even read dates in and the category is hanging out down there. So this is version 1.0 and version 1.0 is quite different and I added a drawer to the bottom and I moved the date into the bottom and I moved, I had categories still there and that was based on user feedback and you know, I've got a button to hide the drawer and we see here is that we've got a new thing appearing here and it's the word count and it's kind of an ironic story about xPad, but word count was not planned at all.

I had no plan for this feature. As I was developing the app though, when I got to the end I had this drawer, and I realized all of a sudden I wasn't constrained by what I had before, which was this tiny bar, I could suddenly put a lot more info into this, into this drawer and this is before the movement toward the semi-transparent black panels, but and drawers were awesome back then, I don't know if anybody, it's true. I could get two more drawers on there if possible.

Preference would have like six drawers.

They're so great, they're so cool, they slid out. Anyway, so when you look at the word count and the word count just kinda happened. It was like, I have extra space, what would someone who's editing a lot of text, who's not a developer, what would they do? And I started to get a lot of feedback from people saying, I need more tools for writing, which I thought was kinda funny cause I thought well, there's already text edit and there are Word and there's all these other things for writing, why are you gonna write in xPad and what people said is xPad loads in like you know, one tenth of a second.

Because there's nothing there, it's such a simple application, that it just pops open. So now it doesn't pop open, but it pops open even if you have tons of documents. It's very fast. Right? So what people were realizing is opening Word would take thirty seconds or however long it took depending on what computer you were using, xPad would open in half a second. Well yeah, Word's got a lot of features but if I can get my work done now, then I'll use xPad. So people were like word count is what I need.

So I had this space now and I had it iterated through this development process and I was like okay well, users are saying that they need word count, I'll do word count. So I put it in and it turns out that word count is actually kinda like the feature that everybody focuses on when they talk about xPad and I had no idea. I thought the highlight and the strike were just spectacular. People were like, I don't use that.

Word count is where it's at and I was, I was asking people why they needed to know how many words there are and everything, if people were writing with a lot of constraints and so I, that was my focus. When I put those in, I was showing testers and I was like highlight, they're like, no.

And then we see 1.2.5, which I released actually a couple months ago which is actually universal binary and we've got you know, some more OS X familiar stuff. We've got the unified tool bar look and this kind of shows more of what xPad looks like in use, some documents, some categories.

And so what we're talking about here is we're talking about the fact that I learned a language through iteration effectively. It's extremely powerful as a development process. Because I didn't know what I was gonna do, I didn't know what I was gonna have to do, I didn't know what I was gonna have to do to get in this, all I decided is, I'm gonna do this app and I'm gonna focus on one thing at a time.

And that's a unified tool bar there. Point that out. And here's another great example of iterative design and user feedback, is this is, this is the first, one of the first beta panels and you can see how much text is in this preference panel and I was very nervous initially that people wouldn't understand how to use my application, so I so like told them everything about it. Like the help was so literal that it was hard to read because it was like you click this and then you click this and then you'll be happy. And if we look at, actually this kinda goes in, these slides are in reverse order, that's even worse.

There's like three paragraphs there on the top thing and what you figure out is you get user testing, is that people are like calm down, you don't need to tell me so much. Some of these things are pretty obvious. You know, show, delete confirmation. It doesn't really need a full paragraph to describe it. And then you look at closer to the final and we're stripping out all that stuff and we're making it, making it much more simple.

We also have a couple more features that appear, because as we iterate and as we add features, we're able to focus on new features at a time. So when I hit my based feature set, I had a lot of user feedback of feature requests and some of them became really easily doable because I had done work before, that I wasn't planning on, that allowed me to do it. Word count was a great example. Suddenly I had space, it made sense and I could do it.

And now we'll talk about SimpleLog and SimpleLog is a Ruby on Rails application, that I also wrote. I'm a genius. ( laughter ) You came to see me. That's not true, you came to see Kelly. And this is cross platform, this is database agnostic, it's rails app. So it's been downloaded not very many times, I'm trying, I'm pushing it and that point of SimpleLog, it's a web app, it's a web logging application right.

So the whole point of this is again, much like xPad, is to focus on simplicity and focus on the core application process and one of the things that I talk about a lot when I talk and people don't wanna hear, is that things are too complicated, right. I think of myself as a smart guy, but things are too complicated and we have this habit, especially as developers, to complicate things even more even when we don't need to and we start out with new applications, we start out with new apps, we think of all the possibilities.

You know, we can, we can, we can put, we'll have core data, we'll have core animation, we'll have WebKit, AppKit, it'll do a lot of work for you and we just, we cram because these things are so fun, they're so interesting to use and we just cram all this stuff into it and that's called bloat right.

And everybody knows that word bloat, because you hear it all the time, you say it about other people's apps all the time, that's so bloated, my thing is so much easier. But the reality is we all, bloat is normal because we get excited about what we do. And so I've been writing a web log for nine years and I've used various things, used movable type and all these different things and I wanted to focus on writing. I have a problem with focusing, especially when it comes to writing on my website and one of the problems is that if there's too much stuff going on, I can't focus on the actual task, which is writing.

So I decided I was gonna write my own, my own thing and later, at the prodding of people who helped me test it, I released it. Open source to the community. So this is a great example of how I talk about things and then I don't do them.

Right? So this is simple op 1.0 and people would look at it and go, the word simple is very inappropriate because it's not simple at all, it's out of control, right, and it's a developer application. I looked at this and I was like, you can set every detail of a post, without doing anything. You don't have to go anywhere else. And you'd look at this thing and it's insane.

There's, why would you need to modify dates so frequently that they need to be the first thing. Like that's the most important part of writing an entry, is what date it was on. I wanna get that straight right away. And you know, there's just so much stuff here and I released this to testers and they were like, this is out of control.

So this is 1.1. Now, 1.1, a lot simpler. What I've done here, for the most part, is I've taken everything that's on the top that's not related to writing a post, I've gotten rid of it right. And I've moved it to the bottom. And we look at SimpleLog 2.0 and we're even simpler, right.

So now we've, we've moved all the stuff that was hanging around the top, all the options and actually if you look at this, you'll see at the top, that it says, SimpleLog colon and then has the options, as if I need to tell people every minute that they're using SimpleLog. Like don't forget, this is SimpleLog.

So these things like users would say, I don't need to see that, I know that it's SimpleLog. I'm not gonna forget where I am. And so we moved to, I moved to this you know, easier to read the top, the navigation is clearly defined, much more clearer than before and again, focusing on just writing. If you look now, you see title, body and tags. And the point of this is yes, there is a lot of developer or crazy stuff you can do, but it's all hidden, right.

So we've got a simplified top and we've got everything hidden in these collapsible things below and we focus on just the content. We've got the preview and we've got the actual data itself. Now, this is the preferences panel for SimpleLog 1.0b.

You'll notice I couldn't even fit this on a slide.

It's actually, I think I actually, you had to remove one whole section because I was like, I can't, like you know, it wouldn't let me copy and paste it in. This is out of control. But this is every single preference that I've created for the thing and I have a thing with preferences and I think a lot of people like preferences in general, when you get a new version of it and after you've seen your preferences, you're like all right. But then in the long run, you don't really use them most of the time and I have that problem.

Where I just create them like crazy. What if somebody wants to do this? They may never do it, but at least they could if they wanted to right. So this is out of control and again, much like everything else, testing is what is key. Getting someone else's sane opinion about what you're doing helps.

So this is 1.0. Now, again I went with the same basic idea of hiding stuff in collapsible panels and deciding what I thought was most important to show to begin with, but again we're still, we're still thinking about this from a developers mindset. I feel like it's important that you see all this stuff to begin with, but then I got feedback from people and they were saying I never change the text filter. I'll never change that, so why is it always visible? But I might change the extra stuff which has things like meta information which they may update their design and need to change their meta information, etc.

So again, things are hidden and this is 2.0. Now, the point of 2.0 here, the idea was how can I use commonly used, you know, metaphors that everyone uses, the people that used to to hide things but to make it easier to find and tabs. Tabs work for everyone. You know, years now, everyone's been using tabs and it's easy to understand.

So we put tabs in, everything's hidden, quickly switch between things, but really only show what I feel is absolutely necessary and to be perfectly honest, I'm working on a new version of SimpleLog and I've changed this again, based on user feedback. And so what I'm trying to say is that user feedback is key and it helps you do your job so much more effectively.

So also, talk about the Adobe CS3 Installer. I don't know how many people have installed CS3, if you have, you've seen part of this. This was built with WebKit by Blue Flavor and it's cross-platform. It's based on html web technologies and this is a really interesting case because we're starting to get to a point where we can use existing tools, everyone know how to use already, for things we weren't using them for before.

Right? So if you look at installing applications on the Mac, most people think of drag and drop and drag and drop is you know, the commonly used practice. But occasionally you do have applications that have to be fully installed and right to a lot of different places and even on the Mac, where there's not a lot of competition in the installer main space, you still have a lot of different ones.

And so what companies are starting to realize is that when they're writing installers, they're having to create Windows installers, they're having to create Mac installers, they're having to create, you know, depending on with Linux installers, etc. And they're rewriting a lot of different stuff in different languages and different installers and so what Adobe said is why do we have to do, why do we have to create this in a technology that doesn't already exist? Why do we have to like create this differently for every platform? Right? Why can't we use web technologies? Everybody knows that web technologies work on all platforms. They may be rendered slightly different, but for the most part, now you can kinda safely use web for everything. So this is one of the betas of the installer and this is all WebKit rendered, right.

So it looks like a normal installer, it has normal installer options, but the technology behind it is able to be portable to other things. So in Windows for instance, you use, I think it's Internet Explorer's tool kit, to render the same thing. So what you have is you have a single base for everything and that again, cuts down on rewrites and cutting down on rewrites allows you to change things a lot faster.

Because you don't have to do them for multiple platforms. You don't have to you know, test the actual content. You have to test the usability and everything like that. So, one of the things about working with Adobe though is that they obviously were not final on their look and feel for CS3.

We all know now it's the small square icons, the colors, the wavy colors. But back here, we see more of the CS2 look, which is the feathers and stuff like that. So it's never locked down until you get to close to the end So part of the development process of this installer is making sure that you take into account that this is not the way its going to look, even tomorrow, potentially.

And you know, Adobe has a team at, Blue Flavor has a team and everybody's working, and iteration allows you to work with a lot of people because everyone's only assumption is that everything is going to change. So we know that, tomorrow, this installer might look totally different so we're not going to plan that this is final and we're not going to plan that this is how everything's going to work.

And, of course, its not final, and you get into other things too, which are kind of interesting technology wise, is when you build an installer, there are things that you, everyone has to do, right. You have to choose a drive. A lot of times, on the Mac, you don't have to choose drives, but on Windows, it's a very common occurrence to choose a drive before you install, choose a folder, choose like 50 folders.

And so now we're doing web technologies, how do we do things that are commonly done with non-web technologies like drive selection. So these things are interesting, new problems that are caused while you're iterating and so you focus on these things one at a time. So when you start this out, you don't say, okay these are every single problem we're going to encounter because you don't even know yet. Like you know, maybe you don't consider the fact oh, I'm going to have to do drive selection. I wonder how I'm going to do that using Webkit. And you just focus on doing these things one thing at a time.

And so, everybody might recognize this one, this is from the beta, from public beta of PhotoShop and now we can see that the look is totally different. Right? We've got this blue look, the text is different, there's more of the, they kind of switched to a more simple look for a lot of their stuff.

And so again, we're not having to redo a lot of work because we didn't assume that that previous look was the correct one, that it was done. In fact, we assumed it was probably going to change almost entirely. And then we see the final and every, a lot of people who have installed this have seen this one, which is now we've got the branding, we've got the full name. This happens to be design premium, there are only like, I think, 40 versions.

And so we've got a final look and this process has allowed two separate teams, two different offices, albeit close offices, to work on a project that's cross platform that uses new technology effectively for what its doing, and to work together to create something over a processed time, right? So continually making changes until you, until you get done. So, take aways, just simple things that you can do today to start iterating.

Embrace agile methods, now that sounds like buzz, it sounds like I'm saying you know, something crazy. But the reality here is, this is basically saying start thinking about things like they're not set in stone. Start thinking about processes like its going to be different tomorrow. Start thinking that maybe you don't have to focus on the entire app right now. Maybe you just have to focus on one or two features, right? And that goes to avoiding feature creep.

And feature creep can be an immensely powerful and I fight this a lot when I get close to the end of projects, especially as I just start adding features and adding features for the sake of adding features adds testing, and testing, of course, adds more iterations. So you want to avoid feature creep and you want to focus on just one feature at a time.

And this allows you to get work done and to work succinctly, right? And you want to establish a realistic process and if there's anything I can drive at here, this is a very important point. Which is that you cant create process for the sake of process. You cant decide we're going to use Cleanroom and just use it until, you know, your company goes out of business, but use Cleanroom till the end. You know, you have to establish a process that works for you. And it may not be fully iterative.

That, that's a possibility. SCRUM is a very interesting example because its not technically fully iterative. It has this thing called Sprint Cycle, where you build up a lot of ideas and then you do like a 30 day sprint, I think it is. And that's kind of an interesting mix between more of a non-iterative development process and an iterative development process. And that may be the way that works for you. Well the goal here is to establish realistic process that allows you to use these tools which can help you get your work done.

And this one is my personal favorite. Its an acronym I made up. Its called GLUE and I want everybody to use this, just 24 hours a day. Tell this to everyone. Its, get lots of users early and this is key. And this is key for everything that you do, design, development, testing, everything. You need to have as many people using your work immediately as you can.

And this may be that these users are getting non-full quality assured work and that's a reality of development, right? Is that you cant always give people final product. You cant always, you never, nothing's perfect, right? So the point here is not to wait until the last minute and get 15 people and say here's a final app, test it.

Because they're going to give you feed back that's going to make you go back to the beginning, because they're going to say well, I don't even like how this works to begin with. What you need to do is you need to get users right away and that may be, for some of you who work in large teams internally, you're working on internal apps, that may be your coworkers. It may not be outside users, it may not be people who don't know how to use the app. But its still users. Its powerful to get people to use the app.

I always talk about how I have both my girlfriend and my mother test my applications and the reason is that my girlfriend is computer savvy, she's a magazine editor and she knows how to use a computers but she doesn't think the way that I think at all, at all.

Serious problem.

So and my mother, well is my mother and she's not computer savvy really, no matter how much I beg her to just understand that right clicking is the right side of the mouse and so I, but I give these things to them because it's powerful to get non-technical users using your applications. Because they're gonna give you feedback that you wouldn't even think of, even when you're asking normal testers right.

So when I give xPad to my girlfriend, she uses it in slightly different ways and then she starts using it all the time and then she starts you know, getting angry that I spent nine months, but she's using it and so it's a big problem. Seriously we have problems.

And so but, you know, you need to get users who aren't in your target audience. That's a very important part. People who don't know how to use your stuff. Because they're gonna give you feedback that you never expected. They're gonna say I don't know how to use this at all right.

So use GLUE a lot. Things like zero link building right and these are tools for iterating quicker. Zero link is a great technology because it quickens the building time, right. You don't have to do, you don't have to rebuild all the links and everything, you can pump out builds even faster and what's great especially if you're an internal teams, using things like Xcode, is that you don't have to go through a lot of processes for releasing to people. You don't have to package, you don't have to do that.

You can literally you know, send out builds over email or over your internal network or over iChat or whatever and you can get these things out to your users really, really quickly. Rail tests and script/console is another thing. Test driven development is a really great way to iterate, because it allows you to quickly test all the work you've done before. Which is a very important part of it as well, is you know, if you have to do less work to verify the things you've changed, then even better. So thank you very much and let's have George come back up here.

Thanks a lot Garrett, thanks a lot Kelly. So to wrap things up before we head into Q&A really quickly. For more information around Apple HCI guidelines, go ahead it's located on the Apple developer connection. John Geleynse is the individual that's responsible for that. His contact information is above.

Mark Malone who will be up on stage shortly also to help field questions, is responsible for all the internet technology evangelism now here at Apple, including the iPhone. So feel free to get in contact with him regarding any of the WebKits or WebKit related technologies, java script etcetera.