Sencha Touch provides full browser back history support, so that if the browser back button is tapped, the application will go back to the previous URL in the history list.  This is useful because when running an app on an Android phone, the browser back button is available.  However, Safari can hide the back button if the app is launched in web application mode.  For the latter reason, we made a back button available within the application.

Initially, we coded the app back button to mimic the browser back button behavior, in which it would go back through the history until it reached the app launch page. This was accomplished by adding actions to the Sencha Touch Ext.app.History.actions array.  However, we found that it would be more useful to be able to use the back button to switch back and forth between the search results page and the details page. A home button was provided to get the user back to the initial page to start a new search. In addition, the search results page and the details page each had navigation buttons to go forward and backward through the list of results and the details, respectively. The navigation between the pages would reflect the most recent details page viewed, by highlighting the record on the search results page and by navigating back to that view when returning to the details page.

Search Results page

Details page

Back to Search Results Page

This all worked fine except for the case when the browser back (or forward) button was tapped instead of the app back button. Then the behavior reverted back to going back and back and back (and possibly out of the app). This was particularly a problem for us because we implemented a state-machine to keep track of which pages had been viewed so that the app could display a back button from the main page if necessary or in the case of a permalink taking a user directly to a details page, the back button would not be displayed at all, as there was no page to go ‘back’ to.

App Startup page

Startup from Permalink URL

Home after Permalink

Navigating between pages in our application was accomplished by using the routes configuration in the page controllers and Ext.RedirectTo().  The redirect function populated the Ext.app.History.actions array and the windows.history.   We also used the function animateActiveItem() to animate the transition between pages.

Ideally, we would have disabled the browser history back button while in the app. However, since we couldn’t do that, we analyzed what was happening in the code and mitigated the effect by the following solutions:

1. Cleared the History actions list on a new search. The action list would be cleared back to the action that represented the search (home) page. This accesses a documented  private object  (Ext.app.History) in the Sencha Touch library.

To view the actions list in the debugger, we wrote a function called showHistory():

showHistory()
History actions 
	showHome  
	showListings listings 
	showDetails details/1 
	showDetails details/2 
	showDetails details/3

2. Minimized using Ext.redirectTo. In this case, only once for the Search Results page. The Details page used it for each selection of a details view. When going back to previous views, the history.go(-x) was used, where x is calculated based on the number of details pages that were viewed .  We used Ext.redirectTo during development to emulate requests to the server providing the data. As we started to integrate the data server, we found that we didn’t always have to call it to redisplay data that had already been loaded.  We were able to manipulate the page view based on what had already been viewed.

3. Captured change events on the Application.getHistory() object. If the current state did not match the current url, then a ‘back’ state event was consumed on the state machine to attempt to match up the current state with the url.   This is a weak ‘hack’ that must be corrected in a future release.

We also considered detecting changes on the windows.popstate event, but it fired when an action was added or removed from the history array.  This created the challenge of keeping track of whether the state had just been pushed to the history list or if it was being popped during a change to a different page. We possibly need to reduce our state machine to allow us to use this properly.

Using the popstate event in conjunction with the pushState and replaceState methods is supposed to allow you to mimic URL redirection without actually redirecting.  This would allow the application to be one element in the browser history. We are investigating how to accomplish this in our next project.

References

HTML5 Rocks Presentation

Sencha Touch History Support

Sencha Touch Ext.app.History

Dive Into HTML 5

The Motivation
We built their previous mobile property search application using our first generation technology, which we developed and released into the market over 3 years ago. Needless to say, mobile technology has advanced significantly over that time, and the original application was beginning to show its age, both in looks and performance. Together with Comey & Shepherd, we felt it was time to give the application a facelift by improving the look-and-feel, user interface, branding, and performance of the application. We also wanted to put in place an architecture that would allow us to continually improve the application by incorporating new features and making adjustments to existing ones.

The Approach
As with the first generation application, we chose to stick with a web-based approach. A mobile web solution using HTML5 and CSS3 provides a user interface on par with a native application and allows us to address both iPhone and Android devices with one development. Plus, we can provide updates to the application in real-time, use standard analytics and measurement techniques, and leverage the marketing of the website to promote the mobile application.

Our goals for the upgraded design were to enhance the look of the site to match the current Comey & Shepherd branding, to provide a more engaging user experience by incorporating standard mobile UI elements such as loading indicators, animations, carousels and gesture interfaces, to put in place a modern architecture that would provide the ability to add more features to the application over time, and to incorporate deeper analytics so we could better measure the performance of the application to understand which features are working and, just as important, which ones were not.

For the implementation phase, we chose to use the Sencha Touch framework. It provided both the features and performance improvements we were looking to attain, and it is a solid development platform that lays the foundation for adding features to the application.

The New and Improved Look (and performance)

1. The Home Page
   Below are images of the previous generation application (on the left) and the latest generation (on the right). You can see that more emphasis has been placed on the branding, with the Comey & Shepherd logo prominent across the top of the application and colors updated to better match their website. There is also a footer in the new version that is locked to the bottom of the screen to provide navigation through the application as well as a contact button that makes it easy for clients to reach Comey & Shepherd. We also moved the location search to the top of the page to make it easier to find (and use), as the old version had the location search below the fold.
   
2. Larger Thumbnails and property identification
   The thumbnails for property search results have been enlarged so users can get a better view of the properties, and we’ve made it easier, for compliance purposes, to tell which properties are listed through Comey & Shepherd and which are provided through Broker Reciprocity. We also included the icon indicators from the Comey & Shepherd website that shows properties that are under contract (red ball), have an open house scheduled (blue ball), or have just come on the market (green ball).
   
3. Navigation Improvements
   The pagination of the listings pages have been improved to allow for back and forth movement through listings results, and navigation between details pages has been added. Previously, users were not able to move back and forth between details pages without going back to the listings pages. There’s dedicated home and back buttons in the footer that keep track of the user’s navigation through the application, providing a native app-like experience (see screenshot above and below).
4. The Details
   A photo carousel has been added to the details page so users can swipe through photos without leaving the page (as before), and the property details has been moved to a panel to keep the main details interface cleaner and easier to read. A second contact button was also added to the details inset so users can quickly get additional information on a property. If the property is listed by a Comey & Shepherd agent, they are connected directly to the agent, otherwise they are connected to  a Comey & Shepherd office for more information.
   
5. Under the Hood
   Significant performance improvements have been made in the application by utilizing many of the local storage options available through HTML5. For example, property search results are stored locally to limit interactions with the server and to speed up moving from page to page. Likewise, once loaded, details pages are also stored locally for quicker movement between properties. Overall, the application is using the HTML5 Application Cache so the application files and static images are stored on the client’s phone, which makes for a much faster and more consistent loading time when users return to the site.

Analyzing the Results
The application has been live for just over two weeks, and we’ve already gathered quite a bit of data. In a short amount of time, some interesting trends are already developing:

• Street searches trump Location searches
  Believe it or not, but only 25% of the searches performed are by location. In fact, the leading search is for properties by street name, which comprises almost 40% of the searches performed. We’ll be keeping a close eye on this statistic going forward, as I was completely caught off guard by this and figured the location/advanced search distribution would be flipped.
• Navigating details pages is more important than navigating listings pages
  Another curious finding is that users tend to primarily navigate forward on listings pages and rarely move backward. The forward button to back button ratio on listings results pages is ~50-to-1. Details pages, on the other hand, have a much more even distribution of browsing back and forth.
• Most Contact events happen from the Home Page
  Most users are utilizing the Contact Us button from the home page. My guess is that people are looking for quick information after loading the app (like an office or agent phone number) and go straight to the contact button to connect to Comey & Shepherd.
• The Details Contact button gets good usage
  Adding a Contact button to the Details inset area was a late addition to the app, but it has turned out to be a good one. It doesn’t get as much usage as the Contact Us on the home page, but it isn’t far behind either.
• People are interested in More Details
  Here’s another statistic that surprised me. I thought most people were not that interested in the detailed description of a property, since it’s mostly marketing speak. However, over 10% of the details pages viewed are checking out the property description, which is 4-5 times higher that I would have expected.
• Details pages are important
  On average, users are viewing 4-5 property details pages per search completed. What does this mean? It means that the property details pages are important and that people are looking at them.

What’s Next
There is a lengthy list of features that we are planning to add to the application that includes mapping, property sharing, additional contact options (such as email and text), and more office and agent information. Before we start implementing however,  we’re going to let the site age a bit so we can gather more analytics. We will be looking for usage trends to identify any areas of improvement and to see what can be done to increase conversions through the application. The bottom line, mobile is still evolving and moving fast, so the application will be a work in progress.

The application is best viewed using an iPhone and Android powered mobile phone. Simply open your phone’s browser and go to http://www.comey.com to start your property search!

What is Facebook Home?
It’s an Android Launcher, which, in Webopedia’s terms, is the part of the Android user interface that lets users customize the home screen, launch mobile apps, make phone calls, and perform other tasks on Android devices. Every Android phone has a built-in launcher application, but there are numerous launchers available in the Google Play Store (see here), and Facebook will add to that list.

What are the features?
I don’t want to get into too many details here since they’ve been reviewed in the tech blogosphere by Gizmodo, Mashable, and Engadget, but the short summary is that it will provide a streamlined version of your news feed called Cover Feed, integrate with your phone’s contacts, make it easy to message your contacts through Facebook, and simplify sharing updates and photos, even easier than their Android app.

Why develop a launcher?
From a user perspective, Facebook has created a launcher to provide the user with a more engaging Facebook experience on their phone. While reviews are a bit mixed, I’m sure that Facebook will continue to improve the interface based on usage and user feedback.

From Facebook’s perspective, it wants to increase time spent on its social network in order to collect more data so it can generate more revenue through mobile advertising. By coupling your location with your Facebook interactions, Facebook will be able to target you with more relevant ads. In other words, the ads will be very lucrative as advertisers will be able to target not only you but also your intentions. For example, imagine arranging lunch plans with friends using Facebook Home, and while you are near a restaurant shortly thereafter, you are targeted with an ad for half-price off your meal or a free dessert. In other words, be prepared to be targeted if you use Facebook Home, which may not be such a bad thing if the ads are highly relevant.

Should you install it?
If you are a fan of Facebook and/or a heavy Facebook user, then you should download and try it out. I would only caution you that Facebook will collect even more details about you, which isn’t different than what Google or Apple does with their operating system, but may be a little unnerving given how cavalier Facebook has been with users’ privacy and data in the past.

If you don’t use Facebook much or are concerned about privacy, then you should stay away. While I would like to try it to evaluate the interface, I’m not going to install it. I’m going to rely on reviews from others because I don’t trust Facebook. I know that you can uninstall it, but the paranoid side of me is concerned that uninstalling won’t completely erase everything allowing Facebook to continue to collect data, which I’m not comfortable with. My views are similar to Om Malik of GigaOM, which he articulated way better than I can in this article. Even a hands on wasn’t able to convince him otherwise.

Summary
Facebook Home is an application for hard core Facebook users. Otherwise, I would recommend caution before installing the application and awareness of what Facebook’s end game is – to make money off of mobile advertisements using the data you provide them.

My preference of the three options is to bring your own. I like the idea of being able to buy any device you want and then decide which plan you want to use with it. I started moving this direction over a year ago, and when my current contract with T-mobile was up this summer, I was planning on moving to a prepaid service plan for me and my family.

I reviewed our monthly usage and found that we were using our phones primarily for texting and data. The number of minutes used on a monthly basis was pretty low. I had my eyes on T-mobile’s $30/month prepaid plan that included 100 talk minutes, unlimited text, and unlimited web with up to 5GB at 4G speeds.

The new T-mobile plans presented me with another option, so I decided to compare the three options: their classic contract plan, their new Simple Choice plans, or the prepaid plan I was considering. Here’s what I found over two years:

Phone cost: $800 ($200 x 4 lines)
Total cost over 24 months: $5,120

Phone cost: $2,400 ($600 x 4 lines)
Total cost over 24 months: $5,760

Phone cost : $2,400 ($600 x 4 lines)
Total cost over 24 months: $5,280


Considering I buy the latest smartphone, which typically retails for approximately $600 or is subsidized at $199, the classic plan that I have is the best value over two years. Of course, the Simple Plan does offer unlimited minutes, but based on my usage, that isn’t important for me. The prepaid plan certainly gets a lot closer to the classic plan, but it still doesn’t beat it.

In fact, the only way I can beat the classic plan I currently have is to either buy cheaper phones up front or to keep the phones for longer than 30 months. After that, the classic plan is not a good value.

The morale of this story, make sure you do your homework and run the numbers before changing plans or carriers. Your situation may be different than mine and result in greater costs and/or savings between plans.

While former Google CEO Eric Schmidt tried to deny the merging of the operating systems in a recent interview, the fact that the other two major OS vendors are consolidating their efforts provides a strong signal. As pointed out in a Gizmodo article commenting on Google’s changes, both Apple and Microsoft have been working at merging their mobile and desktop operating systems into one. It’s only natural that Google would start moving in the same direction, and what better way to do it than to have both teams report to the same person?

There’s also a strong motivation to merge the two efforts. Maintaining and managing two separate operating systems is inefficient (and hard). Google has exhibited through its spring cleaning efforts that it is not afraid to make tough decisions to reduce costs and inefficiencies. A merger of Chrome and Android, at least from the outside, seems like it would be a slam dunk. In my mind, it would be as simple as encapsulating Android within Chrome and providing a method to install and run Android apps. It may not be the best way, but it could be a simple way to get started while a better and/or more robust solution is developed.

So is this the beginning of the end for Android? I don’t think so – it will survive. Google will somehow fold Android, or Android capabilities, into Chrome OS, but Android will continue to be available on a standalone basis. I wouldn’t be surprised if Google were to step aside as the leader of Android and leave it for the open source community to take over. In this way, manufacturers could continue to use the Android operating system, continue to evolve and grow it with the help of the open source community, and even fold it into their own browser-based operating systems.

When looked at in this context, Eric Schmidt is right on with his comments. Android and Chrome OS will continue to stay separate for a long time. However, he doesn’t say that Chrome will not take on features of Android or allow Android apps to run inside of it, something that people are chomping at the bit to see in their Chromebooks, particularly the Chromebook Pixel. Plus, he’d be foolish to pre-announce the demise of Android. Such an announcement could produce an Osborne effect around Android in which people begin to abandon the operating system before Google has had a chance to migrate them to Chrome.

In the end, I don’t see the merging of the operating systems as a matter of “if”, only”when”.

We attempted numerous methods of instantiating the list and the additional components, but we were not able to get them to display in the order we wanted. The list would not show up, or when we got the list to display, the disclaimer, copyright notice, and page footer would either show up in the middle of the displayed list, or they would appeared jumbled and in the wrong order.
The code sample for the structure of the page is:

Ext.define("MyApp.view.ListContainer", {
    extend: 'Ext.Container',
    xtype:'listings',
    requires: [
        'MyApp.view.Header',
        'MyApp.view.Footer',
        'MyApp.view.TableView',
        'MyApp.view.Disclaimer'
    ],

    config: {
        // we want layout to be of type vbox
        layout: {type:'vbox', pack:'start'},  
        cls:'page',
        scrollable:true, 
        items:[
            // header logo	
            {xtype: 'header', docked:'top'},
            // titlebar that tells what records are being displayed
            {xtype:'titlebar', docked:'top', 
                title:'Loading Results', 
            }, // end of titlebar

            // Load list as a list
            {xtype: 'listView'},
            // Instantiate disclaimer after list
            {xtype: 'disclaimer', cls: 'myAppDisclaimer'},
            // Instantiate slogan and logo footer
            {xtype: 'footerPage',},
            // Instantiate footer with copyright notices
            {xtype: 'copyright',},
            // Footer with back button, contact us button and home button
            {xtype:'footer', docked: 'bottom'},
        ]} // end config and its items
});

Here is the List extended to use our store and itemTpl:

Ext.define("MyApp.view.MyList", {
    extend: 'Ext.dataview.List',
    xtype:'listView',
    requires: [
	    'MyApp.store.MyStore',
	],

    config: {
	id: 'myList',
	store: 'MyStore',
	cls: 'myList',
	// parent is scrollable
	scrollable:false,

	itemTpl: new Ext.XTemplate(
		'<img src="{thumbnail}" />',
		'<h1>{FullStreetAddress}</h1>' ,
		'<p>{City}, {State}</p>' 
	}) // end XTemplate
},  // end config
});

Finally, we decided to create the list on our own using a container and building a table of items, and then appending the disclaimer, page footer and copyright notice. It was a bit of a hack and not as simple and elegant as using the List element, but it allowed us to achieve the desired effect.  The following code example creates the xtype for the tableView. We replaced {xtype:listView} with {xtype:tableView} in the ListContainer view defined in  the above code example.

Ext.define("MyApp.view.MyTable", {
    // Extend container, not dataview, as we to setup a vbox
    // for the listings, and then put the listings inside the vbox
    // using the xtype dataview
    extend: 'Ext.Container',
    xtype:'tableView',
    requires: [
	       'MyApp.store.MyStore',
	],

    config: {
	layout: 'vbox',
	cls: 'myview',
	scrollable:false,

	// Use items here to instantiate table with divs using xtype dataview
	items: [
		{
		id: 'myTable',
		xtype: 'dataview',
 		scrollable: false,
		store: 'myStore',
            		emptyText: 'Please return to the Home page and start a new search.',
		cls: 'myTable',
            		itemSelector: 'div.tableRow',
		itemTpl: new Ext.XTemplate(
			'<div class="tableRow">' +
			//  thumbnail image
			'<div class="tableThumbnail"><img src="{thumbnail}" /> </div>' +
			//  details
			'<div class="tableSummary">' +
			'<h1>{FullStreetAddress}</h1>' +
			'<p>{City}, {State}</p>' +
			'</div>' +
 			'</div>'  //close outer div

		) // end XTemplate
		} //end xtype dataview
	] //end items
   },  // end config
});

So what did we learn?

• The List element in Sencha Touch is useful for displaying list of data from a store if you do not have any other elements, or just one, that you want to display in the same container as the list. (One item can be displayed at the bottom of the list using the scrolldock command, but trying to scrolldock multiple elements does not allow for control of the order of display.)
• Building a list using a generic dataview is better and gives you more layout flexibility if you want to display additional items in the same container as the list.

The winners were JDI by Simon Brunel, Weathy by Boris Orduñez & Ariamnet López, and SnapsMate by Brett Hannah. You can read the full results over at the Sencha Blog by clicking here.

The contest was a great idea as it encouraged developers to push the envelop and demonstrate the capabilities of the mobile web. All three winners did a tremendous job developing a functional app in the two months they were allotted to complete their work. I also felt it was a great opportunity to review their work and discuss the pluses and minuses of each app. Following is my thoughts on each app, which is not a review of the app idea itself, but a review of the techniques, features and functionality of each.

JDI - a to-do list/task management app

Likes: The app is very responsive, scrolling is smooth, and animations are clean and well done. The registration process is simple, and the instructions are easy to read and understand. The overall look-and-feel of the app is very well done. I liked the color schemes, fonts, placement of elements and use of icons. I also felt animations were used in a way that enhanced the user experience without overdoing it.

Dislikes: The app does not work on the stock Android browser of my Galaxy Nexus, which is a big minus (I had to use the Chrome browser or an iPhone5). In addition, the app is not intuitive. You need to do a bit of reading to understand how it works as well as how to operate it. I would have also suggested they used the fullscreen mode available on iOS and pushed the browser URL bar off the screen. Finally, there was an issue on the iPhone where it was constantly loading even while in operation.

Weathy – an interactive weather app

Likes: The design does a good job tapping into location for the weather, and I really liked how they incorporated the auto complete for cities when using the search box.  The placement of edge menus is really cool (once you figure it out and get the hang of it), and the touching of the icons to switch between the day and night forecast makes for a great user experience. I also liked how they made use of cards in their design for each major piece of functionality and thought the color schemes made for a great look.

Dislikes: Unfortunately, the app is not very intuitive. It took me a quite a while to figure out how to add cities to the side menu, as well as delete them once added – some hints or instructions would be very useful. The mapping was also very laggy, and it was virtually impossible to zoom in and out on the iPhone. As with JDI, for some reason the browser URL bar was still visible on the iPhone, and the stock Android browser was a no-op, which is a huge negative in my opinion.

Snapsmate – a photo sharing wall

Likes: I really liked the idea and implementation behind Snapsmate. It has a very simple and clean interface that makes it easy and intuitive to use. I was impressed how the app was able to access the native Camera and file system as well as how you were able to manipulate photos after capture, particularly the rotation effects. Pushing photos backward or forward works great, and the app is very responsive given the graphics manipulation. I felt it was a good vehicle to demonstrate the capabilities of HTML5, and with a little work, I could easily see the use cases for such an app.

Dislikes: The app isn’t as polished as the others. For example, saving to the home screen did not make use of Apple touch icons. I also couldn’t figure out to navigate between walls if you created more than one.

Overall, there wasn’t one app that stood out above the others for me, but I would rank them as follows across these 3 key dimensions:

Form – best looking
1. JDI
2. Weathy
3. Snapsmate

Function – best use of HTML5 features
1. Snapsmate
2. Weathy
3. JDI

Idea – best app concept
1. Snapsmate
2. Weathy
3. JDI

If you’ve had a chance to look at the apps, what were you most favorite and least favorite aspects of each?

The Browser is the OS
If you’re able to watch the first minute of the video above, you’ll immediately see a key distinction of the operating system – it’s a browser. In other words, every application is run inside of a browser, including traditionally native functionality such as the phone dialer and camera.

A New Concept
The first reaction is that Mozilla is introducing a new and unproven concept, but this is a trail that has already been cut and cleared by Google. Their line of Chromebooks uses the Chrome OS in the same way at a laptop level. In other words, a Chromebook is a machine with a dedicated Chrome browser that allows you to surf the web and use all of your favorite web applications like Gmail, Google Docs, Facebook, Twitter, Runkeeper and more.

With their Chromebooks, Google has demonstrated that for most users, you can eliminate all of the overhead required to run native apps from a laptop. It provides benefits such as rapid turn on, better protection against viruses, and data protection since files are stored in the cloud and can be accessed from any machine.

In fact, I anticipate that Google will soon come out with a mobile phone that uses Chrome as the OS. It only requires that device APIs are opened up to the browser, which are close to being standardized by the W3C as Mozilla points out in the above video.

Didn’t Zuckerberg Say HTML5 Isn’t Ready?
While some feel that Mozilla is just repeating the mistakes of others, I don’t buy it. At least not for the reasons outlined in this article by Terrence O’Brien of Engadget. I believe that Terrence’s biggest mistake is that he calls out HTML5 apps as an inefficient solution. The problem with this logic is that apps are not written in HTML5 – it’s just a mark-up language.

Apps are written in code, and in the case of web applications, the code is most often in Javascript. Just as with poorly written native apps, poorly written Javascript apps will be slow and inefficient. Well written Javascript apps can and do perform every bit as good as native apps.

To see how two different coding styles can achieve different results, we can use Facebook as an example. Mark Zuckerberg stated that using web technologies was a huge mistake and that it was the reason the Facebook mobile experience was poor before switching to native app development. Why then, was Sencha able to create a Facebook app using the browser that does not suffer from performance issues (open fb.html5isready.com in a mobile browser to see for yourself). The reason – coding practices. In other words, it’s not the technology that’s a problem, it’s the implementation.

Balance in The Force
The idea is sound, but in order to succeed Mozilla needs the support of manufacturers and carriers, which are lending their support. Why? They want an alternative to control the dominance of Apple and Google that is not controlled by any one entity. With Mozilla, the power is in the standards set by the community, which might be a little scary for Mozilla since users will be able to switch operating systems easily, but it’s not different than what they’ve dealt with on the desktop with their Firefox browser.

For further reading, this article by David Meyer at GigaOM provides more insight as to why the manufacturers and carriers are lending their support to the Firefox OS.

Back to the Future
Mozilla’s strategy is not as much a preview of the future but a return to the past. The desktop has already passed through this cycle of native applications to web applications, and the web has won. Nearly all of the applications I use these days (e.g., email, calendar, contact management, expenses, CRM, project management) are web-based, and the few applications that are native (e.g. Office, Photoshop and QuickBooks) have already moved to a web-based model. For this reason alone, I find it extremely surprising that people continue to sing the praises of native apps when they’ve lost the desktop war. I see the native app banner being carried by Apple, Google, Microsoft and RIM who continue to restrict web app capabilities on their hardware in an effort to lock developers and consumers into their platform.

A Matter of Time
Personally, I’m excited and believe that Mozilla’s efforts will prove that web-based applications can match the performance of their native counterparts. And once developers experience freedom from the chains of platform development, we will see another renaissance in mobile app development. One in which we can build once and serve everyone, without having to worry about platform dependency.

I didn’t watch the event first hand but spent time reading the reactions from the event. From that I read, the reaction that summed it up the best was – “meh”. In other words, BlackBerry did a good job updating the hardware, changing the software interface, and effectively catching up to others in the industry. On the other hand, it didn’t do anything to impress me either.

BlackBerry faces a lot of tough challenges on its road back to relevance. Here are just a few that stand out:

1. Market Momentum
   This isn’t a technical term, but BlackBerry needs to find a way to use yesterday’s event to turn the market in its favor. The press and general market are down on BlackBerry, and yesterday’s event didn’t change it much. I’m not sure how BlackBerry solves this challenge, but it has to find some way to get people other than their loyal fans back on board.
2. Cool factor
   Again, an intangible, but having a BlackBerry these days is a point of ridicule rather than pride. If I had a Blackberry five years ago, I was viewed as progressive and cool. Having a BlackBerry today labels me as old school and out of touch. BlackBerry needs to invest a lot in marketing to change this perception, and while I like Alicia Keys, hiring her as your creative director is not the answer.
3. Retake the Enterprise
   One point that did come across yesterday is that BlackBerry still knows Enterprise. There are some nifty features that corporate IT types should love. Unfortunately, the shift to BYOD (Bring Your Own Device) is irreversible. Five years ago, BlackBerry could have moved the market by selling to corporate IT departments. Today they need to target the users in order to rebuild their enterprise standing. Now that people have experienced the freedom of BYOD, I doubt they’ll want to go back.
4. Rebuild loyalty
   As a former loyal user, I’ve lost faith in BlackBerry. Sure, yesterday’s event felt great, but I’m not convinced that it wasn’t just a one time shot in the arm. I stayed with BlackBerry longer than I should have. I held out hope that they would upgrade their hardware and software to match what iOS and Android were bringing to the table. They let me down. Based on their track record over the last three years, do I really want to rely on them again? Not so much.
5. Attract new users
   Finally, if BlackBerry wants to survive, they need to bring new users into the fold. Unfortunately, BB10 doesn’t bring enough new to the table to separate it from what’s already out there. If anything, the changes in BB10 could alienate new users. It changes many standard smartphone interactions. They’ve eliminated the home button and introduced new gestures to control the device. These improvements don’t appear intuitive. This article from mainstream tech publication Mashable is one example (The First BlackBerry 10 Phone Is Exceptional but Perplexing), and the video they took below is even more telling.

   I like bold approaches, but this may not have been the right time for BlackBerry to take big risks on the user experience.

Unfortunately, yesterday’s announcement, while well done and much needed, will not mark the resurgence of BlackBerry. I’m afraid that I stand by my 2013 prediction that BlackBerry does not survive and ends up an acquisition target before the end of the year. There are a number of larger technology companies, like Dell, HP and Lenovo, who need to grab a share of the smartphone market, and BlackBerry gives them a way in.

So I applaud BlackBerry for taking a stand yesterday, but for this former user, it was too little, too late.

(By the way, for a little trip down memory lane, Engadget put together an abbreviated history of the company. It’s well worth checking out. Click here to see it.)

If this sounds like something you, or someone you know would be interested in, please send a resume to jobs<at>aumnia<dot>com or click the button below. Please be sure to include information about past and previous projects, including links to completed projects that we can take a look at.

For more information, check out our job posting on Stack Overflow.