Setup for Functional Prototyping on OSX

1. Open Terminal.
2. Install Ruby:
3. Install Homebrew:
4. Install node.js by running the command: brew install node
5. install coffee script: npm install -g coffee-script
6. Install grunt.js: npm install -g grunt-cli
7. Make sure your Dropbox is synced
8. Open Terminal  and navigate to ‘Source’ in your dropbox and run: npm init
9. install these packages:
npm install grunt-contrib-sass –save-dev
npm install grunt-contrib-watch –save-dev
npm install grunt-autoprefixer –save-dev
10. Install git:
11. Install Jekyll:  sudo gem install jekyll -v 2.5.3
12. Running Jekyll:
13. Install Sublime text:
14. Install SourceTree: SourceTree (commit using SourceTree)
15. Add to Keychain Access
16. push changes to github using terminal (from the source dir) by running command: git push master

Prototyping Fresh Paint for Windows Phone


In the World of prototyping there are many possible outcomes. Sometimes the prototype becomes an application, other times it becomes nothing. The prototype I’ve chosen to discuss is no exception. Sure it’s an application made for Microsoft, but they have changed much as a company in the past four years. I’ve found that the agile development process has been making the rounds on Microsoft’s Redmond Campus like never before, leaving everything up in the air. Not that it has ever been a walk in the park as a designer here at Microsoft, but the ship cycle used to be 3 years and now it’s every week.

The feelings of desperation, anxiety and uncertainty make for an exciting workplace indeed. Not to mention the people for whom I created this prototype are part of Microsoft’s research organization known as the start-up business group. The point being that I had a mere 48 hours to make the prototype and provide the development team – two guys – with the assets and the code necessary to move forward into production. Somewhere around the 14th hour I handed-off a rough prototype to be served as a demonstration to the stakeholders who would make or break the application as far as funding was concerned. Luckily for me as I was coding another designer was kind enough to generate the assets needed for the controls – from the composites. Kind of backwards, eh?

My experience building the Fresh Paint application prototypes reveal the difference between ideal app design process versus actual app design process. Let’s break the two down a bit, shall we?

An Ideal App Design Process

The business, design and technology triad come up with an idea for an app and a strategy

Sketch the UI’s golden path – what are the goals and personality? – and discuss it with the team

Create an app-flow diagram and discuss it with the team

Create wire frames of the UI, smoothing out the UX with functional specifications – functional “specs” cover what the different controls do, their behaviors, events actions and such and discuss these with the team

Create a few personas representing the apps intended users using models from Getty Images and give them names based on character from HBO’s “Game of Thrones” so colleagues chuckle and love you for it then seek compromise with the team

Design a few versions using sexy software like Sketch, Marvel, Pixate, Illustrator, Photoshop, 3D Studio Max and Cinema 4D and discuss them with the team

Put together a deck for presentation to the broader team, usually known as a stop-motion or “paper” prototype to solicit ideas and buy-in

Create motion comps using Adobe After Effects that demonstrate the physics of the UI and give context to the app flow diagram, sometimes using the personas as contacts within the app and discuss animation with the team

Start using the integrated development environment (IDE) of choice like Visual Studio, Eclipse, Source Insight or xCode, using a well-documented and intuitive software development kit (SDK) to generate the code and UI with regards to front-end development resulting in a draft of the prototyped application representing the culmination of efforts of the UX design team by yourself

Iterate and refine based upon feedback from the team

Present a bug-free prototype to the business decision makers within the company

Give high-fives all around when the app is approved for production

deliver the prototype, assets, functional specs and its source code to engineering

Listen to engineers throw chairs at each other whilst shopping for new fonts created by House Industries


Actual App Design Process (the order here doesn’t necessarily apply)

Come up with an idea for an app and a persona representing a fictional user, find a cheap stock photo or use family members to represent the user avatar.

Hastily draw the UI’s golden path on a white board and leave it up to serve as the app-flow diagram and wireframe adding as dead-ends occur and discuss it with the team as you code with the available IDE, using an under-documented and under-intuitive software development kit (SDK) as the design composites that will also serve as asset slicer conduits are created by you or a fellow designer

Put together a deck for presentation to the broader team, usually known as a stop-motion or “paper” prototype to solicit ideas and buy-in, use this as a functional spec for the prototype and make changes every day to adhere to good ideas that come from the team meetings

Add assets to the prototype as they become available, but use for placement only (FPO) assets in the meantime

Participate in way too many discussions with engineers and assure business decisions makers that the FPO assets aren’t the ones that will ship as they occasionally help and look over your shoulder

provide a prototype to be presented to the team and make changes based upon everyone’s feedback a couple of times

Give high-fives all around when the app is approved for production

deliver the prototype, assets and its source code to engineering and help integrate the markup

Listen to engineers disagree with each other whilst starting the next prototype with your team

I guess you could call the above comparison a good summary of what it takes to create an app from a design perspective nowadays. The prototype ended up serving as collateral to the PowerPoint presentation as it was more hands-on and could be toyed with as the presenter spoke to the stakeholders. Once we had the green light to move the prototype to engineering it served as a head start for the front-end UI as I coded it to be scalable for the devs – it was far from perfect, but at least they didn’t need to worry as much.

My part of the process involved not only creating the prototype, but all facets of the design process. It was a true team effort, with my main focus being the prototype. There were four designers involved and we worked together to bring Fresh Paint to Windows Phone. That was a busy week and one of the greatest experiences of mine at Microsoft!

Some Advantages of XAML Versus WinJS in UI Development for Windows

I’ve worked on application prototypes for Microsoft using both XAML (C#/C++) and WinJS (HTML/CSS/JavaScript). While XAML has a tremendous advantage regarding MVVM (Model View / View Model), custom properties, explicit tags and XAML Storyboards, WinJS has the advantage of div abstraction, CSS and JavaScript’s seemingly limitless capabilities, not to mention jQuery support.

Let’s scratch the surface a bit into why both have benefits in an agile development processXAML’s gesture capabilities allow for quicker overloading of touch-based controls, especially if those controls are nested within other controls that have manipulations similar to their children. These types of behavior are somewhat difficult to manage in WinJS and can take hours to debug. I’ve found WinJS animation capabilities are quicker than those of XAML if the intent is to quickly apply event-based tweens, easing and transitions. Using XAML I often find myself searching for, cutting and pasting storyboards whether they are in XAML or in code-behind, but WinJS is convenient in this way – no need for storyboards here! I also find HTML divs easy to work with, as a div may be anything and everything.

While these benefits are good, there are also pitfalls. The more advanced the MVVM framework is in XAML, the less efficient it becomes – bugs arise everywhere and if a design change wasn’t considered from the beginning, then it becomes sluggish. Common controls are a bit convoluted in WinJS, something as ubiquitous as a list view becomes a bit mysterious and non-symantic because it’s a div too! Performance is also an issue with WinJS.

It’s hard to choose a winner because both are great tools. At the same time once a UX designer leaves the safe haven of the provided SDK code samples for each, things become a challenge. That’s why we’re here though isn’t it?