Showing posts with label explain. Show all posts
Showing posts with label explain. Show all posts

2013-11-23

Arguing Versus Debating

(These two words may be synonyms at a basic level, but can mean two different things.)

It is useless to have two different words mean the exact same thing.

Typically, there are different levels of meaning (i.e., big vs huge vs gargantuan). But, unfortunately, it takes a long time to learn the specific differences/intricacies between all of the words we use. So, in order for us to better communicate our thoughts to one another, I write this post. Here is goes:

I don't like to argue. But, I do like to debate.

If I ever say, "I don't like/want to argue", then this is really what I mean...

Here's my common definitions for "arguing":
- At a rudimentary level, "complaining for the sake of it".
- At a basic level, "explaining, using logical fallacies".
- From a chess perspective, "perfectly symmetrical debating that has stalemated 5+ moves ago (think: KvK)".

Here's my common definitions for "debating":
- At an elementary level, "listing pros and cons"
- At a fundamental level, "two sides taking turns, presenting their ideas to the other. Typically has an outcome."
- From a military/infantry perspective, "arguing in the form of bounding overwatch, where progress is achieved."

If you have any comments about arguing versus debating, then I'd like to hear you in the comments below.

~ Danial Goodwin ~

ps - One reason I like to spend time to write posts is so that:
1. I can better understand myself,
2. Others can better understand me,
3. Others can better understand themselves,
4. Others can better understand each other,
5. And, if there are comments, then I can better understand others. ;]



2013-11-08

Working Title, "Basically, Android Expained"

I am an Android developer. I have been one for a few years now. In that time, I've had the pleasure of helping many people with technical questions. I believe one of my specialties is being able to explain complicated concepts in simple, laymans terms.

Over the years, I was bound to give repeat answers eventually. So, in order to keep myself more efficient, I will start adding all of my layman explanations to a wiki, which I will eventually probably turn into some sort of ebook.

The book will be titled, "Basically, Android Explained". I still have a few working ideas for a tagline.

I chose to title the book this way because almost all my explanations start off with "Basically, ...". This single word is very important to my explanations because it signifies that what follows is NOT everything explained. It is just the easiest explanation for a non-developer or a new developer.

I'm not sure of the entire structure that I want to use for my definitions, but one way is to have the first sentence be "Basically, ...", then the following sentence would be a more technical definition, then after that will be the reasons for using it.

For good measure, here's an except:
KeyStore: (also referred to as a Java keystore or keystore file) A security certificate used for authorization. Basically, an app's signature. It proves that the app was made by a certain developer. This is a precautionary security measure that prevents malicious apps from replacing another app."

That was just a quick rough draft, I have a few more ways to explain this concept. Feedback always welcomed.

~ Danial Goodwin ~

Title: Basically, Android Explained
Description: Where advanced technical concepts are abbreviated to quick/light readings.



2013-08-26

Graphs: 3x4 Types Of Goods And Services

The following graph explains the three different types of goods and services very well. It helps in determining what type of pricing structure you should use when you sell something. In my realm, it is how to price a smartphone application.

After the picture is my own take on the 3 categories.


Categories, from left to right:
1. Consumables, seasonal apps, fad/meme apps: These apps will be used only a few times at the most, then eventually probably uninstalled. Examples include apps that play off from something happening in the news, or an app for an Internet meme like that one dancing craze I forgot about already (Harlem shake).

2. News, reference sheets, utilities, tools: These apps will always be of use to the user, and functionality in them typically don't change drastically. Examples include flashlight apps, unit converters, information apps about a particular topic, and hourly/daily/weekly news feeds.

3. Productivity, social, leveling-up games: These apps get more useful the more you use them. Example: When you store more files in Dropbox, then the app becomes more useful to access, backup, and share files, thus you use it more. When using these apps, there is either a real or perceived difficulty in changing service providers. Users may worry about the future of these apps much more than the other two categories.

In each of the app marketplaces, apps that fit the first category (with consumables) are the most prevalent. And, apps in the third category are the most scarce. And, or course, there are always exceptions in the examples I gave, I will not list them all here.

Here's the pricing structure that should be used, in general, for each of these categories (if you want to make money from the app). An easy way to remember is: charge for the app when it is the most valuable to the user.
1. Charge once, early.
2. In order of preference: (1) Subscription model to keep all the information updated, or just to have access to the data/information. (2) Charge once, early. Then have additional (major) updates cost extra. (3) Ads.
3. Freemium: App should start off free and have enough basic features in order for most users to be satisfied with that. Then you should charge for more features only to users that get the most value out of your product. If you never have to update the app again, then a one-time fee is okay. But, if you are going to be providing updates to the app, then don't work for free! A subscription model or in-app purchases will allow you to stay in the business of creating more great apps and keeping that one updated and fresh.

But, wait! There's more!
You don't have all the information yet required for building a proper business model. In addition to those 3 categories above, your app can be further classified into one of the following 4 categories.

This following graph should give you a more thorough understanding of what type of app you have:


(I have labelled the quadrants according to mathematically standards with 1 in the top-right, going counter-clockwise to 4 in the bottom-right. A few hand-selected apps are positioned roughly in their corresponding quadrants.)

The biggest take-away from this graph is that most apps in the market are in quadrant 3 (least profitable), and it is very rare to have an app in quadrant 1, the most profitable quadrant.

Wide appeal apps have the luxury of choosing to only charge once and still be in a profitable business because many new smartphone users will always need/want these apps. Thus, a "never ending" source of income. Narrow appeal (niche) apps will not be able to draw as many downloads. So, a charge once business model is not sustainable in the long run. Though, many developers of quadrant 3 choose to create a framework and keep switching out the data to create new apps very quickly and easily. Example: A Chuck Norris joke app and Shakespeare Insult app could share 95+% of the code by just changing the database where the information is pulled. So, by creating many cheap niche apps, these developers are effectively reaching quadrant 2.

In order to effectively/successfully create a profitable premium app, users must "need" the app. There is also probably little to no [close] competition. Your app has to truly shine. These apps correspond to the category 3 (freemium) apps of the first graph. Category 2 apps from the first graph are most likely to be classified in quadrant 2 or 4. And just about all Category 1 apps from the first graph are located in the third quadrant, but not apps in the third quadrant are category 1.

If you have any further thoughts to share, then I'm all ears.

~ Simply Advanced ~

Additional great resources:
[1] http://www.xda-developers.com/android/the-smart-way-to-price-your-mobile-app-xda-developer-tv/
[2] http://mobile.smashingmagazine.com/2012/11/07/succeed-with-your-app/
[3] http://blog.ideashower.com/post/21276590202/why-pocket-went-free
[4] http://www.bradfordcoffey.com/bid/81600/pricing-model-lessons-matching-the-timing-on-value-price