Kyle Newsomehttp://www.bitwit.ca/
Web/iOS Developer, UX EnthusiastFri, 27 Jun 2014 03:35:31 +0000en-UShourly1http://wordpress.org/?v=3.6Regarding AngularJS data preloadinghttp://www.bitwit.ca/blog/regarding-angularjs-data-preloading/
http://www.bitwit.ca/blog/regarding-angularjs-data-preloading/#commentsFri, 27 Jun 2014 00:45:33 +0000Kylehttp://kylnew.com/?p=1679A 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:

It shouldn’t pollute the global name space

It shouldn’t require declaration within the scope of `ng-app` in the DOM

You should be able declare multiple pieces of data separately and concatenate them

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.

]]>http://www.bitwit.ca/blog/regarding-angularjs-data-preloading/feed/0Reflections on a Cancelled Collaborative Projecthttp://www.bitwit.ca/blog/reflections-on-a-cancelled-collaborative-project/
http://www.bitwit.ca/blog/reflections-on-a-cancelled-collaborative-project/#commentsTue, 06 May 2014 22:52:52 +0000Kylehttp://kylnew.com/?p=1650This 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.

]]>http://www.bitwit.ca/blog/reflections-on-a-cancelled-collaborative-project/feed/3Reflections and lessons from Toronto Game Jam 9http://www.bitwit.ca/blog/reflections-and-lessons-from-toronto-game-jam-9/
http://www.bitwit.ca/blog/reflections-and-lessons-from-toronto-game-jam-9/#commentsThu, 01 May 2014 15:04:13 +0000Kylehttp://kylnew.com/?p=1627For 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.

]]>http://www.bitwit.ca/blog/reflections-and-lessons-from-toronto-game-jam-9/feed/1Postcard is coming to The App Store February 19thhttp://www.bitwit.ca/blog/postcard-is-coming-to-the-app-store-february-19th/
http://www.bitwit.ca/blog/postcard-is-coming-to-the-app-store-february-19th/#commentsTue, 11 Feb 2014 16:29:57 +0000Kylehttp://kylnew.com/?p=1595I’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

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

]]>http://www.bitwit.ca/blog/postcard-is-coming-to-the-app-store-february-19th/feed/5App Rewards Club Version 2.0 & A year in reviewhttp://www.bitwit.ca/uncategorized/app-rewards-club-v2-year-in-review/
http://www.bitwit.ca/uncategorized/app-rewards-club-v2-year-in-review/#commentsThu, 14 Nov 2013 14:10:50 +0000Kylehttp://kylnew.com/?p=1585I originally wrote this on the App Rewards Club Blog Site. Please visit the site for more information on contacting Ken or I about how we can feature your apps.

Version 2.0 – Refining our business model

Today Ken and I are proud to announce the launch of App Rewards Club Version 2.0. We decided to make several changes to improve the offering to developers and users alike.

Our service is now 100% free for everyone. Any free app of any kind can be featured at absolutely no cost. No sales data required, nothing.

Featuring an app with us is as simple as contacting us with an iTunes ID and a day/date range of when your app will be free. We are also rolling out a way to distribute gift codes for paid apps (read on)

We are introducing a new daily raffle system for users to make sure that we consistently deliver more rewards on a daily basis than ever before. We also aim to improve visitation regularity this way.

The aforementioned daily raffle system now also affords us the opportunity to showcase products and distribute gift codes for paid apps and other online products/services. We wanted to find a way to get paid apps/games more involved in our system and this will be our first way. Any users who click on the prize icons in our winner announcements can be redirected to any product webpage or the iTunes app store.

We are now focussed on the US App Store market exclusively. Our app was removed from global sale in January and we are dedicated to focussing on the US market exclusively.

With these changes we can proudly say that we are the first and only free app marketing service that spends money out of pocket every day to feature free apps while charging developers absolutely nothing. You have nothing to lose and everything to gain by trying our service.

A year in review

It’s been exactly 1 year since we last wrote a blog entry on this website, which is unfortunate for a service that touts transparency in their mission statement. It was our original goal to deliver several updates per year as we accumulated more sales data and attempted to create norms, however this vision did not come to fruition. So what the heck has been going on? Well let us briefly get you up to speed.

Post launch problems

After our worldwide launch in mid-September 2012 and our 2 week long campaign, which we reported on in November, momentum wasn’t exactly where we wanted it to be for a few reasons:

One of our first rewards partners, who will remain nameless, was not pulling their weight and we were having lots of issues with prizing and gift card availability. Our partner’s loyalty rewards business simply wasn’t ready to provide what we needed. There was a lot of over-promising and under-delivering on their part which really made us question what was happening behind the scenes. In retrospect, it has been a lesson to us in not depending on other early startups as a core of one’s own business model.

Our pricing model wasn’t resonating with developers. Despite being free when sharing sales numbers via AppFigures, some developers still questioned why they had to share such information. Ultimately it became apparent that the perceived cost of sharing sales data is highly subjective. The service wasn’t giving the impression that it was free/worthwhile enough to use.

Switching rewards providers

The first of these two problems, our rewards provider, was by far our greatest struggle. Without a solid system in place our app was not building an audience nor were any shining positive reviews coming through. So we looked to find a new rewards provider that we felt could provide a better and more reliable experience for our user base. We found exactly that in the service SessionM. However, prior to using SessionM we had to make one very important decision – To stay global or focus only on the US App Store market. Currently SessionM is only available in the United States and our app was, at the time, distributed in every app store worldwide. It was already clear to see, however, that most of our advertising revenue was coming from the US and it is by far the most important App Store market to succeed in so we opted to remove the app from all other stores upon the release of Version 1.5 in mid-January.

Finding stable ground

While we’d love to tell you everything was smooth from Version 1.5 onward, it was not. We initially ran into some issues with SessionM’s system not being quite prepared for our kind of loyalty platform and, over the course of a few weeks, we worked with them to tweak things to a satisfactory level that kept our users enthusiastic about the program. We endured a few pretty nasty emails and some less than sound nights of sleep while transitioning between rewards providers and while the points system was a bit unstable but things did normalize by the end of January.

With the app finally in a stable and reliable state, there was one last key issue to attack – we weren’t yet a profitable business. Over the course of 2012 Ken and I invested several thousands of dollars into design and prizing. We were still heavily in the red. Version 1.5 gave us hope that we were much closer to a stable and profitable business but we had yet to see a reliable revenue stream that would allow us to justify further investment in marketing, user acquisition and retention. By about April/May we were finally breaking even and looking forward to improvements and expenditures in the near future. Version 2 discussions began not long afterward. Since this is a side-project for Ken and I, given other work commitments and the forthcoming fall release of iOS7, we decided to wait a little while, accumulate some more expendable income and then release.

In Summary – Our Mission Statement

Now that you’re caught up and aware of our Version 2.0 release we hope you are excited to work with us to help market your apps. We encourage you to reach out to us by email, twitter or in the comments of our blog.

To repeat our mission statement:

Our mission is to be the most transparent, informative and accessible app marketing service available to developers. It is our intention to determine the best strategy and true cost of effective free app marketing and share those findings with the community at large. In addition, we will strive to be creative in our means of app promotion and continuously evolve as necessary in the best interest of our clients.

That statement remains unchanged since we wrote it before the release of Version 1.0.

]]>http://www.bitwit.ca/uncategorized/app-rewards-club-v2-year-in-review/feed/0On Solo Entrepreneurship and Euchrehttp://www.bitwit.ca/blog/on-solo-entrepreneurship-and-euchre/
http://www.bitwit.ca/blog/on-solo-entrepreneurship-and-euchre/#commentsTue, 08 Oct 2013 12:00:11 +0000Kylehttp://kylnew.com/?p=1565If you’re a multi-talented individual, others might tell you that you can do it all. Heck, you might very well be telling yourself this too. However, whether you actually should do a venture on your own is a totally different matter. Personally, I struggle with this issue and have ultimately concluded that, no, I shouldn’t be trying to do every aspect of a project by myself. Somewhere in that revelation I realized an interesting similarity between my work challenges and one of my favourite card games, Euchre.

“I’m going alone”

In the game of Euchre, ‘going alone’ is a risky move. You tell your partner to put down their cards while you attempt to take all the ‘tricks’ in that hand alone for extra team points. You make that decision based on a hunch, but you very rarely have enough information to be absolutely sure. Needless to say, it goes wrong sometimes (you don’t get the extra points) and very wrong other times (your opponents win the hand with bonus points for not calling the suit). In my personal Euchre experience, going alone burns more than it pays off. While my perceived success rate might be due to my own lack of expertise in Euchre, it only solidifies the argument I’m making.

Doing it all is risky

Much like in Euchre, choosing to do it all alone in business is a risk. While we might not be given the opportunity to have a teammate in real life the way we are assigned one in Euchre, working alone is like trying to play a 3 player Euchre game going alone every hand against a two players. Sure, it’s going to work sometimes, but when it does, it is a meeting luck and preparation. That’s not to say that successful solo entrepreneurs are lucky people, because the ‘preparation’ is an incredibly important part of that equation; it’s all the expertise and hard work that gives you a fighting chance, much like a newbie Euchre player would just get destroyed going alone every hand without any sense of strategy.

Teammates curb risk and see things differently

In Euchre, teammates are the lynchpin of a steady game. While you can’t actually talk to your teammate in the game, skilled players know how to read each others’ plays to extrapolate what the rest of their hand probably looks like. Good teammates work in sync and play around each other’s strengths and weaknesses wherever possible in order to secure more tricks for the hand. It can truly be a beautiful synergy and, in my opinion, the most exhilarating part of playing Euchre.

This is exactly what a partner in any business endeavour can be too: someone to complement your weaknesses, see all the challenges ahead from a completely different point of view, celebrate your victories and failures with, and help maintain the team morale.

Cheers to partnership

With that, I raise a glass in toast to partnership and collaboration. It’s something I’ve only done sparsely in the past but every single time it’s made what I do better. As I near the beta release of my app Postcard, which I am very proud of, I still can’t help but think what it might look like if I built it with someone else’s help. As far as my own products go, it has been by far the most isolated from external assistance. Some of the most challenging parts of this endeavour have been constantly trying to play my own devil’s advocate, maintaining emotional stability through the highs and lows of the creation process and keeping both design and development moving forward as well as managing my own marketing communications – problems a second set of hands would have helped with tremendously. It is my goal in the future to work with others more and stop trying to go alone. I’m confident it is the key to being my best.

]]>http://www.bitwit.ca/blog/on-solo-entrepreneurship-and-euchre/feed/0My New Website and 3 Ways It’s Integrated with Postcardhttp://www.bitwit.ca/blog/my-new-website-and-how-its-integrated-with-postcard/
http://www.bitwit.ca/blog/my-new-website-and-how-its-integrated-with-postcard/#commentsWed, 11 Sep 2013 20:44:49 +0000Kylehttp://kylnew.com/?p=1545I’m proud to announce today that I’ve finally released a long overdue update for my website. The old one was getting a bit stale and the portfolio was seriously out of date but other things, namely client work, always took priority. One of the biggest reasons I finally got around to actually updating my site was out of necessity to start ‘dogfooding’ Postcard in preparation for its beta and upcoming release. As a result, you’ll notice some strong similarities between this site’s layout and the Postcard launch page.

Today I wanted to briefly go over some of the new website functionality that is integrated with Postcard.

The header image

You see that image at the top with my goofy expression? That’s a ‘selfie’ I took a little while ago and when I sent it to my social networks, including this website, I tagged it with ‘#profile’. That tag functions as an indicator to Postcard that this is my new profile picture.

The ‘Interesting Links’ section

Similar to my header image, the interesting links section functions through the power of tagging my posts as ‘interesting’ or ‘useful’. However, you might notice that not all these posts have been explicitly labelled as ‘#interesting’ or ‘#useful’. That’s because postcard includes the ability to privately tag posts and not occupy message space.

The ‘About Me’ section

At the bottom of my About page I embedded a picture gallery. It is simply a gallery of recent image or video content I post directly to this website. Much like Instagram’s website, you can click on any image to navigate the pictures through a modal overlay. You’ll notice that this gallery works well in any size, whether you are on a desktop or mobile phone. That’s because Postcard (as well as this website) is design responsively to fit well in any situation.

Beta begins

As of today I’m finally actively approaching people who have signed up to beta test Postcard and I’d be happy to work with others who are interested but haven’t signed up yet. Just email me at kyle@bitwit.ca or signup on the launch page and I will reach out to you very soon.

]]>http://www.bitwit.ca/blog/my-new-website-and-how-its-integrated-with-postcard/feed/0What if email had never been standardized?http://www.bitwit.ca/blog/what-if-email-had-never-been-standardized/
http://www.bitwit.ca/blog/what-if-email-had-never-been-standardized/#commentsWed, 04 Sep 2013 12:54:52 +0000Kylehttp://www.bitwit.ca/?p=1425Bear with me for a moment as we do a quick thought experiment. What if email had never been standardized? Email-like services have existed as early as the 1960s and it was first suggested that such a type of service should be standardized in 1973. But what might the landscape of email be like in this modern era of Internet if no standard protocol had ever come to pass? I can think of a few things:

Not too surprisingly there would be a few email services with massive user market shares and a lot of smaller players. However, unlike the email we know today, few of these services would cooperate with each other. Gmail users would email other Gmail users, Hotmail users would email other Hotmail users and so on. As a result, many users would probably have email accounts across more service providers in order to fulfill their email communication needs with all their contacts. They would need even more accounts on each service if they represent a company or brand as well as themselves.

We’d probably be seeing more email service start-ups emerging all the time with new and fancy ‘killer features’. For example, one service might offer strong video integration while another allows Javascript integration for a more interactive message. One service might guarantee read receipt functionality while another lets you post date your emails to not be open-able until a specific date and time. That’s just a few off the top of my head but I’m sure Silicon Valley would have plenty of wild ideas for what email would do.

Some of these email services, in order to play nicely, might offer some sort of high-level integration with a select few other email providers such as being able to send a plain-text email body only.

Each email service would be able to have strong control over 3rd party client applications, if the service so pleased. Some might even disallow 3rd party clients completely and expect you to visit their website or mobile app only.

It would be incredibly hard to move users between services. Email migration would either be complicated or, in many cases, impossible due to the format just being too different. Also, convincing users to try new services out would be a new challenge considering the need to already have friends and colleagues on board.

As a result of the previous point, the value of a user on your email service would increase. Some email start-ups, despite a lack of revenue, might have high valuations due to their ‘killer features’ successfully drawing in new users at impressive rates. We’d probably see some of these start-ups getting bought out by bigger players either out of fear or interest in drawing in a market segment they have been failing to appeal to.

Doesn’t this sound kind of familiar?

I’m sure you can’t help but get that nagging feeling you’ve seen this all happen despite email having adopted a protocol. Why? Because that’s the state of social networking as we know it today, which begs the question: Why hasn’t social networking got a protocol of its own?

Full disclosure: As one component of my project, Postcard, I’m working on an open social networking protocol, which is just one of the many reasons I have such a passion for the topic. However, this will be my only mention of Postcard in this blog entry. You can learn more by reading this entry.

How we could all benefit from a social networking protocol

Now maybe you aren’t quite convinced there would be any benefit or reason to standardize social networking. Well consider these possibilities:

Exporting and importing data would be a breeze.

The ability to amalgamate data from multiple networks would be a non-issue. Making integrated personal albums or timelines of our experiences across various services would be simple.

The door would be wide open to 3rd party applications.

Distributing a message across many networks would be streamlined. Much like the way email functions, social networks would behave like your contact list and “To:” field when authoring a message.

Migrating data from one network to another wouldn’t be such a crazy concept.

Further to this, content ownership would be much simpler. Adding social widgets to our own websites, for example, would be simplified. Our personal websites could even respond to the social networking protocol directly.

New features of social networking would be widely communicated ahead of time and implemented across most, if not all networks. The need to join a new network for one ‘killer feature’ would be significantly diminished.

This doesn’t mean they have to be all the same

Now I know this might sound like the death of creativity in social media. After all, if a protocol had existed a couple years ago, this might have impacted newer networks like the recently introduced Vine which has clearly resonated with many social media lovers (myself included). Well, not all social networks have to behave alike just because they all conform to the same protocol. If that had to be the case, then how would something like the concept of Inbox Zero have taken off in the word of email recently? It works because Inbox Zero is about behaviour, not protocol. An app like Vine would be communicating on a media attachment part of the protocol. How it chooses to produce and present that media within its own client context is entirely of its own accord. Furthermore, the protocol does not need to be stagnant, rather it should be a living document updated regularly in an extensible fashion, much like the W3C manages a changing standard for HTML.

Closing thoughts

I’ve got to be honest, I’m a bit sick and tired of joining new social networks. New features are great and all, but I’d really love to see the social web step forward as a community rather than be at the whim of so many separate and conflicted interest groups. There’s so much to be gained from acknowledging that social networking is here to stay and should be adopted as a standardized part of the web.

]]>http://www.bitwit.ca/blog/what-if-email-had-never-been-standardized/feed/0Announcing Postcard and Why It’s Useful To Indie Developershttp://www.bitwit.ca/blog/announcing-postcard-and-why-its-useful-to-indie-developers/
http://www.bitwit.ca/blog/announcing-postcard-and-why-its-useful-to-indie-developers/#commentsWed, 28 Aug 2013 01:30:44 +0000Kylehttp://www.bitwit.ca/?p=1392This week I’m very proud to announce my upcoming software release, Postcard. Postcard is a private social networking platform for websites that helps owners post content to social networks as well as their websites. My first focus is on supporting WordPress sites but there is possibility in the future to make many other web frameworks compatible.

Among the various applications of Postcard, I wanted to briefly discuss why I think this is a useful tool to indie developers like myself. Postcard’s primary goal is to help get content on your own website as well as social networks if you don’t have time to do long-form blogging. I know that I’m personally guilty of this problem. Over time I have seen my own website, as well as the websites of others, start to go stale. Meanwhile, we are actively involved in our communities, developing new projects and updating our Twitter accounts multiple times daily with increasingly rich content like images and videos.

Filtered feeds and #screenshotsaturday

If you are a game developer you might be familiar with the hashtag #screenshotsaturday. It’s commonly used when people want to share pictures of a current game project in progress. #screenshotsaturday is a great example of times when we share interesting content in social media but probably neglect to get it on our website. It’s also a great example of how Postcard could be incorporated into your existing habits and provide new benefits.

For example, let’s say one of your games is called “Potatoes From Space”. You might tag the post with both #screenshotsaturday and #spacepotatoes every time you give a status update on Twitter. Harnessing the power of Postcard you would be gaining the opportunity to embed a gallery on your website of all your #screenshotsaturday pictures or perhaps make a pre-launch page for Potatoes From Space with a gallery or feed of its #spacepotatoes updates.

It’s not just about images or videos either. If you are someone who likes collecting useful internet resources and sharing various types of topical news, Postcard is a great way to maintain a feed focussed in any particular category using the tagging system.

Just like that you can be keeping your website fresh and blogging again, but in a more micro/social-oriented format.

More on Postcard/ Beta testers wanted

There’s a lot more to learn about the power of Postcard. You can learn more and sign up to be notified of the launch on the Postcard Homepage. I will be writing and sharing more information on The Postcard Blog. I’m actively recruiting testers for both the WordPress plugin and iOS app. Please sign up on the launch page.

]]>http://www.bitwit.ca/blog/announcing-postcard-and-why-its-useful-to-indie-developers/feed/0iOS7 Is The Right Time To Raise Priceshttp://www.bitwit.ca/blog/ios7-is-the-right-time-to-raise-prices/
http://www.bitwit.ca/blog/ios7-is-the-right-time-to-raise-prices/#commentsWed, 03 Jul 2013 14:07:20 +0000Kylehttp://www.bitwit.ca/?p=1304This coming fall when Apple releases iOS7 to the general public, it will be a good time for us all to raise our app prices. I read countless articles, forum discussions and tweets on the subject of how we are all selling our goods too cheaply (especially apps at $0.99) and should strive to raise the bar. Well a great opportunity is upon us all and here’s why:

The big interface change requires some relearning

iOS7 is about to bring one of the most colossal changes to iOS we have ever seen. The complete switch to a flat design of every single interface element not to mention functionality changes is sure to take users back a moment. Their understanding of the new functionality and what devices are now capable of will be accomplished over time as they use their existing apps and also purchase new ones.

The great quality divide

Given the massive changes to look and feel that are imminent, we can expect to see a gap between the old apps which have not updated themselves for iOS7 and ones that have gone all in on preparing. When I say ‘we’, I don’t just mean the tech savvy either; this is something everyone will identify much more easily than previous iOS upgrades. There lies an opportunity to make a statement with price.

Creating a “$0.99 is old market” perception

In particular, I think a statement can be made about the $0.99 price tag. If developers who are striving for iOS7 raised their prices by even $1, it would create a message about the types of apps that are still $0.99 – they are the old ones; the dinosaurs. They no longer represent the quality and cutting edge nature of apps today. Their screenshots will look instantly dated the moment iOS7 releases. Given that our users will be in a learning state as they shift between the iOS6 and iOS7 paradigms, reception to a price change is less likely to be a problem with how much is already going on.

A marketing and product opportunity combined

In an article written a while ago during the launch of iOS5, I pointed out that marketing opportunities and product opportunities rarely come at the same time. Marketing opportunities come as a result of new software/hardware releases, holidays and pop-culture bombshells. Personally, marketing opportunities aren’t the ones I typically strive for. Product opportunities come when the product is really ready, not just because it’s a good time to make money.

However, I believe that iOS7 is one of those rare situations when both opportunities will come at the same time. It is a good time raise prices because users are adjusting to a lot of change and developing new perceptions. It is a good time for your product to have a new release because of the sheer amount of change that is coming at minimal cost if you are using UIKit. Developers have been granted at least a 3 month period to get iOS7 ready and beyond. It’s probably worth it.

Who should participate and how?

Depending on any individual developer’s repertoire of products, this may or may not apply to any/all of them. Some of your apps might be best to keep unchanged. I think that if you can say YES to a few or more of the following though, it’s worth considering a price increase:

You are in the process of preparing to update for iOS7

You plan on maintaining this app into the future

You’ve got new features coming out

You’ve wanted to change your app’s price before but never known when is right

You’re currently on sale and are deciding when/what price to return to.

Your app is free but you want to increase the price of a one-time purchase such as a full version unlock

On the other hand, if you have an old app that’s past it’s prime, not selling much or you don’t plan on updating, keep it like it is. You are a part of the statement by just updating the version and price of only the apps you care about maintaining most while leaving the rest behind.

To be discussed…

This is a decision for us all to consider and we’ve got a little time to think and talk about it. All industries deal with having to raise their prices at some point or another and now seems like a good time to talk about if this is the right time for our apps. Please feel to write in the comments below, share, or find me directly on twitter. I’d love to hear what you think.