Skip to Main Content

University of Illinois Springfield

Office of Web Services University of Illinois Springfield

UIS Homepage

The UIS Mobile App Project

If you are thinking about developing an app for your educational institution, we hope this summary will be of use to you. This summary provides you with a basic, top-level framework for planning, developing, and delivering a mobile app for your institution.

Institutions have different demands, priorities, and approaches. Therefore, you will need to keep those aspects in mind as you move forward with planning, developing, testing, and delivering an app for your institution.

Phase I – From Concept to Web App

1) Plan

Assemble Your Team
Thanks to the foresight of a retired Web Services director, the first step we took at the University of Illinois Springfield was to assemble a mobile strategy task force [in fall 2011]. Membership of this task force were comprised of faculty, staff, and administrators. Units represented in this team consisted of Admissions, Campus Relations, Information Technology Services, Library, and Web Services. The goals for a university-wide mobile strategy were planned, discussed, and approved. The team would:

  • Consider all things related to the development of mobile applications, how to best present the university brand via the mobile medium, and how best to serve our students and our communities with practical and engaging content.
  • Develop guidelines, standards, and approval process for submission of UIS-created apps to the App Store, Google Play, and other mobile stores, as well as those for university-use-only.

Define Your Goals
Once you have your team in place, define the goals of your mobile strategy. The focus of the strategy is not on the technology but on what services your mobile strategy should address, provide, and deliver. Simultaneously, we drafted, reviewed, edited, and approved an university mobile policy. The targeted audience was classified into three groups: 1) Students, 2) Faulty/Staff, and 3) External Stakeholders. The items that needed to be addressed immediately were – a) policies, b) standards and procedures, c) development platforms, and d) structured hierarchy of apps. A primary question that was answered at the outset was – What do students want from this app and what do we share with students?

Develop Your Strategy
Native, Cross-Platform, HTML 5, and Hybrid -
We knew early on that each of our targeted mobile device platforms had its own SDK and programming language, yet all of them had a browser component in common. Therefore, we wanted to develop a hybrid app that ran in this common browser component. This write once, run anywhere approach is useful when doing cross-device development. In addition, we did not have the personnel to develop two separate native apps. The HTML5 framework helps in the creation of mobile web applications, which can be made to look and behave more like native apps, unlike a regular webpage. Web apps built using these frameworks usually run in a browser. The two frameworks we reviewed were a) jQuery Mobile, and b) Sencha Touch. The next goal was to package the app in a hybrid shell and we used PhoneGap for that.

Choose: Web App vs. App
Our approach was to first develop a Web App. The Web App would contain basic functionalities that fell into two categories: 1) Information, and 2) Utility. We knew that it would be easy to develop and would allow us to get some feedback from the campus community before we decided to move forward with an App for the university. A 30-minute conference call with Gartner validated our approach, both in terms of our mobile and development strategy. Two critical take-aways from the call was 1) don’t swamp the mobile app with complexity, and 2) provide alerts instead of complete services.

Choose: In-house vs. Outsource
We had the requisite skills to develop the Web App. In addition, we did not want to purchase an off-the-shelf solution with a framework that did not provide an unique identity and additional features.

2) Develop

The development process took us six months, from inception to delivery. This timeframe could have been cut down further if we had a dedicated staff member, or members, working on the app 100% of their work time. We are a team of three members that supports a varied set of Web services: Toolbox, training, social media, shopping cart, special projects, apps, and websites. Our graphic designers developed the icons for the Web App. The Information Technology Services department proved instrumental is coding the campus directory and making it mobile.

3) Test

We had a group of individuals test the Web App on both the iOS and Android platforms. There were minor edits to make and no changes to the architecture or programming aspects.

4) Deploy

UIS Web AppIn spring 2012, we announced the availability of the Web App via two of our official social media channels – Facebook and Twitter. We knew early on that our users would not be pleased when a function within the Web App launched the native browser. This was not be a problem when we move to Phase II of the project.

Most of the feedback we received pertained to Webmail.

“Thank you for the new UIS mobile app. It is very nice. I am wondering, though, how do we access webmail from the mobile app?”

“How do I get to the email with this new app??”

“Hi how do we check our UIS emails on app?”

Our campus did not have a mobile version of MS Outlook or Webmail. We were under the impression that users were tapping into the built-in email clients, which was not the case. Therefore, we spent time on educating our users that their mobile devices provided ways to map email clients. Additional feedback pertained to accessing a varied set student information services.

“I can find an A-Z link. How do I quickly add money to my iCard? So far, I can’t access what I need from this mobile app. When I can remember the other problems, I’ll send another message. Thanks!”

 

Phase II – From Web App to App

The next step was to move from a Web App to an App. In summer 2012, we went back to the drawing board in terms of enhancing the services that could be made available on the App. Given that our enterprise systems run across three campuses, we focused on services that were feasible to provide for our first release, version 1. At the same time, we discussed with our sister campus regarding student information services that would become available in a mobile format by the end of fall 2012.

The UIS Mobile app was made available in the App Store and Google Play in October 2012. The inception to delivery time frame for this phase was five months. Again, this timeframe could have been cut down if staff were dedicated for the project full-time.

Content First

A major decision in Phase II was to put content first. This was based on two conclusions:

  1. Mobile devices have less screen space and priority should be given to relevant content, which is more important to users, and
  2. Luke Wroblewski’s presentation on “Mobile Web Design” [An Event Apart] convinced us to take a content first approach.

Screenshot of UIS Mobile app

For the UIS Mobile app, we display content first, which is a feed that consists of calendar items, news stories, food services menu, and weather.

Where Do We Go From Here?

As student information services from our enterprise systems become available, we will be able to add those features into our app.

Conclusion

  • Mobile is the current and future medium. Invest in it, if you have not done so already.
  • Focus on features that are most popular in your institution.
  • While targeting multiple device platforms, the HTML/Native hybrid approach can cut down development times without sacrificing functionality.

Written by the Web Services Team
November 2, 2012

Back to top