A few weeks ago Gabriel Scholz wrote a blog about frictionless data preloading in AngularJS which I quite enjoyed. He also updated the blog later conceding that there was an even better method. From my experience, neither options were ideal and I wanted to write a short entry on how I propose we preload data in AngularJS.

A few objectives

I think that there are a few key attributes that a good solution has to have:

  1. It shouldn’t pollute the global name space
  2. It shouldn’t require declaration within the scope of `ng-app` in the DOM
  3. You should be able declare multiple pieces of data separately and concatenate them
  4. Preloaded data should be optional, not a dependency

The two previously suggested solutions

1. Gabriel suggested that we put JSON objects inside of <script> tags, identify them by a type such as “text/preloaded” and then parse and add them to a `preloaded` config object via a directive that looks for `script` tags. I actually really like this idea but it didn’t satisfy rule #2. Your script tag needed to be inside of `ng-app`’s scope.

2. The blog entry was updated with a solution of simply declaring another module within `script` tags. However, this solution doesn’t satisfy rules #3 and #4 very well. I would hate to be declaring and depending on multiple modules of preloaded data.

My proposed solution

I actually really like Gabriel’s method, except for running the search for preloaded data inside of a directive. Instead I say it should be done inside of a `.run()`, which occurs after `.config()` and before `.controller()`. Like so:


This method satisfies all 4 rules I stated above. I would love to hear feedback if anyone has a better method.

This past April I cancelled a collaborative project I had been working on since last November. It was a very difficult decision to make and took a lot of consideration but I feel it was the right decision. It isn’t my intention to be the good or bad guy, I just want to write a little bit about what happened that led to this decision in an effort to continuously improve what I do. This is my post-mortem.

The New Project Specifications

In November of 2013, a friend of mine introduced me to another developer. This developer (who I will refer to as the CEO), had a pre-existing service for web that she wanted to make into an iPhone app. Coincidentally, I had recently realigned my career goals to work more collaboratively with others. So I was quite enthusiastic about taking an opportunity to work with another developer.

Over a couple of talks in restaurants and coffee shops we came to an agreement about how the project would move forward. I would develop the iPhone application and the CEO would own it 100%. I would get a 35% cut of all advertising and subscription revenue made from the iPhone app. The app’s data service(API) would be provided to me and was already in working order since it was used in the web version. I would help with some design and architecture aspects but final design was to be provided to me by the CEO’s previous designer.

Beginning the project

After coming to an agreement, I was ready to go. The following week I committed all my work hours toward making our first prototype and uncovering any issues/needs. It was a very productive first week. I worked on the app for about 50% of the next week, mostly diving deeper into making the app more performant. The week after (now early December) we met and discussed exactly the changes she needed to make to the data API in order to facilitate the iPhone app.

Middle of the project

This is about the point things started to derail. I’m not sure if it was the nature of December and the holidays or what, but the changes I had requested weren’t made. In about the second week of January, I decided to switch focus back to my recently released app, Postcard. We always had an understanding that I was working on 2 iOS Applications but I did consider hers to be like client work and therefore my first priority. However, the data API hadn’t changed yet and I didn’t want to sit on my hands indefinitely, so I switched my focus. On reflection, I should have been more proactive about making sure the data API was being developed for me rather than waiting. Thinking of her as a client, I just let it take as long as necessary. Paying clients, however, are motivated by the cost of development; partners are not.

Postcard’s development moved forward at a great rate. By the end of January I had shipped it off to Apple for approval. So with my own app in the approval queue at Apple, I was available to return my focus. When I emailed the CEO again about our project and the data API’s status, I was met with a response to the tune of “I’m ready, I was just on hold while you worked on Postcard”. I wasn’t a big fan of this response. For one thing, the timing of events was out of order for that to be a viable reason. I had only come back to Postcard after not seeing much momentum on my other project. We met up for lunch the following week and I discussed some concerns regarding our pace, the level at which we were communicating and other matters. We came to an agreement that we had lacked enough communication with either other and made too many assumptions. We both agreed to improve.

I also brought up the state of design and when this would fit into the project. I wanted final design sooner rather than later so I volunteered to make a thorough information architecture document outlining the views and interactions. This way she could hand the document to the designer earlier and we could have that discussion sooner. Interface before implementation.

I had a goal for our first user testing build to be ready by March 16th. While this build didn’t end up constituting a ‘beta’, it was a significant move forward, implementing everything I had outlined in the architecture. Unfortunately, the data API changes that I requested hadn’t all been made yet, so there was no way to have a beta build ready anyway.

End of the project

On March 16th, after delivering the latest build, I informed the CEO I wouldn’t be able to work on it again until start of April. Postcard, which I had released on February 19th, needed some attention now that it was out in stores. In early April we started up again. We had a lunch to discuss next steps and agreed to meet at a collaborative workspace I frequent to hammer out the data API. I inquired about the status of design as well, but was informed the designer still had not yet been contacted after I delivered information architecture.

We met that weekend, hammered on code all day and developed all the changes to the data API, except for one. Things were finally looking good for the data service portion. At the conclusion of our day together, I informed the CEO that we needed that last API fix and to bring the designer on to this ASAP.

That Monday I was informed “we have a problem…”. The designer was uninterested in working on the project. Judging by the tone of the email it actually sounded like he had been unavailable/uninterested for a little while. I was incredibly frustrated by this, after having stressed the importance of the design aspect for months. Over a series of a few more emails, I quit the project.

The reasons that I quit the project

That’s the whole story in a nutshell. It was a very difficult decision to make. After being informed that the designer was out, it took me a day or two to reply just because I needed to carefully consider the situation and how I wanted to move forward. From that I concluded the following:

  • I was running out of time and money. I hadn’t taken a contract in over 6 months and was only doing enough freelance to get by as I tried to developed apps I had some ownership of. I hadn’t anticipated the project would go on like this. I didn’t feel like the right developer for the project. I assessed too much risk in continuing.
  • The CEO should have been more motivated to complete the tasks I requested of her; both data and design. We could have identified the designer issue in late February/early March. She shouldn’t have forwarded me an email to inform me ‘we have a problem’. She could have been proactively seeking another designer and reassuring me this was only a temporary setback. That was the kind of leadership I needed to see from her in the moment of crisis.
  • As a result of this, I didn’t feel I was being adequately supported on the project and set up for success. You need to feel like your business partners have your back and your work together has a synergistic result. I did not feel we were achieving this.

The mistakes I made

If I tried to end this post without criticizing what I did wrong I would be thoroughly kidding myself. So what mistakes did I make?

  • I should have proactively communicated better when I wasn’t getting what I wanted. I didn’t want to patronize a developer for whom I have much respect, but things might have happened sooner if I was just a bit more assertive.
  • I should have set more clear timeline and/or project benchmarks for us to meet.
  • I should have outlined more clauses in our agreement regarding the expected timely fulfilling of requests.
  • I should have ignored Postcard completely until the completion of this project. If some of the previous ‘should-have’s were fulfilled, this would have been accomplished naturally. The divided focus, particularly toward the end, was hurting me.
  • Maybe I should have made my concerns throughout the project more clear. This is a really hard one to say though from a relationship management POV. You don’t won’t come off as the person who’s being too anal about how a project has to go.

In conclusion

If I could do it again, I would, but with the aforementioned adjustments. I liked the project. I like and respect the CEO. If this project were adopted by a new developer they would be getting a significant leg up on the starting code, app design and data API. While the end of our collaboration together is over, all is certainly not.

I would gladly collaborate again. The results of collaboration are amazing and it is the kind of thing you just have to continuously try to improve upon. These lessons learned don’t expose our personal flaws so much as the kinds of issues that are innate in collaborative projects. They would have inevitably happened on one project or another eventually so I’m glad to be ready for them sooner rather than later. I hope that we’re both walking away as better developers than we were before. I know I am.

 

Think there’s something I missed in this post-mortem? Leave a comment.

For 3 years now I have participated in the Toronto Game Jam(#TOJam). It is pretty much my number one reason to live in Toronto these days. Despite not regularly practising game development on or off the clock, I do still consider it a hobby and this my favourite place to exercise it.

One of the things that makes the Toronto Game Jam so great is the fact that it is a non-competitive event. People are encouraged instead to challenge themselves and have a great time while helping each other in a greater collective goal of making a small game by Sunday. Speaking of help, the whole thing wouldn’t even be possible without the tireless volunteers that work to prepare the event and run it through all hours.  A lot of energy, enthusiasm and support under high pressure went into each of those games. If you aren’t a participant and haven’t seen the amazing list of games that came out this year from the jam, you really need to have a look.

Among the list you will find a game developed by myself and Rob Richard called Lemonade Startup. It is a satire business simulator game paying homage to the lemonade stand simulator games of younger years and the current popularity of startup culture. I consider it to be the most successful of the 3 jams I have participated in for several reasons.

Lessons Learned

  • Having a vision going into the jam is essential. It isn’t illegal by jam rules to be prepared and this is about your personal best. So setting yourself up for success is a good idea. Rob and I met for pints casually and discussed our idea. We drew out a plan of execution for day 1, 10am.
  • Scope, scope, scope. Consider the scope of everything you add. It is really important to be able to draw a vague line in your mind of how you are going to get from start to finish in 56 hours. Ideas that seem unclear in execution or side fluff need to be benched. Don’t even think about adding them just at the end either if it involves too much last minute coding.
  • Sleep. Take breaks. Scope needs to account for a minimum of 16-20 hours of leisure per person. That’s at least a good night’s sleep every night.
  • Regular ‘nightly’ builds. We set a goal to have something playable each day. Since it’s a web game, Lemonade Startup was even shared online every night. This is really useful because it means you are setting yourself up to be ready for the post-jam arcade and getting opportunity to test it earlier. We made some key pivots on day 2 after realizing that drag and drop controls were too sluggish. We moved to hotkey capabilities and it made a world of difference.
  • Team size matters a lot. I’ve tried a 6 man and a 1 man team before and seen both of their pitfalls. Large teams are hard to manage and organize. If you have remote workers, even harder. It also makes the pre-planning phase trickier. Take each member you add seriously; they contribute to scope. 2-3 people maximum seems like a key team size. The difference between 1 and 2 people is huge. The team support and constant discussion that you get from being 2+ will make for a better final product, not to mention the additional help when dividing tasks.

Post-jam

Every jam is a great learning process and I’m constantly fixated on improving the formula for a successful jam. Our shared past learnings taught us well this year. We had a web game ready in time for pencils down. There was some great feedback and reception during the post-jam arcade. While calendar oriented business simulators aren’t for everyone, others took to it very kindly.

We also had a theory that this game would be liked among the tech/startup crowd. So on Tuesday, after making a few tiny tweaks, I posted our game on Hacker News and can proudly say we made the front page for an hour or two, getting as high as #8 for a glancing moment! It was very rewarding to see people getting into the mechanics and making wise cracks – comments here.

I’m really glad to have participated yet again in the Toronto Game Jam and hope I can participate again next year. I was actually very close to missing it, but managed to spontaneously start a team with Rob just days before registration opened. The only criteria going in was that we make a game built around a drag and drop calendar, because I thought I might reuse the code for other work.

 

I’m thrilled to announce today that Postcard will be available on iOS worldwide on February 19th. It has come a long way since the idea first started forming just over a year ago but I’m incredibly happy with
final result. A huge thanks to everyone who encouraged me and helped me test and improve Postcard to where it is today.

As of today the new launch page has been posted and you can see a video preview of the app sending a message out
to several networks including, of course, my own website!

So what makes Postcard special? Well,

  • It’s a write once, share everywhere authoring tool that gives you post-by-post control of where you share
  • It lets one network serve as a ‘host’ and the remaining networks share a link back to that ‘host’ network’s content
  • The ‘host’ feature can be used to effectively overcome message length and media type limitations of some networks i.e. Host a video with a long message on Facebook and share it to Twitter
  • It allows any prepared website to also receive the posted content
  • There is already a WordPress plugin available for download

While posting to one’s own website may not be the first feature that I’m advertising, it is the one I am personally most excited about because it represents most strongly why I first started building this app in the
first place – to help people solve content ownership and control issues I see prevalent in the shape of social media today. There is a big opportunity with this app to make sure your website doesn’t go stale as
you post regular short form content to social networks. Furthermore, if advertising revenue or lead generation are important aspects of your website, there’s all the more reason to take advantage of the ‘host’ feature and draw traffic from networks to your website.

Postcard and its API Protocol are my attempts at moving toward a more open and standardized model for the way we use social networking. For those of us who are active content creators, I think this marks a very important change in the way we use social media.

This week I’m preparing for launch next Wednesday and am happy to answer any questions about the app and how it might help empower the way you use social media.

Cheers,

Kyle