Apple has introduced all three iPhone iterations during the summer, starting with the release of the original in 2007. Given the fast-moving nature of the industry, Apple will most certainly introduce a new iteration of the iPhone next year, if not during the now-typical summer season, then for sure before the holiday season of 2010.
Considering the iPhone's strengths and weaknesses, as well as the state of the competition, the following is a look at what the likely "4G" iPhone will look like. It is based not on sources, but extrapolation of current trends and an attempt at reading the market, so while these predictions are conservative, I also think they're fairly likely to come true.
Screen Upgrade
When it was introduced in 2007, the iPhone boasted one of the best screens on a mobile device, however it has not changed 2 and a half years while phones like the Motorola Droid or HTC HD2 have been introduced with larger, higher-res screens(3.7+-inch, 800+pixels). Apple clearly has to upgrade the iPhone's screen soon to remain competitive, however one of the iPhone's advantages has been providing a unified platforms for developers where all devices have the same screen.
Thus, I think its highly likely that the next iPhone will have a 960x640 screen impacting existing applications minimally by upscaling everything by 2. Developers will have to upgrade their image resources, but impact beyond this should be minimal. In addition, given the increased density, I think the screen will be bigger than the current 3.5". By cutting back on the large amount of dead black area on the face of the device, Apple should be able to fit in a 3.7-4" screen without noticeably altering the device's profile.
CPU and Memory
The 3GS gave us a much needed speed improvement, but the iPhone is still a very resource-constrained device, so while I think the CPU may see only a moderate speed increase (maybe 700Mhz compared to the current 600), I think the device's RAM will be doubled to 512MB.
Radio Quality
Given the high-end nature of the product, the call and connection quality of the current crop of iPhones can be described as "mediocre" at best. In positioning the iPhone as a gaming, internet and multimedia device, Apple has been able to get away with this so far, however I think the next iteration of the iPhone will have some noticeable improvements in its DSP, as this will improve one of the product's biggest weaknesses.
Camera
The current 3MP camera is pretty average and improving it seems like low-hanging fruit, so I think we'll see at least a flash and possibly a 5.2MP camera in the next iPhone.
Storage
I think the current 16GB and 32GB models are more than adequate for the vast majority of users, so I think its unlikely that we'll see a 64GB iPhone.
App Store Genius
With over 100,000 Apps in the Store, it's getting increasingly hard to find new apps. Using your list of installed apps (and possibly how much you use them) and your App Store ratings, it would be straightforward to build recommendation system for the App Store. Apple already has the genius feature working for music and with the Netflix Challenge winner's algorithm being publicly available, they also have access to a top-notch algorithm.
More Developer Power
While I am not very hopeful, perhaps the continued success of Android and its openness combined with continued developer complaints about its review process will convince Apple that is perfectly OK to give developers more power, such as access to system logs or background processing. Phonalyzr is one example of a somewhat popular Android app (currently #8 in the communication category) that is impossible to write on non-jailbroken iPhones.
Saturday, December 19, 2009
Monday, November 30, 2009
Why Perl Lost It
Over the last several years it has become fairly obvious that Perl has lost the prominence and popularity it enjoyed in the late 90s and early 2000s, which can be seen from many different angles:
On the low end, PHP became the defacto web development language thanks to its ease of development and deployment. While many developers decry PHP's ugliness and its simplistic nature (no closures, no namespaces, 3000 functions), it nevertheless made web development far more accessible to everyone and thus allowed a huge number of people to make the products they wanted, and helped some notable companies (Flickr, Facebook etc).
On the other end, Python's steady improvement over the years (which made it both more powerful and easier than Perl) attracted a lot of companies and developers, while Ruby and Rails attracted developers who wanted more flexibility out of their language. While this was happening, there were no significant releases to Perl5 and Perl6 was nowhere in sight.
Another significant factor I believe was Perl's much beloved "There's More Than One Way To Do It" principle. While marketed to developers and giving them freedom and flexibility, it also hamper's Perls practicality.
First, it makes the language extraordinarily complicated. While most good designs struggle and strive for simplicity and coherence (the K.I.S.S. principle), Perl goes for the kitchen-sink mentality. Its table of operators can only be described by "gargantuan" and is only eclipsed by its grammar, which is at least 5 times larger than the grammars of languages like Python and Haskell. What this means is that Perl demands far more time out of a developer to become proficient at it, while offering no significant benefits for someone investing this extra time.
Second, it makes it hard for the community as a whole to progress. For example, while Python added new-style classes and pushed everyone into adopting them, there is no way for Moose to easily obtain the same ubiquity (as no one can push it and enforce it). In fact, it is rather telling that Perl's premiere web development framework, Catalyst, only acquired a decent object system in mid 2009.
Whether Perl will continue to decline or not is hard to say, though I highly doubt it'll ever return to its former glory - neither Perl5 nor Perl6 seem to offer much for developers who do not already love Perl.
[1] http://www.google.com/trends?q=perl%2C+python%2C+ruby&ctab=0&geo=all&date=all&sort=0
[2] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
[3] http://langpop.com/
[4] http://www.slideshare.net/Tim.Bunce/perl-myths-200802?src=embed
[5] http://blog.newint.org/tech/2009/11/26/perl-dont-ingore-it/
Easter Egg: The Forex Chart Monkey gives advice on Picket Prevention and Forex Technical Analysis
- Google Trends [1] and the TIOBE index [2] show a steady decline over time [1]
- A wide reaching survey at Langpop places Perl near the bottom [3]
- A lot of Perl talk centers around people vigorously stating that Perl is not dead [4] and other kinds of cries for attention [5]
On the low end, PHP became the defacto web development language thanks to its ease of development and deployment. While many developers decry PHP's ugliness and its simplistic nature (no closures, no namespaces, 3000 functions), it nevertheless made web development far more accessible to everyone and thus allowed a huge number of people to make the products they wanted, and helped some notable companies (Flickr, Facebook etc).
On the other end, Python's steady improvement over the years (which made it both more powerful and easier than Perl) attracted a lot of companies and developers, while Ruby and Rails attracted developers who wanted more flexibility out of their language. While this was happening, there were no significant releases to Perl5 and Perl6 was nowhere in sight.
Another significant factor I believe was Perl's much beloved "There's More Than One Way To Do It" principle. While marketed to developers and giving them freedom and flexibility, it also hamper's Perls practicality.
First, it makes the language extraordinarily complicated. While most good designs struggle and strive for simplicity and coherence (the K.I.S.S. principle), Perl goes for the kitchen-sink mentality. Its table of operators can only be described by "gargantuan" and is only eclipsed by its grammar, which is at least 5 times larger than the grammars of languages like Python and Haskell. What this means is that Perl demands far more time out of a developer to become proficient at it, while offering no significant benefits for someone investing this extra time.
Second, it makes it hard for the community as a whole to progress. For example, while Python added new-style classes and pushed everyone into adopting them, there is no way for Moose to easily obtain the same ubiquity (as no one can push it and enforce it). In fact, it is rather telling that Perl's premiere web development framework, Catalyst, only acquired a decent object system in mid 2009.
Whether Perl will continue to decline or not is hard to say, though I highly doubt it'll ever return to its former glory - neither Perl5 nor Perl6 seem to offer much for developers who do not already love Perl.
[1] http://www.google.com/trends?q=perl%2C+python%2C+ruby&ctab=0&geo=all&date=all&sort=0
[2] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
[3] http://langpop.com/
[4] http://www.slideshare.net/Tim.Bunce/perl-myths-200802?src=embed
[5] http://blog.newint.org/tech/2009/11/26/perl-dont-ingore-it/
Easter Egg: The Forex Chart Monkey gives advice on Picket Prevention and Forex Technical Analysis
Saturday, November 21, 2009
The Making of BlockBattle.net
Welcome to the first of a series of blog posts I'll be writing about the ongoing development of BlockBattle.net. Although the project is several weeks old, it is still early in the development life of the game and I am hopeful that these posts will provide some insights to other developers about working with some interesting new technologies, as well as random tetris and network-programming related tid bits.
BlockBattle.net is in essence a modern implementation of the classic Tetrinet game. For those who are not familiar with Tetrinet, it is a fun and well-made multiplayer version of Tetris. Up to six players can join a game, then divide themselves into teams. Once the game starts, every player gets to control a single tetris field. When they make a line in their field, a random block will turn into a special power/attack and if a line is destroyed that includes that special power/attack, the power gets transfered to the player's attack queue. As the game progresses and players make lines and accumulate powers, they can use those powers/attacks either on themselves or on other players. For example, if a player gets a Clear Line and Add Line powers, they use use Clear on themselves and Add on an opponent.
While the original Tetrinet was great, it is now an old game (it was first released in 1997), works only desktop OSs and makes it really hard to find players on demand. BlockBattle.net (so named so that it does not infringe on any trademarks) will be web-based version, available across modern web-enabled devices (iPhone, Android etc) as well as any modern web browser. In addition, BlockBattle.net will offer automatic on-demand player matching and focus on simplicity of game play. It is my hope that BlockBattle will turn out to be a novel, fun and engaging game for users, while offering an interesting exercise in game, UI and web development for the developers.
The major design outlines of BlockBatte.net are:
For some silliness, check out the Forex Chart Monkey that helps you with Pickpocket Prevention and Forex Technical Analysis.
BlockBattle.net is in essence a modern implementation of the classic Tetrinet game. For those who are not familiar with Tetrinet, it is a fun and well-made multiplayer version of Tetris. Up to six players can join a game, then divide themselves into teams. Once the game starts, every player gets to control a single tetris field. When they make a line in their field, a random block will turn into a special power/attack and if a line is destroyed that includes that special power/attack, the power gets transfered to the player's attack queue. As the game progresses and players make lines and accumulate powers, they can use those powers/attacks either on themselves or on other players. For example, if a player gets a Clear Line and Add Line powers, they use use Clear on themselves and Add on an opponent.
While the original Tetrinet was great, it is now an old game (it was first released in 1997), works only desktop OSs and makes it really hard to find players on demand. BlockBattle.net (so named so that it does not infringe on any trademarks) will be web-based version, available across modern web-enabled devices (iPhone, Android etc) as well as any modern web browser. In addition, BlockBattle.net will offer automatic on-demand player matching and focus on simplicity of game play. It is my hope that BlockBattle will turn out to be a novel, fun and engaging game for users, while offering an interesting exercise in game, UI and web development for the developers.
The major design outlines of BlockBatte.net are:
- The front-end game play will be done in JavaScript. Piece movement, generation, etc will be done client-side, while major events (dropping a piece, attacking an opponent) will be sent to the server so all player fields are synced at all times.
- Using HTTP Long-polling (AKA Comet) to enable the sever to push events to the client, such as the player getting attacked.
- Rather than the Tetrinet way of finding players, whereby one person starts a server and other players connect to the IP, BlockBattle.net will try to automatically match players, so users can simply log in and start playing
- Making the game accessible on mobile devices by embedding a WebBrowser within an application, then making local inputs (buttons, gestures, taps etc) control the game.
- JavaScript/DHTML for the game front-end.
- Tornado Webserver - Tornado is a real-time python webserver that powered FriendFeed's website. Tornado was chosen because it is a fast, lightweight framework well suited to the needs of a push server. As well, it is written in Python which is popular, easy to develop for and quite powerful.
- Mobile Apps: Popular mobile devices such as the iPhone, BlackBerry and Google Android phones will have native apps for BlockBattle, each of which will offer as simple UI customized to the handset and the kind of controls that are suitable for it.
For some silliness, check out the Forex Chart Monkey that helps you with Pickpocket Prevention and Forex Technical Analysis.
Friday, May 22, 2009
Why the BlackBerry Storm 2's UI Could be a Winner
The original BlackBerry Storm came out in early December and despite a fair amount of anticipation and heavy promotion by RIM and its launch partners (Verizon in the US, Bell and Telus in Canada), the device received a thorough skewing in the blogotubes.
The complaints against it were numerous and ranged form well-deserved criticism to trollish whining, the most valid of which were:
However, it seems RIM is not satisfied with this and has taken people's complaints quite seriously. The unstable software (which was, at least somewhat understandably, rushed in order to catch the holiday season) has been undated to remove many of the original problems, however solving the hardware problem is much harder. Earlier today, Engadget posted some photos of the rumoured Storm 2 [2], which is due many months ahead of the usual 12-16 month refresh cycle, along with confirmation that the tacticle "SurePress" screen of the original Storm is gone.
In order to understand why the original click screen was needed we have note the differences between the BlackBerry OS and its main competitors - Android and iPhone OS. While both Android and the iPhone were under active development (2005-2008), the BlackBerry was already a pretty full-featured smartphone established in the corporate space. In order to support a multitude of features (the BB email app can do almost everything desktop Outlook can), the BB OS takes a more desktop-app like approach in which there is a distinct difference between selecting items and performing actions on the items. This makes much sense when supporting things like selecting several emails and choosing one of many different actions to support (moving to folders, deleting, flagging etc).
The iPhone OS and Android on the other hand, do not support selecting items and instead opt for a narrower feature set with a simpler UI. This works well for a lot of poeple, however the approach will breakdown if too many actions are supported. For example, forwarding and replying on the iPhone show up as buttons when an email is opened at the appropriate key is pressed, but what would the UI look like if instead of 3-4, there were 10-15 such buttons?
Being constrained by the way their OS worked, RIM thought they had a good solution in letting the touch screen do the selecting, while the pressing of the screen performed the action. Unfortunately, this turned out to be a huge bother in most use cases, such as selecting menu items, pressing buttons and especially typing. Thus, the SurePress screen turned out to be both essential and devilishly annoying.
With the Storm 2, RIM seemed to have realized this mistake and are touting something called the TruePress screen. While no one at the gadget blogs (Engadget, CrackBerry, Boy Genius, etc) seems to have use the Storm 2, I think that by making a few small changes, RIM could have a real winner on their hands. Namely:
Whether the Storm 2 will be able to solve all the problems and preset a credible threat to Android and the iPhone remains to be seen.
The complaints against it were numerous and ranged form well-deserved criticism to trollish whining, the most valid of which were:
- A generally crummy build of the OS
- The odd, love-it-or-hate-it-but-mostly-hate-it click screen.
However, it seems RIM is not satisfied with this and has taken people's complaints quite seriously. The unstable software (which was, at least somewhat understandably, rushed in order to catch the holiday season) has been undated to remove many of the original problems, however solving the hardware problem is much harder. Earlier today, Engadget posted some photos of the rumoured Storm 2 [2], which is due many months ahead of the usual 12-16 month refresh cycle, along with confirmation that the tacticle "SurePress" screen of the original Storm is gone.
In order to understand why the original click screen was needed we have note the differences between the BlackBerry OS and its main competitors - Android and iPhone OS. While both Android and the iPhone were under active development (2005-2008), the BlackBerry was already a pretty full-featured smartphone established in the corporate space. In order to support a multitude of features (the BB email app can do almost everything desktop Outlook can), the BB OS takes a more desktop-app like approach in which there is a distinct difference between selecting items and performing actions on the items. This makes much sense when supporting things like selecting several emails and choosing one of many different actions to support (moving to folders, deleting, flagging etc).
The iPhone OS and Android on the other hand, do not support selecting items and instead opt for a narrower feature set with a simpler UI. This works well for a lot of poeple, however the approach will breakdown if too many actions are supported. For example, forwarding and replying on the iPhone show up as buttons when an email is opened at the appropriate key is pressed, but what would the UI look like if instead of 3-4, there were 10-15 such buttons?
Being constrained by the way their OS worked, RIM thought they had a good solution in letting the touch screen do the selecting, while the pressing of the screen performed the action. Unfortunately, this turned out to be a huge bother in most use cases, such as selecting menu items, pressing buttons and especially typing. Thus, the SurePress screen turned out to be both essential and devilishly annoying.
With the Storm 2, RIM seemed to have realized this mistake and are touting something called the TruePress screen. While no one at the gadget blogs (Engadget, CrackBerry, Boy Genius, etc) seems to have use the Storm 2, I think that by making a few small changes, RIM could have a real winner on their hands. Namely:
- By removing the click screen and going with a touch-only screen, RIM can make the user experience much better in the vast majority of cases (selecting menu items, clicking buttons) by not requiring the odd screen-click
- In order to support the essential differentiation between selecting items and performing an action on an item, RIM could require that in cases were something could be selected (a list of emails for example), a single capacitative touch could select the item, while a double-click would perform the action. In addition to freeing them from the click screen, a double-click would also be familiar to a lot of people used to laptop touchpads.
Whether the Storm 2 will be able to solve all the problems and preset a credible threat to Android and the iPhone remains to be seen.
Subscribe to:
Posts (Atom)