As a followup to “Design an Application like a movie” I wanted to highlight the fact that design and interaction design has become the new standard. Today it is very hard to ship an app or propose an app without a fluid, cinematic user interface. Sure there are still areas where POF (Plain Old Forms) will do but more and more design++ is the new requirement.
If you look at all the leading applications and platforms, cinematic and well designed is built in. Iphone has it, Pre has it, Twitter clients have it, Safari has it, Kindle has it, OSX has it, even Windows 7 has it. This level of quality is really the new baseline for releasing an application for end use. Users really require a simple easy to use visually pleasing system for daily use.
At Adobe we have been working to shift apps from being developed to being designed. If you take a careful look at Catalyst it flips the % of design and development work within an app. Where development was 80% of an app, it is now 20% and Design/Interaction was 20% is now 80%. I have long thought as a platform Flash needed to better leverage the designers on Adobe’s platform (10M+) and combined with an ecosystem of developers above 1M+ we would reach critical mass. In essence, Catalyst is game changing as it allows design to become the defining factor.
Now folks can dispute the value of how things are designed or the usability of product ABC but design and interaction are here to stay as the new requirement of anything software.
When an end user steps up to use an application, the whole experience end to end is like a movie. The user does this, then does that, and then that other thing all using various states of an application. Now although different users perform these scenes in different order, designing each scene should be thought about with the same precision as designing a movie scene. We tend not to design around usability like this, instead we think about the raw things the user needs to do rather than the whole scene experience. I keep wondering if an application would be more usable if there were a script written for each scene of the application. Instead of building use cases, you would build a script to visualize the user completing tasks end to end.
I find it interesting that both Director and Flash as development paradigms based on non-linear timelines/scenes, more so, Flex and Catalyst have adopted a development paradigm largely based on application states. Thinking about an application in terms of scenes or states can really change the overall usability of your application. How do the states flow together, what does the user during each scene, and do these scenes flow together well?
Adobe recently released a new toolset for scriptwriting called Adobe Story. The toolset is based on Buzzword but is specifically designed for script writing. The hidden agenda of the app is to get scene metadata into a video production workflow at the very start of design which leads to a cool end result over the production whole. I am going to explore designing an application using Adobe Story to see if the paradigm works for application design as well as it does for scene design and scripting.
Regardless of how the experiment turns out, I think my Actors, Roles, and Scenes will be better thought out.
I have worked for Adobe for 3+ years now and it remains a really great place to work. It goes without saying that I love my job but working for a company redefining web, design, and applications is awe inspiring. Recently I had a case where my personal software development collided with Adobe’s IP policy for employees. See I have been exploring other platforms and learning Objective C for iphone development on the side during non-work hours. My hobby has resulted in a few iphone apps being developed, 5 to be exact. As an Adobe employee I signed all intellectual property rights to Adobe when I joined the company, which is smart of Adobe considering that the entire value of the company walks in and out of the doors every day. When you manage that much intellectual property, policies like this are just good smart business. So when I went to publish my iphone app, I talked to my manager which started a long process with HR and legal over what to do.
Who owned the iphone app intellectual property?
Was it possible for me to own it even given the work was done during non-working hours?
So the end result was the creation of a new internal process at Adobe where any employee can apply for IP rights for their creation. I applied and have been approved for the 5 applications I am writing and Adobe has granted me IP rights for all the apps. The gesture and support mean allot to me and the result make Adobe a much better place to work. Better still the projects, although personal, have really helped me understand the market and the need for Adobe to monetize applications and the need for a first class developer program.
If you have every thought about working for a great company, take a look at working for Adobe, it is a great place to work.
So the first app is called GolfLevel and it is the first golf green reading application for Iphone. It is a fun app that gives you an accurate read of the golf green to improve you putting. What is cool is that every bitmap within the app was built with FireWorks saved as PNG. You can check out the app here
The next app BallStar (game) should be approved this week. I will post on the app when it hits the appstore.
One of the key parts of software development is problem solving. Like most problems in the real world software, problems can be broken down into many nested smaller problems and thus become much easier to solve. Breaking problems apart requires a deep understanding of the problem at hand and in many cases this is actually 80% of the problem itself. Once you understand the problem, writing a solution is pretty easy.
In my experience, to fully understand a problem you need to wrestle with it a bit. This requires some level of a throw away solution as you learn how something works. I tend to plan for throw away versions when major problems are identified within a software project. Generally it pads the development schedule and gives ample time for understanding and solving problems. Many lump these together as one thing but in reality understanding a problem and solving it are very different things. The only thing you need to watch out for is when “understanding the problem” code make it into a main build when this should really be rewritten.
Have you ever lost code? Why is it that you can recode a solution so quickly the second time? The second time you understand the problem at hand and solutions are easy to write when you understand them. Better still the 2nd solution tends to be more thought through and is most often cleaner with optimization built in (vs created early, read evil).
Breaking problems into smaller parts can be very hard to do. Getting from A to G requires you to solve BCDEF but what are BCDEF in terms of problems? I tend to make a procedural list once I have identified the larger TODO. A-G is a TODO item but solving BCDEF isn’t. I typically make a check list of the things that need to happen to solve the TODO level problem. It helps me see the smaller elements in context with the larger problem. In many cases these smaller parts are helper methods and small data management tasks or UI related tasks. Here is a simple case:
Load DataGrid with Data
1. Create http networking
2. Make call to server
3. Create server result in XML
4. Return result to client networking
5. Parse result data set
6. Clear out data in DataGrid Component
7. Create Typed Objects from XML data results and Add to Model
8. Set Model to DataGrid
The todo is simple but the checklist within really reads like code. I typically make the checklists for any solution inline as comments and write code around them. It provides some structure as I write code and the nature of the problem is within the documentation/code before I write any logic. This also allows you to build test cases and really helps close the quality gap. You need to know for sure that a problem is solved and testing is the only real way to know for sure.
So in a nutshell, break problems into smaller problems and plan to write some “understanding the problem” code before you write a solution. These simple steps have really helped me write logic faster with fewer errors over the years and I am sure it well help you solve the many problems you run into.
In 1996 I found myself ocean kayaking in Patagonia Chile. Our group, 15 of us, would wake at 5am to paddle from point to point across many small island inlets on the 30 day kayaking trip. The experience really stuck with me as we had to be very careful watching the weather conditions whenever we crossed open water. Crossings are the most dangerous element of ocean kayaking as you are exposed and weather can rapidly change for the worse. As strange as it sounds, this experience is identical to management of risk in a software development project. This model, development islands, has provided me a great way to think about software projects and the risk bearing decisions within the development process.
I have always found it ironic that in order to make progress writing software, you actively need to destroy/break the software you already wrote to make progress. At any point during development, 95% of the time software is in a non-working state becasue as you code, software clearly is broken. These areas during development I call crossings and the islands are the safe stable builds within a project. Looking at the larger picture software projects can be thought of as a large series of crossings between islands (stable builds) heading towards an unknown island where everything works perfectly. Here is a picture to help:
Obviously a project starts somewhere and makes build after build until it is complete. Along the way the project can fork into several parts so teams can work on aspects in parallel or at times things can fail. With every crossing you get closer and closer to this ideal endpoint yet at every part of development the project is at risk.
In looking at the larger picture, the ideal case is to make many small crossings where the build stays functional as much as possible. I do not believe that a project should ever reach an unworking state and that a developers role is to constantly have a safe island to return to and begin another crossing should one fail. Under this model the crossings represent feature/aspect development time and help you think about the many decisions on how a project gets broken apart. I use todo lists to define these crossings in advance of development but seeing things like this really changes the strategy. Breaking development tasks down into the smallest possible crossing becomes the key to the system.
How quickly can you get part of this problem solved into a stable build?
Can you build part of the project without the larger whole and integrate it in later?
Is this a component that I can license/reuse to save me development risk?
So next time you crack open a project, think about it in terms of Development Islands. Development Islands has changed how I think about projects, how I plan them, and how I executed them in development. Hopefully it will help you too.
And next time you get the chance go ocean kayaking, you will see what I mean. :)
Over the past few years I have found that keeping an updated prioritized TODO list for app development is really essential. The TODO list habit started out of the need for me to stay focused but evolved into prioritizing what I was working on ranked by risk. Software development is essentially a game of risk management as any part of an application can quickly become very complex and suck the life out of your development schedule. We have all been there, the aspect you think will take the least time time ends up taking the longest for some odd reason. The TODO list helps me stay focused on the high risk elements early and forces me into a fail early, fail often model of development. I really like getting the hard problems out of the way first and slowly working towards an ever more stable release with constant lower risk refinement.
Here is how I manage my TODO list:
1. Write a list of all TODO items in the application each must have a defined completion point ( what is complete here? ).
2. Rank these by risk ( How hard are these items? How long will they take? Have you done this before? )
3. Work top to bottom on the list
4. Keep this TODO in version control within the build
The practice has really helped me built lots of different software projects and has made “What should I be working on?” much easier to answer at any point during development. It also is super handy for long term projects where you WILL forget what you were working on and what needs to be completed. I do know some developers that do this inline in the software application but I really like having a separate document for printability. Wasting a peice of paper on a priority list of TODO’s is very high value in my book.
So take some time and write out a TODO list for the application you are working on. It really clears your head and allows you to focus on what is important in your app.
I have set-up an new application on Adobe Groups for sharing skins made with Flash Catalyst. Given the limitless design options when creating skins I thought it might be great to share skins and see what others come up with.
Having a defined set of skin elements on a hidden state within Catalyst really makes prototyping easy as design elements are just drag and drop.
Some sample skins:
If you build a skin in Catalyst or just have a cool ui to share.
Post them here.