An exclusive series by the CIO Executive Council
I truly believe that mobile is the future, and am actively preparing my team and the University for this new reality. Our goal is to take as many interactions as possible that our 26,000 students have with the University of Kentucky and enable it on a mobile device. We deliberately created a three-year mobile strategic plan to demonstrate our long-term commitment and dedication to expanding and enhancing our mobile presence. We believe this will enhance student engagement with the university leading to improved student retention and academic success.
Today, students can use a mobile device to access information such as directories, building addresses and locations, maps, campus events, sport scores, course information and other aspects of campus life. Soon we will add access to grades and course registration, among other interactions. A mobile app to access the University learning management platform will soon be accessible via Blackberry Android, iPad and iPhone apps.
Many IT teams take an existing portal and then enable it for mobile. Due to the sheer quantity of interactions, we are planning to do the opposite --design a portal that meets the needs of mobile users and then scale it for use on a PC. We feel that this approach could result in a much better GUI for the mobile user. We also need to identify the right balance of what we do in a mobile Web interface versus a mobile installed application, and how to best integrate transactional data from ERP and other back-end systems. Skill development is another priority; we need to make sure that we have the right knowledge in the right roles to foster success in the mobile arena.
Sounding Boards Discussion Points:
Mobile portal strategies - Installed app vs browsers - Integration of back-end systems - Skills development
Secure back-end data and install apps for UI hogs
Mobile apps are an important part of our disease management program for diabetes patients who are monitoring blood glucose levels and need to get information anywhere at any time. When integrating our back-end systems, especially medical databases, we put a lot of effort into understanding requirements around data protection and security, and then confirming that they are in place for mobile. We look across the entire application architecture to make sure that our bases are covered on access points like Web browsers, PC or mobile devices. Simply being on mobile isn't enough; the apps still has to be a good one where data security and privacy requirements still apply.
Vince, I agree with your idea of approaching mobile portals differently than simply taking the PC version and making it accessible on mobile devices. The user interface just doesn't have the same amount of real estate and you have to be much more selective about what you show and where you position it on the screen. We start by creating one GUI for the Web and then do that work again to get the mobile version right. To determine which apps are client installed apps and which are accessed via a browser, we use a decision matrix. My team considers things like the target user base and what they plan to do with the data. For things like viewing class schedules or checking sports scores, I think you'd be better off with a Website. More UI-intensive tasks like GPS would require an installed app. The downside of installed apps is that you need to have a software update and change management strategy in place.
Let devices and user generations guide app choice
We organized our mobile strategy into two areas: improving business operations and external client interactions. To date, we have focused primarily on creating apps that allow execs to access important company metrics such as profitability and revenue forecasts. For our top-level business metrics, my mobile apps SWAT Team designed a solution that works for BlackBerries, Apple and Android phones through the firewall. The next step is to improve the GUI and identify other business "must haves." For example, a future need our clients requested is the ability to find out if we have experience in a specific area of law or industry, This type of input drives our mobile app planning process.
Your ERP integration question is relevant for me as well since the financial data driving the metrics resides in my ERP system; HR information resides in a separate system. I am considering whether to use external expertise from my ERP vendor to help move this integration piece forward.
About half the time we develop rich mobile installed apps, and the other half we employ browsers. For BlackBerry and Droid devices, we typically use a browser container since their mobile apps are not as strong. For Apple products like the iPad and iPhone, it's a no brainer -- we create the actual application. Another thing we take into account when creating mobile apps is the range of our user demographics. We have three generations of workers at the law firm: Baby Boomers (has to be a turn-key app), Gen X (may need some help) and Gen Y's (self-sufficient). Vince, your target audience of students is predominantly Gen Ys which should influence your app strategy and rollout.
Develop portals simultaneously
Our company has a long history in building technology that runs across multiple platforms. We're fortunate in that we have a mature Web development organization that has been very successful in the transition to mobile development. All of our mobile work, including the work we've done on iPad and Android, is done by our internal teams. The best part is that while there are many creative design elements to consider within mobile, a lot of the code will be built on familiar standards. Most of our work is currently being done in HTML5. For Android, we do a lot of Java.
We've tried a few different ways to create portals for end-users, but the best approach we've found is designing for PC and mobile access at the same time. We start by building our site for the Web, while creating a design for mobile. Our VP of Rich Media Technologies Shiva Vannavada has established a model for creating a "portability framework," which is essentially a content hub. The hub supports multiple frameworks for its output, but doesn't contain any services itself. Vince, I've provided a snapshot of the framework we use to show how it works. This hub can have any number of outputs - with just one of those being mobile. The opportunities within this model scale well for any number of device types.
Interviews done by Carrie Mathews