Collaborate from Anywhere in AR

Remote collaboration tools can’t come fast enough, and these tools will be a massive benefit for every aspect of a venture lifecycle. Spatial uses the space around you to create a shareable augmented workplace. Remote users can collaborate, search, brainstorm and share content as if they were in the same room.

How much to make an App?
Estimate the cost of an app easily using this handy tool. http://howmuchtomakeanapp.com/

One Size Fits Some

“Paid-up-front iOS apps had a great run, but it’s over. Time to make other plans.”

(via Marco.org)

This article from Marco Arment on his pricing strategy for the upcoming Overcast app has created quite a stir. I encourage you as an app developer to read it. There are a lot of valid points in it.

I don’t disagree with most of what he wrote. But when I get to a line like the one I just quoted above, I’m reminded of exactly what bothers me about most blog articles from app developers: “This is true for me, so it must be true for everyone and every other app in the universe.” The one-size-fits-all mentality that caused the race to the bottom in the first place continues.

If I were Marco, making a podcast app for iOS, I’d be considering seriously something other than a pay-once-up-front business model. Of course, I’m not going to be making a podcast app anytime soon, because I have no intention of getting into what’s already a crowded and I think pretty well-served market. Nor would I want to compete with his new app by any means. I’m sure it’ll be good, and deservingly successful.

There are many other kinds of apps where moving to this sort of model might make a lot of sense, too. It’s certainly worth careful consideration. But the problem arrives when you assume that all iOS users think and behave alike, and therefore all apps must be monetized similarly.

If we were to convert Teleprompt+ to the free with in-app purchase model, for instance, the three of us at Bombing Brain would be out of business in a couple of weeks.

Our customers are primarily prosumers and pros—people who wouldn’t trust their business to a “free” app. Our high price is a large part of what has made us successful in this market. (Along with years of cultivating a reputation for being better than our competition.) Converting this particular app to free with in-app purchase now would likely be an unmitigated disaster. We know, because there have been free alternatives that have crashed and burned. Hard.

Our target customers, the few who don’t blink at $15-$20 for an iPad app, are completely oblivious to the entire “free” app market. Free = invisible to them when it comes to finding solutions for their businesses.

To be fair, I don’t think Marco is actually suggesting that companies like ours change business models. But I do fear that too many developers read posts like this and walk away with that impression.

The fact is, there is a whole world of untapped potential on the App Store for developers who can solve real problems for people who are happy to pay. I’ve said it a million times, but it bears repeating: it’s not about price; it’s about trust. People are willing to spend money if they are sure what they are getting will solve their problem.

Is it easy to convince people that your app is worth a fair price? Of course not. Does that mean that you should make your app free in hopes of enticing a small percentage of people to convert to “paying” users? Not necessarily. Not for every kind of app, at least.

Giving a limited app away for free and charging to make it feature-complete is, in theory, one way to build trust. But given the reputation in-app purchase has acquired over the past few years, it’s going to take serious convincing before professionals, prosumers, and small business owners view IAP as anything but a scam in the short term. This is unfortunate, but you will be judged by the unscrupulous developers who have abused IAP before you, whether you like it or not. So you’re going to have to work even harder to gain that trust than you might think when associating yourself with this pricing model.

While it is true that the vast majority of iOS users scour the App Store looking for free alternatives, there is a not-insignificant number of users who wouldn’t go near a “free” app with a ten-foot pole. In their minds, free-with-in-app-purchase apps are all essentially Candy Crush.

So the risk is gaining a large number of users who are unlikely to pay you and who will write tons of bad reviews, while completely turning off the most valuable demographic in the Store.

Users looking to pay a premium price may be few and far between, but each one is ten times more valuable than the “average” iOS user to a developer like me.

Then there’s also the bulk of the education market to consider, which can’t, as a matter of policy, use any app with in-app purchase.

The point is, there are lots of different kinds of users in the App Store. And you need to know which ones are the most likely customers for your app. Don’t go treating them all equally.

Marco’s argument is essentially one of market share. He views total number of users as the primary goal. He wants to target as large a percentage of the total iOS user base as possible. That’s a perfectly valid business model that has worked for many. And for a podcast app, I think it’s a smart way to go. But it’s not the only way to skin this cat.

There are millions of iOS users in the world. I only need a tiny fraction of the right users to be successful.

I guess what I’m saying is, take everything you read from other developers (including myself) with a grain of salt. There’s no one way to be successful at this thing. Different apps in different markets, with different audiences, command different business models. You need to think about how you want to monetize your app long before you start building it. Consider all the options carefully. But don’t dismiss any of them out of hand because of what one or two others have experienced.

I’m happy that more devs are experimenting with in-app purchase as a legitimate way to encourage people to “try before they buy.” Look no further than MoneyWell for iPad as a primary example of IAP being used with positive results. Of course, this is an established company with a paid companion Mac app that already has a reputation for quality. Your mileage may vary. And, as Kevin Hoctor himself admits, his preliminary numbers are likely to be skewed for at least a few more months. But maybe in the long run, in-app purchase will gain the trust of users that currently avoid free apps like the plague. I think it’s going to be a long, uphill battle.

I look forward to seeing how other such experiments from other developers go. In the meantime, be cautious with anyone who tells you there’s only one way to go about doing things on the App Store.

Source

The Art of Creative Coding. PBS Digital Studios. Programming plays a huge role in the world that surrounds us, and though its uses are often purely functional, there is a growing community of artists who use the language of code as their medium. Their work includes everything from computer generated art to elaborate interactive installations, all with the goal of expanding our sense of what is possible with digital tools. Source

In cooperation with Nissan Motor Co., Ltd., the VOICE DRIVER Production Team has developed the world’s first motor sports VOICE DRIVER,making it possible to drive a car using voice commands alone. All you need to enter the race is your voice. No complicated driving operations are needed as the volume of your voice is translated directly into the car’s propulsion.The auto body used is that of Nissan’s flagship FAIRLADY Z sports car. This is a race game that enables anyone to enjoy the FAIRLADY Z driving experience.. Source

“The creative process is just that: a process. Recognizing value that others have missed doesn’t require preternatural clairvoyance. A well-honed creative process enables us to intuitively recognize patterns and use those insights to make inductive predictions about divergent ideas, both vertically within categories, and horizontally across categories. By understanding the genealogy of innovation within a given category, we can imagine what might come next.”

—

Source

Principles behind the Agile Manifesto

Article: Source

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in 
development. Agile processes harness change for 
the customer’s competitive advantage.

Deliver working software frequently, from a 
couple of weeks to a couple of months, with a 
preference to the shorter timescale.

Business people and developers must work 
together daily throughout the project.

Build projects around motivated individuals. 
Give them the environment and support they need, 
and trust them to get the job done.

The most efficient and effective method of 
conveying information to and within a development 
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. 
The sponsors, developers, and users should be able 
to maintain a constant pace indefinitely.

Continuous attention to technical excellence 
and good design enhances agility.

Simplicity—the art of maximizing the amount 
of work not done—is essential.

The best architectures, requirements, and designs 
emerge from self-organizing teams.

At regular intervals, the team reflects on how 
to become more effective, then tunes and adjusts 
its behavior accordingly.

Agile Software Development: A gentle introduction

Article: Source

Computer science is a young science. Computer programmers my age were trained by engineers. That training dictated how we approached software development for an entire generation. But now after decades of building software to be expensive, unwanted, and unreliable we have come to realize software is different. Building software is more like creating a work of art, it requires creativity in design and ample craftsmanship to complete. Software remains malleable, often illogical, and incomplete forever. Agile software development is based on fundamental changes to what we considered essential to software development ten years ago.

The most important thing to know about Agile methods or processes is that there is no such thing. There are only Agile teams. The processes we describe as Agile are environments for a team to learn how to be Agile.

We realize the way a team works together is far more important than any process. While a new process can easily improve team productivity by a fraction, enabling your team to work effectively as a cohesive unit can improve productivity by several times. Of course to be eligible for such a big improvement you must be working at a fraction of your potential now. Unfortunately, it isn’t that uncommon. 

The most brilliant programmers alive working competitively in an ego-rich environment can’t get as much done as ordinary programmers working cooperatively as a self disciplined and self-organizing team. You need a process where team empowerment and collaboration thrive to reach your full potential.

The second change is making the

customer, the one who funds the software development, a valuable and essential team member. When the dead line gets close a traditional approach to reducing scope is to let the developers decide what will work properly and what won’t. Instead let the customer make scope decisions a little at a time throughout the project.

When your customer, or domain expert works directly with the development team everyone learns something new about the problem. True domain expertise and experience is essential to finding a simple, elegant, correct solution. A document can have plenty of information, but real knowledge is hard to put on paper. Left alone programmers must assume they know everything they need. When asking questions is difficult or slow the knowledge gap grows. The system will get built, but it won’t solve the problem like one guided by an expert on a daily basis.

Perhaps the biggest problem with software development is changing requirements. Agile processes accept the reality of change versus the hunt for complete, rigid specifications. There are domains where requirements can’t change, but most projects have changing requirements. For most projects readily accepting changes can actually cost less than ensuring requirements will never change.

We can produce working software starting with the first week of development so why not show it to the customer? We can learn so much more about the project requirements in the context of a working system. The changes we get this way are usually the most important to implement.

Agile also means a fundamental change in how we manage our projects. If working software is what you will deliver then measure your progress by how much you have right now. We will change our management style to be based on getting working software done a little at a time. The documents we used to create as project milestones may still be useful, just not as a measure of progress.

Instead of managing our activities and waiting till the project ends for software, we will manage our requirements and demonstrate each new version to the customer. It is a hard change to make but it opens up new ways to develop software.

Take a guided tour of Agile Development by following the  buttons starting here. Or continue your guided tour ofExtreme Programming by following the buttons. Let’s look at how we manage by features next.