Don’t forget to set up your Facebook page ASAP

I’ve talked to a few business lately that ended up finding squatters on their ideal Facebook URL.  Yeah, it’s the new “AOL Keyword”, but it’s just expected these days.  Same thing with your twitter name.  It’s just not as simple as securing your domain name anymore.  But there are more reasons to start early on Twitter and Facebook than just avoiding squaters and beating competitors… Here is the first mistake I made with KickoffLabs and Facebook:

Facebook does not have a way to associate URLs with pages. 

This means that http://kickofflabs.com can never really be tied to http://facebook.com/kickofflabs.  There are separate likes, fan counts, and facebook insight reports. 

When I initially published the landing page for kickofflabs.com I set the Facebook like button to the kickofflabs.com URL.  I’d also set the following meta-tag in the page header to “link” our page with our domain:

    <meta content=’200576366633574′ property=’fb:page_id’ />

Along with other Open Graph protocol information.

The assumption was that this would tie the URL to the domain.  But that’s not the case. As of today you have a choice:

1. Have people like your URL and manage the interaction there.  Which is more complicated… but you can do this and have your URL publish stories to Facebook just like it’s a Facebook page itself. 

2. Have people like your Facebook page and publish stories from your URL.  This option is much more user friendly if you are just getting started… but keeps the relationships tied to the Facebook URL instead of  your site. 

You can use the URL linter on Facebook http://developers.facebook.com/tools/lint/ to see what’s going on by entering something like http://microsoft.com and comparing it to http://facebook.com/microsoft.  They’ve push most of the fan activity to the facebook page…but over 5k people have liked the microsoft.com URL directly and generated social activities with it.

So what did we choose:

Since we had the Facebook page http://facebook.com/kickofflabs  we decided to just have our like button link to that instead of our own URL.  The upside is that it’s easier to manage publishing content to fans on facebook.  The downside is that the facebook insights on our domain (for liked blog entries, visits, or someone just sharing a URL directly by posting a link) are now separate and we have to look at both of them if we want aggregate data.

Back to the moral of this story… before you get too many people sharing your URL you want to decide if you want them liking that or your Facebook Page.  So secure your Facebook page ASAP and you can push people to congregate there.  Thankfully only 14 people had shared our URL when we made the switch and most of them had also liked our Facebook page. 

Who is responsible for quality? Raise your hand.

When I started my career at Microsoft I was on the QA team and I distinctly remember a conversation with one of my team leaders that went something like this:

Me: “We’re responsible for the quality of the product.”

Test Manager: <Laughs>

Me: “Then who owns it?”

Test Manager:Everyone – the job of the QA team is simple to accurately measure the state of product quality consistently.”

Continue…

Skip the splash screen in your apps

Someone reported a “bug” in GoodDay that they “didn’t like the splash screen” I used:

And I admit that I’m not a designer, but I thought this was a clean screen to show while the app was loading.  Until…

I started playing with the built in Apple apps and realized they don’t use a splash screen.  Watch the iPod app open if you want to see what I mean.  They basically load a shell of the UI and then the UI renders on top when it’s ready.  So I set this as my goal.  I built the following “Splash” screen.

In my opinion:

  1. It makes your app feel like it’s loading faster than it is.
  2. You’ll fit in more with expecations that have been set by the default apps.
  3. You don’t have to design a splash screen. 🙂
  4. Apple’s style guide recommends this approach as well… and Apple is never wrong… right?

Now, if you are using PhoneGap to build your application for the iPhone you’ll notice a bug loading the default.png file where it “jumps” 20 pixels right before your app loads as shown here:

If you want to fix this issue you’ll need to tweak the main PhoneGap library code in the following way:

1. Open PhoneGapDelegate.m

2.  Roughly around line 188 you’ll find:  imageView.tag = 1;

3 After that line add: imageView.frame = [[UIScreen mainScreen] applicationFrame];

Hopefully future versions of PhoneGap fix this issue, but for now this will have to do.

Enjoy!

Building an iPhone App Part 4: Selling your App

Having only sold 60 copies of GoodDay you probably should seek advice outside of this post, but these are the things I learned in my app store process.

1. Research your name, keywords, and categories by searching and browsing both the store and google. These are things you can’t change after your app is approved. You’ll also see how bad the app store search is. Unlike Internet searches there doesn’t appear to be any word stemming. So “goal track”, “goal tracking” and “goal tracker” (for example) all seem to return different apps. 🙁

2. It took 8 days for v1 to be approved. Which meant I had time to build the web site after I built the app. 🙂

3. Sales data only updates once a day. It took me a while to learn to stop hitting refresh.

4. You can update your description any time… But that doesn’t seem to impact search results.

5. If anyone knows a way to see all your reviews let me know. For now it seems that you have to pick each country and look for reviews. I don’t see a way to see all.

6. Build in your own feedback/news channel into the app that links to your site. I didn’t do this and now I have no way of knowing what people think or really connecting with users. I would also consider an easy way for people to share it. But thats just a guess for me at the moment.

7 You won’t find out how many people get to your app in the store and don’t purchase. It just seems like that sort of information would be useful. That’s why I’ve used bit.ly to track the success of different links… At least i can see how many people are clicking through my sources.

8. If someone lands on the app page they are way more likely to buy than I imagined… Based on my numbers it seems that about 5% of people that land on an app that costs a dollar seem to purchase. ( this, of course, could be way off. )

9. Direct links to the app store entry seem to do better than linking to your own landing page. This seems like common sense since you are bringing people closer to the point of purchase.

10. Go global. I think it was the default, but I don’t see any reason not to sell an app to all the different country stores. I feel like GoodDay is the David Hasselhof of apps with all the copies I’ve sold in Germany. Next up… Localization.

Thats all for now. It’s at least a good list of things I’d like to do better next time around. Do you have any tips to share?

Building an iPhone app Part 3: 7 Dev Tips

This post is a collection of tips I learned while developing GoodDay for the iPhone with PhoneGap.

1. Start with something off the shelf – After “Hello World” I started with using jQtouch as a shortcut to iPhone UI.  jQTouch is a jQuery plugin for mobile web development.  I’d describe it as a combination of page manager, mobile application theme engine, and a set of UI controls that enable you to easily mimic default iPhone UI.

2. Minify your CSS & script files – Performance is critical.

3. Leverage the jQtouch Tap Event – The tap event is faster than the standard click event because it doesn’t wait the requisite number of milliseconds to register like standard links in Safari.  It makes your app feel more app-like.  For example:

$(‘#removeGoal’).bind(‘tap’, function()

{ deleteGoal(removedGoal, $(‘#goalID’).val());});

4. Pick Tap or Click for browser testing. Of course you can’t use the tap event when testing in desktop safari so you’ll want to define the click event on the load of the application:

var isiPhone = (userAgent.indexOf(‘iphone’) != -1 || userAgent.indexOf(‘ipod’) != -1) ? true : false;

clickEvent = isiPhone ? ‘tap’ : ‘click’;

Then simply use clickEvent instead of hardcoding ‘tap’ all over the place.

5. Disable scrolling if you don’t want your header or footer to move.

document.addEventListener(‘touchmove’, function(e){ e.preventDefault(); });

6. Enable scrolling in regions you want to scroll. You may not want the header and footer to scroll, but you may have a list in the center you want scrolling… for which you’ll need something like iScroll because mobile webkit does not provide a native way to scroll content inside a fixed width/height element… which really takes away from the app-like feeling.

7.  The onDeviceReady() function is not called when you test in the desktop browser… so you’ll also need to break your initialization code into a function that is called only once depending on how the application is being used.  But you’ll want to make sure you don’t try to do too much before the device is ready.

That’s it for now.  In the next part I’ll publish some tips about submitting your app to the Apple Store.

So you want to build an iPhone app… Part 1

GoalListandScores

But you don’t want to learn Objective-C, you aren’t trying to build something that requires high performance graphics, you want it to look and feel like an application, and you are primarily web developer that thinks that things should run cross platform simply.  If this describes you then this series of posts may help motivate you to get started.  In part 1 of this series I’ll look at some of the tools and components that I used to build the GoodDay app

Continue…

Develop Strength Based Product Development Practices

TPS Reports Everyone believes that their product has a few strengths, This is the set of things that your product does better than anything else out there.  If you didn’t you wouldn’t be building it right?  But do you really know what those strengths are?

 

The reality is that you have very little to do with what your true product strengths are.  True product strengths (or TPS for office space fans out there) is really defined in the intersection of what you do well and how customers use the product you sell them. 

image

On the left side you see “Employee Talents”. This is what you are good at building and what you may currently be defining your product strengths as.  On the right side you see customer usage.  This is how your customers are using the product you sell.  In the middle is your TPS… this is the set of things that you really do excel at that combines the two. 

Strength based product development would be a set of practices that focus on growing the True Product Strengths intersection by focusing on them.  A very simplified set of practices could be incorporated into any development methodology:

  1. Self Evaluation – Always re-evaluate your employee talents, what you are good at building, and define the list on the left hand side. 
  2. Customer Listening – Working with your customers to identify what parts of your product they really love and leverage you for.
  3. Create your TPS Report – Create the unison (TPS).
  4. Prioritize the TPS items in your development.

It’s not rocket science and any good company is doing at least #1 or #2, but doing it right involves combining the two into step 3. 

The side effect of doing this right… You will stop focusing on your weaknesses and your requirements become absolutely clear. Other than baseline requirements for all products like security, performance, etc you are wasting time you spend not focusing on TPS.  Features & requirements that don’t focus on TPS will only frustrated your teams since they aren’t good at delivering those things and your customers will complain they get things they don’t need to pay for.

Executing strength based development properly will result in growing the true strengths of your product, employees will love working on things they are good at, and customers will be delighted that you are delivering more of the things they already love about your product.