Intents in Android

If you’re an iOS developer who’s never had a chance to work with Android, there are a few things that you should have a look at.  My favourite part of Android is the Intent system.  It’s an easy and flexible way for apps to add features.

In iOS, when you want to allow the user to send an email from within your application, you instantiate an MFMailComposeViewController and present it.  But what if you’re a Gmail user?  We’re stuck sending you through the default mail sheet.

On Android you instead send an mail intent.  This is a way to say to the system “I want to send an email”.  The system picks your default mail app and presents a send screen.  It’s far more flexible and respectful of user choice.

Mail is just an example.  You can send an intent to do just about anything, and define custom intents of your own.

Extensions in iOS 8 look like they’re bringing a level of this flexibility to iOS.  I’m eager to see if the implementation results in the same explosion of choices available on Android.

Four Phrases

A friend once told me that running a business is like volunteering to be bipolar.  You alternate between incredible highs and lows.  The highs are worth the lows, for me at least.

You develop coping strategies to help get through the rough times.  I like to keep a file that reminds me of why I do this in the first place.

Here’s an excerpt from that file.  These are four phrases that I use to help ride out the rapids.

 

Here’s to the Crazy Ones

This is from the famous “Think Different” campaign that Apple ran.  If we aren’t trying to make a dent in the world, then we need to change what we’re doing.  It may be an ad, but it’s a good reminder too.


A Ship in Harbour is Safe, but that’s Not What Ships are for.

This one is a quote from William G.T. Shedd.  Every time I find myself thinking that a 9-to-5 job might be the way to go, this helps remind me that I’m here for a reason.  I might limp back to harbour after this is all said and done, but I’ll limp back proud.


He Taketh with him two angels, inspiration and perspiration, and worketh to beat hell.

The copy of the poem I have claims it was written by James X Cahill, but Googling says it’s anonymous.  My Dad sent me a copy of this when I asked him how to learn more about sales.  I’ve read an awful lot of books and gotten a lot of advice, but nothing makes success actually happen except getting out the door and working hard.


You could have been a fire truck all along.  (There’s still time)

Another poem that reminds me to dream.  Before you start a company, you spend a lot of time dreaming and picturing the future.  Somehow you get bogged down in the day-to-day details and don’t spend near as much time refreshing that ambition as you should.

 

Of course there are other things in the file too, but if I had to throw everything else away, these are the four phrases I’d keep.  Reading through these is usually enough to get me over whatever bump I’m stuck on.

I Like Uphill Battles

I just finished playing Artemis with a group of friends.  It’s a spaceship bridge simulator – basically the computerized equivalent of the game of make believe every nerdy child played after watching an episode of Star Trek.  Six people man different stations and coordinate amongst themselves to stop an alien invasion.

I don’t really like video games, but I love Artemis.

Often I play ‘Captain’ when we play.  That means I don’t even have a computer in front of me.  Rather, I ask questions, make tactical decisions, issue orders, and act as a coordinator to the rest of the team. The other parts are fun too, but what I really like to do is turn up the difficulty, select the most outclassed ship in the game, and try to lead a team through it.

What I’ve found is that I like uphill battles.  When mopping up the enemy is just a matter of going through the motions I get bored.  Even when it’s tight but winnable, it feel too easy.  I need the game to be downright impossible.  My own personal Kobiashi Maru.

I often find I have to be almost certain I’ll lose for something to be worth trying at all.  I’m attracted to big risks, and I suppose the corresponding big rewards.  To get any of those rewards, you have to be willing to eat certain failure an awful lot.

If the past couple years of running Whole Punk have taught me anything, it’s that there’s a kind of joy in resiliency.  I don’t like failing, but I like fighting to win, and I like standing up again after I fall.

I’m certainly not the only person I know like that.  So many of my favourite friends are the ones who try big things and get back on the horse with a grin, no matter how back they hit the dirt.  I admire people who play life on hard mode.

I Don’t Worry About the Web So Much

It was just over six years ago that I spent a lot of time thinking about web apps.  I was a Mac developer working on a couple of different shareware apps.  The software world was very different, especially if you live in the Apple ecosystem.  There were no App Stores and the iPhone didn’t have a native SDK.

There were a lot of exciting things happening in the web sphere.  Frameworks like Cappuccino and SproutCore were making the desktop approach obsolescence.  At least that’s how I felt.

That’s not something I worry about anymore.  If anything, I feel like web apps have stopped approaching with such ferocity and are idling.  Part of that is that mobile development has drained a lot of the developer talent off the web.  Part of that is that we’re reaching the limits of what’s practical to do in modern browsers.  And part of that is the App Stores, helping to nullify the web app distribution advantage.

Or maybe this is just a pause while mobile specs catch up to the point where the native / web gap doesn’t matter on phones and tablets.  Who knows?  Any who cares?  This could be what maturity feels like – I care less about the technology we use to build a thing and more about the cool things we can do.

I’m convinced that the web has pioneered quite a few business models that we’re starting to adapt to.  Small regular payments instead of lump sums for their use.  Ad supported business models.  Free-to-use for the 99% of users that don’t need expert features.  There are a lot of good ideas here.  We’re going to use them.

Now that I’m not seeing the web as the enemy, I can see the good parts much more clearly.

Design on the Phone Screen

When you’re a first-time mobile designer, the lowest hanging fruit for creating good designs is previewing on an actual device.  Simulators don’t count.  Slapping iPhone.jpg around your PSD as a frame doesn’t count.  You need to actually hold the design in your hand.

I often get to work with designers who are taking their first stab at designing for mobile.  Mobile design has been around for a few years now, but it’s not yet a common skill.  In the same way that web and print have different design processes, mobile also has it’s own unique toolset.  We see a lot of common errors while they get up to speed on the new platform.

The most frequent one is the amount of content that they’re trying to fit onto a single screen.  It looks great on a Cinema Display, but when you bring it down to pocket size, the text is often eyestrain-worthy or worse.  Perfectly reasonable looking buttons are obviously unusable.

You’ll find that previewing the design on the device solves that.  Even if there’s no functionality, just trying to tap the buttons provides insights on hard to reach areas.  Trying to read the text means that you won’t overload the screen.  Common design mistakes become easy to pick out.

There are tools to help you with this.  If you’re looking for a minimal solution, I recommend LiveView, which just positions a viewport on your desktop.  Whatever’s in that frame gets transmitted to your phone.  If you can’t manage to part with Photoshop, this is an easy tool to use with any design app.

If you’re willing to go further, I recommend learning how to use Sketch.  It’s designed for interface designers, makes exporting assets an absolute dream, and has a companion app called Sketch Mirror that streams your designs to your phone without having to fiddle with viewports.

When you design for print, you deal with printed proofs.  It would be insane to trust that you can translate your design from one medium to the next without error.

I get designs that have been approved for development when they’ve never been viewed on an actual phone.  That’s absurd.  Mobile is no different from any other format – designing without outputting to the final medium is the same as designing blind.

“Fixed!”

I used to be terrible at answering email.  These days I maintain inbox zero.[1]

For a long time, I didn’t like answering emails unless I had a solution.  I loved writing the email that showed how smart and efficient I was.  The problem was fixed already!

It never failed to impress.

Except, of course, not everything can be fixed immediately.

Instead, emails would sit in my inbox for a day or two, gnawing at my conscience while I got the problem taken care of.  Because it doubled as a todo list, both my todo list and my inbox were disaster zones.  And since new email kept coming in, things would eventually get lost in the shuffle.

Then, a couple of years ago, I had the pleasure of working with a really good communicator.  He explained that the biggest thing to do right is business communications is expectation management.  It’s more important to tell people you heard them than it is to respond with an immediate solution.

The good business guys know how to set expectations.  “I’ll get back to you with an update by Monday”, or even just a good old “Thanks for the heads up, we’ll put it on the list!”

Disentangling my todo list from my email was helpful.  Getting over my ego and responding with the expectation instead of the fix was a revelation.

Now my rule is that I just have to set the expectation and put the item on my todo list immediately.  Each new email is a ticket in the bug tracker rather than a crisis that has to be handled now.

It’s been good for my customers, my reputation, and my sanity.

[1] Or at least unread zero.  I’ve never seen the point of moving everything to a different folder if ‘read’ == ‘taken care of’.

Re-signing Apps

At Whole Punk, we’re working on a new product that removes an awful lot of the grunt work from UI testing.  We’re using UIAutomation to build full state graphs of the UI, and then generating a pretty doc of all the screenshots and crashes we detect.

It’s a brute force approach – it takes hours for a mid sized app or days for a large one.  But who cares?  I’m happy to have a computer do a days worth of work so I can spend ten minutes reviewing the UI for unexpected display bugs.

The alternative is that I’d do the work myself.  I’m also thrilled to have a computer in charge of finding the low-hanging crashes and handing me reproduction scripts.  Most companies we deal with hand this sort of testing off to an intern.  We think a computer is faster, more comprehensive, and ends up giving better data.

Enough with the sales pitch.

In order to do this testing, we need to be able to run UIAutomation scripts via instruments.  One of the restrictions we ran into is that we can only run UIAutomation scripts on apps that are signed with our development profile.

Since our ambition is to run this as a service, we needed a way to resign apps with our development profile.  The answer turns out to be pretty simple:

/usr/bin/codesign -f -s “YOUR_DEVELOPMENT_CERT_NAME” —resource-rules APP_PATH/ResourceRules.plist —entitlements ENTITLEMENTS_PATH APP PATH

The entitlements file should contain the following:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>get-task-allow</key>
<true/>
</dict>
</plist>

 

And voila, we can run UIAutomation against apps we didn’t build.


Technologically Conservative

Within two weeks of the Swift announcement, clients were asking me if I thought we should be writing new apps in Swift.  The answer, and I hope this doesn’t surprise you, is a resounding NO!

Swift needs time to stabilize.  We need to write plenty of bug reports and feedback on it.  As a community, we need to learn where it’s limits are and establish a new set of best practices for it.  I’m not shipping code on a platform that’s still defining it’s syntax.

As soon as I make those points, everyone nods and agrees.  “Hm,” they say, “we hadn’t realized that it’s still in flux.”

It’s not just languages that have this issue.  A version one of any API as almost moving a little bit.  Sure, the method calls might stay the same, but the behaviour can change subtly underneath you as bugs are fixed and edge cases are recognized. [1]

I do my damnedest to avoid shipping code that relies on new APIs [2]. I don’t like shipping code when I don’t fully trust the libraries beneath it yet.

That said, of course I’m working on side projects with Swift and all the new APIs that catch my attention.  Though I’m conservative in what I ship, I’m far more liberal in what I code.

I like my side projects to push into the new and shiny.  In the words of The Friz: “Take chances, make mistakes, and get messy!”

There can be a fine line between being conservative in your views and being regressive.  Make sure you’re pushing back for the right reasons.  Colour outside the lines when you can.

Footnotes

[1] It’s easier to recognize when your compile breaks as the language updates, but shifting APIs can break your app too.

[2] Unless the goal is to get featured in the App Store by using the newest APIs.  That’s certainly not a bad goal.

Business Plan Fallacies

I recently had coffee with a business student working on his capstone project.  He wasn’t sure about a few things, and his professor had given him my number.

He told me about his plan and showed me his spreadsheets, along with business plan drafts his classmates were sharing.  They had a lot of great ideas about product, but great product isn’t enough to launch a business.

These students had just spent four years learning about entrepreneurship, but they lacked practical experience.

A lot of what I’ll say here applies only to businesses where sales take place predominantly online.  Here are four things you should know when you’re putting together a business plan:

 

Your Time Has Value

Every business plan had the assumption that any tasks the student could perform on their own cost nothing.  The most extreme case was one woman who was proficient at web design and was coding up her own site.  She had written down the cost of the website as equalling the cost of hosting it.

These business plans were extremely optimistic about when they’d start showing profit because they left out their major expense.

If you had to hire someone to do these tasks, how much would that cost?  That’s the amount you have to account for your time.  Otherwise your financial projections are dishonest.

Lots of people work without pay when they’re starting their company, but you should be aware that you’re borrowing money from yourself to do it. 


You Don’t Have a Business Plan Without a Sales Plan [1]

Every one of the business plans I saw had a neat idea for a company.  They had distinctive flairs that existing companies in the space didn’t have, they took unique advantage of emerging technology, they had products that seemed like they would be purchasable for reasonable amounts of money.

None of them described how they were going to promote and sell the product.

How will people hear about your business?  How will they find it, decide that they trust it, and learn how your product makes their life better?

“We’ll have a website” isn’t a full answer to any of those questions.

 

Network Effects Matter

When he told me about his business plan, he emphasized that there was a huge market.  Thousands of local buyers used the existing competitors to purchase high value items every month.

If he could get just a few sellers posting to his site every month, that would bring in enough income to make the business worth running.  How hard could it be to convince 1 or 2% of sellers to list on his site as well?

My guess would be ‘very hard’.  And if you could succeed in getting sellers to move at all, you’d probably get a lot more than 2% of the local market.  Some businesses are subject to network effects – the reason you go there is because everyone else goes there too.

Network effects mean that it’s a hell of a lot harder to convince the first few people to use your service.  Remember this every time you think about launching anything where the value is in the other users.

Your local sandwich shop doesn’t have this problem.

 

You Can Test a Business Without Spending All The Money

When you have a vision of the product in your head, it’s tempting to spend all the time, effort, and money of building the thing before you test out the business side of things.  You know you’ve got a winner, you know people are going to buy, so build it and they will come.  But that’s a terrible idea.

You can’t be sure that someone is going to buy until you’ve actually got their money in your pocket.  It’s worth testing that you have a market before you pump tens of thousands of dollars into a bet that might not pay out.

My preferred way of testing is to build a ‘coming soon’ landing page.  You can buy a theme for a few dollars, spend an hour putting up the page, and buy a few ads to see if you’re getting anyone interested.

Take pre-orders, but make sure that the customer is aware it’s a pre-order and it’ll take a little while to fulfill.  Don’t promise anything that you’re not certain you can achieve in a reasonable timeframe.

If you run your sales process for a week or two and don’t get any bites, make some changes to your plan and try again.


Footnote

[1] The corollary to this is that you don’t have a business without sales.

Fear of Blogging

I just finished reading Ash’s piece on sharing.  It’s worth a look.

I haven’t blogged in years.  By all rights, I should.  I have expertise, a list of topics, and a personal domain that I don’t really use since I moved from ‘freelancer’ to ‘consulting company owner’.

There are plenty of reasons why I don’t blog.  First there are the made up ones: I can’t find the time, there are too many blogs out there already, I have too many things on my plate already.

Then there are the real reasons: I don’t think my voice carries enough value, I’m worried about looking silly and having it on record, too many of the things I want to talk about have the potential to offend people.  I’m afraid of being the fool.

The best way to get over your fear is through exposure.  Nobody gets better at rappelling without jumping off a cliff.

So I’m going to give this a try for 30 days.