Prototyping toward product release applications

Designer vs Developer

In a landscape of moving targets, and the wish to hit the bullseyes in tandem, there is an increasing need to work closer together in order to get things done. In a traditional software “house” or application development team, there are designers and there are developers (or software engineers).


Normally the designers take their list of features/application targets and work away coming up with information flows, user interfaces, user experiences, etc. and test them. They build lower-fidelity prototypes. They use applications like Sketch to build up flows and static representations of the application. They are the painters, applying vision and concepts to virtual canvases – slowly building up an experience. This can be done outside the purview of those in a development department (engineers, developers, coders, whatever you’d like to call them). Or it can be done in tandem with the development department so that there are some reality checks for how things progress. A feature might be easy to pixelate but could have certain ramifications to actually produce and have work robustly.

Each change might need to cascade through artboards. You’ll need to update those and distribute them. You could end up with a very large cycle of repetition that is prone to user error in making all the changes needed… everywhere.

This can be done outside the purview of those in a development department (engineers, developers, coders, whatever you’d like to call them). Or it can be done in tandem with the development department so that there are some reality checks for how things progress. A feature might be easy to pixelate but could have certain ramifications to actually produce and have work robustly.


I’ve seen in some circumstances where developers wait for an approved application design, flow, and experience. Whatever “pseudocode” the designers may have written be tossed aside for fresh & production code. Just because developers know more than designers… right?

Make Mashed Potatoes.

Mashed PotatoesWith the passing of every new year, designers strive to express themselves. They’d like to watch their visions come to life. They push new experiences and interactions. The code more and more. Over time, their code generally improves to the point where it can be pretty good and can actually have a chance to live on in compiled applications. Imagine that.

Version controlled prototypes (SVN, Git, etc.) allow for more play without the worry of forever losing something, especially for designers. Developers know all about such things and welcome branching and merging.

The once tall standing walls of categorical thinking that prevented hopping can now become small fences that can be stepped over – if one just knocks on the door first to be polite.

The gap between designers and developers is gradually closing. Code-driven prototypes could be the future of digital product design. Things turn into a collaborative, team-driven exercise. You get to the scrum milestones with greater success, the developers can help designers with a penchant for producing code-based bits of code to do what they envision, the designers can give the developers a greater sense of design sensibilities, and you end up with something production-ready in a shorter timeframe.

You don’t have two teams of people, each with their unique skills, working separately – or worse, gating each other over and over. You have a group of people advancing together (or nearly so).

So. A prototype now becomes a master prototype. All members use version control. It contains all of the features and functionality that the shipping version is expected to have. New features can be worked out on a branch and merged back in if it’s deemed alright to do so. The animations and experiences are part of the prototype – and not lost in a low-fidelity prototype or merely talked about without being implemented until late in the game.

You might worry about this. It assumes that most of your designers know how to code for the target platform. Or that they really even want to. Some might want to only live in Illustrator, Sketch, Invision, etcetera. So it obviously can’t work in all cases. It is a path that can serve a team and company well though if you have all the parts in place.

The master prototype can be taken at the end and optimized, code-reviewed the last time, and given a version 1.0 blessing by whoever is deemed appropriate to do so. Isn’t that better than producing static or canned experiences that take time and need to be recreated in code later on? Isn’t it better not to worry about how a developer might interpret some design description of how an animation or series of animations is supposed to look? You’ve built the actual thing together.


I have actually worked on small teams producing rich prototypes – and the development time is optimized. I am versed well enough to be able to jump into repositories, look around, and get what I need. I can make smart decisions, request features (visible or backend) in order to make my job of creating an experience easier. I get requests to display certain bits of data from backend developers. We work together, communicate concerns, announce issues early on, fix bugs as we go, and make informed group decisions.

At the end of the prototyping cycle, we have something robust and quite nearly release-ready. The code will be good. If things need to be re-worked for release, we’ll have ideas on how to best set that up since we authored the prototype code already. We’ve done nearly all of the work, we haven’t cut corners to merely get something out the door. We haven’t faked much if anything, if possible. We want to live with the prototype, to feel it work, and to gauge its ability to delight users.

I’m just throwing out this idea. Cutting down the amount of time to release great applications is paramount as more and more companies try to get their stuff out there. They aren’t just competing with each other, they are competing with the AppStore update cycles – if you aren’t fairly active in producing updates, you aren’t perceived as taking the application process as seriously as those who produce updates on a fairly regular cadence.

Information Storage.

While working on a prototype, I document each day’s activity as an overview. I do this using DokuWiki running on my laptop’s server. I have it customized with extensions and my own code to provide just the right experience and ease of updating. For myself and anyone else who would like to update and document certain aspects and decisions. It’s easy to catalog files (PDF, ZIP, etc.) on the wiki as well. Every night I have a CRON job run a script which backs up any changes to an external drive as well so that we don’t miss anything given a catastrophic drive error. It’s an awesome system. It takes some dedication to maintain, but it’s really worth it. And I can go back into any project and re-live it at any time. For me this was a no-brainer.

Tagged : / /

[Swift] UIScrollView snapping into place like in the iOS App Store

I was asked recently to modify the UIScrollViews that I implemented in an iOS application design. The request was to have our scroll views behave like the ones that appear in the iOS App Store. Here is a screen capture of that ribbon to familiarize you with the scroll view in question.


Alright. In short the behavior prevents cell clipping when navigated to someplace in the middle section of the exposed cells. If the user is at either the beginning or the end of the content, you’ll see peak-through which is desired. But anywhere else, don’t clip the display of a cell on the left side.

I searched around doing the StackOverflow dance and found a few posts about this very thing. One of them mentioned the App Store specifically and that’s where I lifted the screen capture. The explanations were up-voted but when I tried them, they only worked part of the way. I’d get some wonky, sticky behavior. I had to convert many of them to Swift as well as they were offered as Objective-C solutions.

I started to get frustrated – just wanting this thing to work quickly, show it to the person who requested the behavior, and then move on to more pressing application authoring issues. Meaning bigger stuff. So after some time trying to modify someone else’s code to work I decided to junk it and use their concept and code it myself.

The place you want to put some code would be in your UIScrollView’s scrollWillEndDragging delegate method. Make sure that you include UIScrollViewDelegate in your class and to set your scroll view delegate appropriately.

class ViewController: UIViewController, UITableViewDelegate, UITableViewDataSource, UIScrollViewDelegate {

And then

myScrollView.delegate = self

When those things are done, the scroll view will call it’s delegate methods. Here is a solution written in Swift that I used to get this behavior and I’ll explain some if it for you.

func scrollViewWillEndDragging(scrollView: UIScrollView, withVelocity velocity: CGPoint, targetContentOffset: UnsafeMutablePointer<CGPoint>) {
        if scrollView.tag == 99 {
            let pageWidth:CGFloat = 170 //160 plus the 10x on each side.
            let val:CGFloat = scrollView.contentOffset.x / pageWidth
            var newPage = NSInteger(val)
            if (velocity.x == 0)
                newPage = Int(floor((targetContentOffset.memory.x - pageWidth / 2) / pageWidth) + 1)
            } else {
                if(velocity.x < 0)
                    let diff:CGFloat = val - CGFloat(newPage)
                    if(diff > 0.6){
                newPage = velocity.x > 0 ? newPage + 1 : newPage - 1
                //Velocity adjustments.
                if velocity.x > 2.7 {
                    newPage += 2
                } else if velocity.x > 2.2 {
                if velocity.x < -2.7 {
                    newPage -= 2
                } else if velocity.x < -2.2 {
                if (newPage < 0){
                    newPage = 0
                if (newPage > NSInteger(scrollView.contentSize.width / pageWidth)){
                    newPage = NSInteger(ceil(scrollView.contentSize.width / pageWidth) - 1.0)
            targetContentOffset.memory.x = CGFloat(newPage) * pageWidth

Since I had several scroll views in this view, I wanted to make sure I could target them individually. I didn’t set them up as class members – I simply used tags to mark them for evaluation. For instance 1 scroll view has the tag 100, another 99, etc. As long as I know which tag calls the delegate method (they all will), I can address them individually. So in this example I’m looking for tag of 99.

The pageWidth is that scroll view’s cell width including the padding. I’ve hard-coded that, you could use a global variable or whatever. If that number changes when the scroll view is populated with cells, you have to remember to change that value in the delegate method. So it’s a little messy, but not a deal breaker in my opinion.

We then determine which page we’re currently on. We’ll use that later to make adjustments if required. The velocity adjustments are there in case the user wants to “throw” the scroll view contents… since we’re making the scroll view sticky, this makes the behavior a little more like the traditional scroll view in regards to perceived smoothness.

If the user throws with a certain velocity, we adjust how many cell indexes becomes the target. If you have a lot of content in your scroll view, you may want to adjust more for velocity – adding more distance for the offset target. Apple does this in their implementation. They have about 3 or 4 “pages” of content. A high velocity drag has a target to get you to the next batch of off-screen content. It’s slick.

We update the targetContentOffset.x with the target “page” * the pageWidth. When that’s updated, the scroll view uses that and updates it’s target position. You end up getting snapping on your cell content just like you would in the iOS App. It’s not a ton of code either.

A note: I read where people were changing the deceleration of the scroll view to make it feel even snappier.

scrollView.decelerationRate = UIScrollViewDecelerationRateFast

I tried it and I felt it made things feel too snappy. It reduced the perception of fluidity and made it feel like something was subtlely wrong with the application or control. So I didn’t use the technique and feel good about that decision. Your milage may vary.

Tagged : / / /

Pull to refresh UITableView

Those of us using iPhones and who are on iOS 6.x have seen Apple’s implementation of pull to refresh. Apple has made this control available to iOS developers – starting with iOS 6.0. We’ve all seen various implementations by other developers that fit their design paradigm, but I think Apple’s implementation is quite nice and could potentially fit many designs. If you’d like to implement this control read on. A current caveat is that this control works with UITableView only at the moment.

Continue reading “Pull to refresh UITableView”

Tagged : /