Call me an idealist. Call me crazy. But I think technology is supposed to be used to change people’s lives for the better. I believe a good technology improves my life as a human being. Take the telephone for example. Imagine instead sending and receiving letters back and forth across the ocean. Of course every technology can be used for unethical purposes as well but what I am interested in this particular article is the initial motivation for building technology. Most particularly in the software industry.
So I went to the professionals. The ones who “did it” before. The successful ones. I read an article about a series of lectures given by established entrepreneurs in the software business, to young aspiring software entrepreneurs, all arranged by the now famous Y Combinator start-up school. I found
After reading carefully, I found some advice on motivation. I came across this piece of advice from Max Levchin, the co-founder of PayPal:
As a final word of product development advice, Levchin encouraged founders to think about the Bible’s seven deadly sins - especially greed, sloth, envy, pride and gluttony. These characteristics, he said, describe many of the primal motivations for users.
Hmmm… Stop right here for a moment. Mr. Levchin, I was looking more for something along the lines of “what sort of technology can we build to improve people’s lives”, not “people are destroying their lives anyway, so let’s build technology that helps them do it better”. That’s ridiculous and sad, but it’s real. And what’s even more sad, it’s that it looks like this advice, was received like some sort of super secret from the masters by the young aspiring entrepreneurs.In view of this, I truly wonder what else they teach at Y Combinator.
Money should not be everything. When it becomes everything for you, you will lose in life. You will bawl your eyes for the things you missed because all you saw is the bottom line.
One of the most crucial entry-level barriers to mobile software development is the wide variety of platforms. To date there are thousands of Java-enabled handsets. Large companies attempt to purchase as many devices as possible and thus cover their bases but what about the small and medium-size players?
Is buying every single device on the market an option? Clearly not.
One idea being tossed back and forth in the mobile industry is the concept of an universal emulator. That is, an emulator which would be able to emulate every single device out there. At present, device vendors such as Nokia, Motorola, and Sony Ericsson have been very good at providing free SDKs and emulators. The problems are still manifold. First of all, not every single device is supported, and the ones that are supported differ in the level of emulation accuracy compared to the actual device. In addition there is no real standard in terms of emulation, other than the Unified Emulator Interface (UEI) which is starting to pick up pace (using UEI emulators). Even if this does become the standard, we’d still have to support non-UEI emulators. Furthermore, managing all emulators from every single vendor would be a nightmare.
Here’s a proposed idea: test every single MIDP and CLDC api call on every single device
This is an almost impossible task of course. But if we did have this kind of data, and if it were always fresh and up-to-date, then we could more easily reproduce API bugs. We would essentially be aware of all KVM discrepancies in the market. We could even build a UI tool to emulate a real KVM which would thus reproducing every API bug on every device.
That’s as close as I can think of getting to the Universal Emulator idea.
There’s no easy way of getting a feel for a mobile game before actually buying it. Other than a crappy screenshot and a short description, it is the brand that sells a game, not the actual quality of it.
Idea:On-device mobile application bundle manager
Assuming the user would have the manager client installed on their device, then they could download sample 10-30 second game bundles which they would load into memory and use to get a feel of the actual game. Since in J2ME dynamic class loading is out of the question, one design choice would be to include a basic game skeleton in the client app which would act as a container for the game pack. The game bundle itself would of course have to be written according to some kind of custom language. In essence, the developer would write a short demo of their game in this custom language, add a few images (sprites, tiles, etc) then bundle everything up in some sort of binary, compressed format then publish it.
Here’s an idea about an app that would relate to a wider audience than the typical mobile gamers.
Idea:Personal relationships manager
The user would create a list of his/her close friends and family members and once in a while, he/she would rate a particular friend or family member based on certain criteria - friendliness, compassion, caring, etc. - on a scale of 1 to 10, based on events that happened during that particular day or say last few days. If the friend in question has the application as well, then the rating could go both ways. The user would then be presented with graphs representing “ups and downs” in his/her relationships.
Mobile operators are the rulers of the wireless world. They control the last-mile, the link to the end-consumers, through their private mobile portals. Due this massive control, they have the final say as to what sells and what does not. Users have a wide variety of content available in the mobile catalogue but browsing the products is difficult, and the true value of the product is not truly visible. Especially for games, a game title, a small text description and an optional screen shot is all the user gets. It is no wonder that it is the branded content that wins the user’s attention, and thus large publishers focus on large brands, spending large amount of money for development. The small developers are left out the operator decks, since they cannot afford big brands. In many cases, the end users are disadvantaged since unbranded content does not necessarily imply lower quality.
A Potential Solution
A disruptive, end-to-end mobile distribution model, giving small developers a fair playing field, while empowering end users with more control over the process of browsing and purchasing content, such as ring-tones, wall-papers, games and applications. This model would compete directly with mobile operators.
How it would work
The user joins the community by creating a profile on the community web site.
The user enters information such as email address and device information (i.e. phone #)
The user receives a WAP push message on the device, to download the mobile client.
The user may buy credits on the web-site, for later use in buying mobile content.
The user starts up the mobile client and logs into the community network.
The user browses for content, which is downloaded on demand by the mobile client.
The client makes requests and receives content responses from an HTTP server.
The mobile client displays text and images and plays sounds and animations.
The mobile client may also download short demo packs.
When the user decides to buy a product, the client checks if the user has enough credits.
If enough credits are available, a one-click button completes the transaction.
The client sends a request to the HTTP server signaling the transaction.
The server sends a WAP push SMS message to the user device.
The client displays a message telling the user to wait for an SMS message, then exits.
The user receives a WAP push SMS and clicks the URL.
The device opens a web browser and starts a download.
The user may follow the on-screen instructions to complete installation.
What happens if the Carrier blocks access to and from our servers?
Glad you asked. Let’s put it these way. They can block one, two, three, dozens of servers but not thousands. And where would we get thousands of servers? This is where P2P would come in. In a community-driven effort, P2P can always offer us a list of carrier “white-listed” addresses to and from our mobile clients.
If only the carriers would smarten up… Oh well, it’s up to the community - once again - to solve this problem.