Good Products Are Viable On A Single Platform

Our clients often ask if we can build them native Android and iPhone apps at the same time for their MVP (Minimum Viable Product). While every situation is unique, if the client is launching a new product or service the answer is usually the same: we’d rather not.

Good products are viable on a single platform. It’s not the product that works in more places that wins. It’s the product that is beautiful, functional, bulletproof, and will resonate with users that wins.

Why Working More Is Not The Answer

At 7PM on a recent Monday, I was asked why MojoTech’s offices were empty.

“Slow time of year for you guys?”

Actually, we’re busier than ever.

Somehow, “I’ve been coding for 12 hours straight” has become a badge of honor, and “you look like shit” is the new pat on the back as your designer leaves the office at midnight.

This is an easy trap to fall into, but in reality these epic pushes are not helping anyone.

Eight Ways To Gamify Your App

Gamification is one of the most buzzed-about concepts in the app world. Clients are constantly asking us to “gamify” their products. And it’s not just startups, either. A Gartner study predicts that by 2015, more than 70% of the world’s biggest companies will have gamified apps.

For those who don’t know, gamification refers to adding game elements — points, badges, milestones, to name a few — to non-game applications. If you’ve used the internet to do just about anything in the past year, you’ve no doubt encountered it.

Now, I’m no fan of the Pimp My Ride approach to development — that is, adding features for the sake of adding features. I’ve written about the dangers of going down that road, and urge you to think hard about your goals before deciding to test gamification in your app.

But for many products, game elements can boost user acquisition, engagement and spending. We’ve found this to be true with apps we’ve built in a variety of industries.

If you’re looking to gamify your app, but don’t know where to start, here’s a list of eight ideas that winning companies — startups and established players alike — use.

Make Your Continuous Integration Server STRIKE FIRST and STRIKE HARD.

If automated testing is a part of your process, you know how much it hurts when tests fail on your master branch. Every red test on master makes it more likely that further breakages will sneak in, for several reasons:

1. If master has failures, when you’re starting to review a feature branch, rather then relying on color recognition (red versus green), you need to use brainpower to separate “new failures” from “old failures”. Whenever you need to use your brain, there’s the chance that you might not end up with the right idea.
2. Even if you never make mistakes, if the first in a series of assertions fails, this can prevent the rest from even running! In other words, because tests are failing, you’re now testing less than you were.
3. Most importantly, good people have a powerful psychological need to preserve beautiful things. A pristine test suite is beautiful, and tends to motivate developers to keep it that way.

How best to keep the master branch green? You could attempt to foster an organizational appreciation that breaking master is a Very Bad Thing, in the hopes that this will make it happen less often. Some folks take this to interesting extremes, including ritual humiliation (however tongue in cheek).

(source: http://www.flickr.com/photos/foca/6935569551/ )

MojoTech Keeps Growing: Meet Duncan Shaw

There are people who travel, and then there’s Duncan Shaw.

Duncan has lived and worked all over the world. His journey has taken him to farthest reaches of China, Australia, Japan, Germany, England and beyond.

And now, we’re beyond excited to announce that Duncan’s latest stop (hopefully for a long, long time) is as Managing Director of MojoTech’s New York City office.

Over the last 15 years, Duncan has run businesses and guided product and brand launches for startups, high-growth and Fortune 500 companies alike. Duncan sums it up best in his own words when he says that “a lot of people claim to have 10-15 years of experience. Many of those people actually have one year of experience, repeated 10-15 times. I’ve always gone out of my way to capitalize and build on my strengths and apply them to the fastest growing segment of the market. That’s exactly where MojoTech is right now.”

Want to make a great product? An engineer isn’t enough.

This post originally appeared as a guest post in The Next Web.

Every few weeks, I’ll be going back and forth with someone about what our team can do for them. They might be looking to build a brand new app from scratch, extend an existing product line or improve on something that they’ve already built.

Then this happens:

“Thanks for helping me define my product more clearly, prioritize my feature set and create some milestones. It was very helpful and your process makes a lot of sense, but I’ve found a programmer on Craigslist who said he could do it for a quarter of the cost.”

Every biz-dev person in every design and development firm that’s reading this is simultaneously nodding their head and face-palming themselves right now.

This happens a lot.

Build Your Product, Then Your Business

You’ve spent weeks obsessing over it, turning it over in your head and convincing yourself that this thing is going to be so good, so disruptive, that the only thing between you and a Google acquisition is the chore of getting the damn thing off the ground.

How do you go about executing?

If you follow the advice of most “10 Things You Need To Do Before Launching Your Startup” articles, here’s how it goes down:

Modals are lazy

Client: We need feature X within the current site

You: Ok I will just make it a modal

When to use a modal

On Type & Visual Hierarchies for Mobile

Be it app design or traditional media, a clear visual hierarchy is essential to good layout and effective communication. Having a well-defined visual hierarchy ensures that users see the information that you want them to see and in the way that it is intended to be consumed. With type, the most obvious technique to creating a hierarchy is to create a disparity in font size amongst type elements. And as such, when we think of “big type”, we often think of important type elements such as newspaper headlines and book titles.

Anyone who’s suffered an amateur PowerPoint deck can relate: manipulation of font-size alone can be crude. This is particularly true of mobile web, where font sizes can only be increased or decreased so much before things start becoming illegible or space constrained. As such it’s a valuable design skill to understand how even subtle changes to other properties (besides font size) can deliver a similar effect.  

Here are some thoughts on those techniques:

Hiring in New York is like hiring for everywhere

One of the reasons we opened our NYC office was greater access to talented designers and developers. It’s a huge market, and it’s trending up-and-to-the-right for all things tech, so I’ve not been surprised by the number of resumes that have been pouring in with New York City and Brooklyn addresses.

One thing I hadn’t considered though is that when you’re in New York you’re really everywhere. How so? Because so many people want to move there. It’s a tremendous advantage being able to hire people that you can work with face-to-face but pull them in from all over the world.