This is the story of how a small college with a department of 4 and a zero-based budget, developed a mobile solution that is affordable and provides vital information to future and current students, faculty, and staff.
10. Something needed to be done and a new
search began for a solution
An app for one device or
an app for all of them??
Better yet, a mobile site :)
http://www.hammer.net/template.asp?nav_id=438
Responsive Web Design - RWD?
11. Inventory of existing resources
What we had:
CMS with RSS Feeds
Athletics Website with
XML feeds
Calendar with iCal
feeds
Analytics information
Downloadable PDF
Campus Map
What we wanted:
Affordable solution
Robust and efficient
system
Technical support
To work perfectly with
what we had
Better map for mobile
devices
13. Open-source mobile framework Kurogo to
the rescue
Data integration
Cross-platform user
experience
Customization
=
Image source: http://kurogo.org/home/
14. Well documented set-up and installation
* Based on Version 1.5 installation: http://kurogo.org/guide/setup.html
17. A mobile framework that allows you integrate
your data sources with customized modules
Emergency Module:
Content from
XML feed.
18. And a very powerful Map module.
Google Earth map Map rendered on mobile
KML File
19. If RWD is not an immediate option, a mobile
framework can be a temporary solution.
But wait…
Isn’t it better just to have a RWD site?
Are there any advantages/disadvantages for
RWD and separate mobile sites?
20. Responsive Web Design - RWD
Advantages
One design fits all
Optimized Web
experience
Website updates done
in one place
No need to URL redirect
21. Responsive Web Design - RWD
Disadvantages
Images/content are
hidden in smaller
devices. Images still
load causing bandwidth
issues.
Scrolling involved
Takes 30% extra time to
implement
22. Separate Mobile Site
Advantages
Specific content geared
to mobile situations
Download time is faster
Takes advantage of
mobile devices
features: Geo-location,
click-to-call, touch
events
Faster to implement
23. Separate Mobile Site
Disadvantages
Only certain content
from full site is
available on mobile site
Two separate places to
update code and
content
URL redirect does not
always work right from
mobile to desktop and
vice versa
24. Advantage of mobile frameworks: they come
with out-of-the-box modules ready to use.
Image source: https://www.modolabs.com/platform
28. According to Brad Frost’s article, “Separate
Mobile Website Vs. Responsive Website”…
Responsive sites avoid
“disparate experiences”
that “deprive certain users
of valuable information
and features”; while mobile
dedicated websites include
“only a fraction of the full
website’s features.”
Frost, B. (2012). Smashing Magazine. Separate mobile website vs. responsive website. Retrieved from
http://mobile.smashingmagazine.com/2012/08/22/separate-mobile-responsive-website-presidential-smackdown/
Image source: http://www.rspmarketing.com/trending-topics/responsive-design-vs-mobile-optimized
29. Ethan Marcotte, on the other hand, states the
following:
“Responsive Web Design isn’t intended to serve as a
replacement for mobile sites.”
It should be viewed as part design philosophy and part-end
development strategy.
“Research how your audiences access your site: not only the
devices and browsers they use, but how, where, and why they
use them.”
Marcotte, E. (2011). Responsive web design. Page 108. New York: A Book Apart.
30. Wrap up…
Nothing is impossible
Know your audience
and provide them with
what will serve them
best.
Make an inventory of
your web assets.
Follow your analytics
like your sixth sense.
Do your homework when
researching open-source.
Yes, you want support
with that.
For URL redirects, always
provide a choice for both
full and mobile site.
Provide a link on your full
site to your mobile site.
Always provide cross-
links from both platforms.
31. Useful resources for open-source mobile
frameworks for Higher Education…
Name Link By Documentation Support
Molly http://mollyproject
.org/
University
of Oxford
http://molly.readthedocs
.org/en/latest/index.html
http://mollyproject.org/c
ommunity.html
UCLA
Mobile Web
Framework
http://mwf.ucla.ed
u/
UCLA https://github.com/ucla/
mwf/wiki
http://mwf.ucla.edu/?go/
develop
MIT Mobile
Web
https://github.com
/MIT-Mobile/MIT-
Mobile-Web
MIT ------- A better README is
forthcoming…
Mobile Web
OSP
https://github.com
/dmolsen/MIT-
Mobile-Web
A fork from
MIT Mobile
Web
http://mobilewebosp.pb
works.com/w/page/2792
3975/FrontPage
---------
Kurogo http://kurogo.org/h
ome/
Modo Labs http://kurogo.org/docs/ https://groups.google.c
om/forum/#!forum/kurog
o-dev
32. Useful resources for RWD frameworks…
Name Link Documentation Support
Gumby http://gumbyframewo
rk.com/
http://gumbyframew
ork.com/docs
https://plus.google.c
om/communities/108
760896951473344451
Bootstrap http://twitter.github.io
/bootstrap/
http://twitter.github.i
o/bootstrap/getting-
started.html
https://github.com/tw
itter/bootstrap/issue
s?state=open
Susy http://susy.oddbird.n
et/
http://susy.oddbird.n
et/guides/getting-
started/
http://stackoverflow.
com/questions/tagge
d/susy-compass
Foundation http://foundation.zur
b.com/
http://foundation.zur
b.com/docs/
https://groups.googl
e.com/forum/#!forum
/foundation-
framework-
33. More good stuff…
More Responsive Web Design - RWD frameworks:
http://stunningfeed.com/25-best-css-frameworks-for-
responsive-webdesign/
Adaptive Images (yes, you will need that too):
http://adaptive-images.com/
Sebarmeli – JS Redirection Mobile Site:
https://github.com/sebarmeli/JS-Redirection-Mobile-Site
Tutorials to get you started in Google Analytics:
http://blog.kissmetrics.com/50-resources-for-getting-the-
most-out-of-google-analytics/
Good book to read about GA: Web Analytics 2.0 by Avinash
Kaushik
34. Two great classes by Higher Ed Experts
Responsive Web Design for Higher Ed (RWD)
http://higheredexperts.com/studyrwd/
Web Analytics for Higher Ed (WAHE)
http://higheredexperts.com/studywahe/
35. Thank you all. Last year this conference helped us
tremendously. This presentation is our way for us
to give back to you.
Enjoy the rest of the conference.
PowerPoint presentation available at: sylvianavarronicosia.com/portfolio/eduweb-2013
36. Q & A
*Slide presentation available at: sylvianavarronicosia.com
Editor's Notes
Black slide at intro (and closing) of template is here so you can set up your presentation prior to your event, and have it ready and running on screen, without anyone seeing it. Our AV technicians will love you for this.
Generic Intro Slide
This is about how we were able to implement a way to display essential information from our website on mobile devices in an efficient and affordable way.If you are from a big wealthy university, good for you! But if you are a small to medium institution with an understaffed office and a tight budget, we hope our story will benefit you in some way.Farmingdale State College had to overcome a series of challenges, including virtually zero budget, minimal staff and limited IT support, to offer our students, faculty, and staff a way to easily access important information about the college from their mobile devices.
Shortly after going live last year with a brand new CMS, we became aware of the growing use of mobile devices to access our site and were introduced to new terms like Responsive Web Design, adaptive images, and mobile apps. It was obvious that we had to address these issues right away.We knew there was no way we could redesign the newly launched Website with the current resources and budget constraints. So, we had to embark on a new adventure that could help us solve this mobile accessibility issue with the resources and staff we currently had.After much research, we went with open-source framework Kurogo. We were able to extract information already on our CMS, use existing RSS feeds from our news and open-source calendar, and use the powerful Google Maps system, in addition to other features. This gave us the ability to provide important information on a solid and robust mobile platform that is accessible to all devices. All just with a minimal investment of a new server compared if we had to hire a professional company.
The Beginning… It all started in 2010, as enrollment kept increasing and the demands from our students, faculty and staff grew, our Website was in desperate need of a new design. At the time, the site was built on frames, tables for layout, and a Flash banner on the homepage. We faced many of the same issues as other institutions, primarily a lack of over sight. Several departments had their own sites, with their own design and not always conforming to the college’s brand, logo, and colors. There were numerous pages with outdated content and the site’s main navigation tool, Quick Links, had every single department listed there. The dropdown contained at least 250 links. As we all know, EVERYONE wants to be on the homepage. Additionally, there was no consistency among browsers and there were issues when viewing the site with Google Chrome. A large number of campus users were still using IE7, and we all know how everything different looks on each version. Ultimately, the largest handicap was that, every single update to the site was directed to our office, thus taking precious time from our staff to do other more important projects.
As a result, we needed a solution that offered us a centralized interface that provided a uniform look, a way to allow content to be updated by departments but still maintain oversight of the Website. We needed a workflow system for content approval, while empowering our users to do their own changes. But how do we do that? We quickly came to the conclusion that what we needed was to move the site into a Content Management System specific for institutions of higher education to handle the layout, the content, and the workflow. The second part was building a whole new site from scratch: from design, layout, navigation and content. While it all looked like a simple part of the process, soon it became a huge deal for everyone involved.
The road ahead wasn’t easy and soon we encountered many unforeseen forces and obstacles that took us a while to overcome: budget approval, IT and hosting issues, faculty and staff reluctant to come on board with the project, and getting a consistent look on all browsers. We had to re-organize all existing content along with the navigation, a process that involved some passionate arguments among our department.
Finally, February 2nd 2012 arrived and ready or not we were going live with our brand new site. As with everything new on campus, there were minor technical issues and big opposition from some faculty, but eventually everything fell into place and peace returned to Farmingdale. Or so we thought.
It was at around this time of the year that a colleague and I came to this fine conference in July 2012. We learned so much by listening to what other institutions were doing in admissions, web design, social media… and other new cool terms such as mobile, apps, and Responsive Web Design. The growth of the mobile audience in higher education was highly emphasized. We felt so empowered by looking at how other institutions like Notre Dame and Harvard handled their mobile projects that it became obvious to us that the next step was to go mobile as well. But as the conference ended and we resumed our positions at home, reality finally hit. We are not Harvard. We are not Notre Dame. We are a small, public institution. We don’t have the staff or resources that big universities enjoy. Due to our recent Website release, we had a zero budget, only four staff members on board, a great Content Management System but with a fixed grid layout, and a growing population accessing our site from mobile devices. We totally felt like the underdog.
We needed to do something fast and a new search began for the solution. We knew that going responsive would take us a great deal of time, (building responsive takes about extra 30 percent of the regular time without counting the time it takes converting the HTML pages into CMS templates or content migration). And again the reality of facing new unforeseen forces kept us very focused on our search.Our analytics showed an increase of iPhone, iPad and Droid users trying to access admissions, course, and events’ information among others. We felt if we built an app for a specific platform, we would exclude other mobile devices from important content from the Website. If we built one for Apple, we had to build one for Android and Blackberry as well. We looked at some companies and again, time and budget were big constraints. So we decided to address all mobile devices at once by building a mobile site. We wanted all mobile devices with a browser to be able to access our content regardless of screen resolution.
We did an inventory of our existing resources: a CMS that provided RSS feeds; an open-source calendar that also allowed us to get feeds from events and our Athletics feeds. Our analytics provided the insight into the content our users were trying to access from mobile devices: including admissions, calendar, and course information, among others. We started looking at jQuery mobile and a variety of built-in mobile frameworks, but we felt we needed one with a great level of support. We needed something robust, and cheap. If at that moment we couldn’t have one design for all, we needed to find something where we could reuse the elements we already had. Although our CMS does offer a mobile solution, again, budget was an issue. So our best option was to go open-source.We also needed a better campus map. Although we are a small campus, you would be surprised at how many people cannot find their way to a building, or visitors that end up at the wrong place. The campus map at the time was just a downloadable PDF, not adequate for mobile devices.We needed something that could integrate all these elements in an inexpensive and efficient way, plus we wanted support and a better campus map for mobile. Sounds impossible right? Yes, we thought that too.
After much research, we found a great open-source framework geared to higher education, that to our surprise, had the ability to handle if not all, most of our issues. We were ecstatic. There was hope. "There's no need to fear, Underdog is here!"
Kurogo is an open source platform that allows you to bring together all your data sources and deliver them intuitively into mobile site or native app providing “exceptional cross-platform user experience” (Modo Labs, 2013). It also allows you to customize and create your own modules, depending on your institution’s needs. Kurogo by Modo Labs, as many of you may already know, are the same people who developed MIT Mobile Web framework. Eventually they split and Modo Labs was created. If you look at both frameworks, they are similar in their features and capabilities. The difference for us was the amount of support that one offers over the other one, even at an open-source level, especially the documentation. No need to re-invent the wheel.
Setup and installation is very well documented. Extract the files to your siteSet the root of your web server to the www folder from the Kurogo structure Make a copy of the Universitas folder Rename the Universitas folder with your site’s nameAdd this name to the Kurogo.ini configuration file And you are ready to start customizing your mobile site.
No need for complicated coding for theme customization. As you start customizing your mobile site with colors and font styles, you do it through .ini configuration files, which are text files where you modify sections and properties for your site. The basic steps for theme customization:In your site’s Theme folder, make a copy of the “default” folderRename the “default” folder Open the configuration file “config.ini” to customize colors and font style.In your renamed Theme folder, go to the modules/home/images folder to start customizing the logoand icons with your ownYou don’t have to worry about how your content is going to look on different devices. The framework comes with an internal device detection that will provide the proper layout according the user’s device. Our Creative Director did all the branding and customization without him having to know or learn any complicated programming code.
The out-of-the-box modules give you a great starting point because you can begin re-using your content immediately. By using RSS/XML we fetch content from our Admissions, Athletics, calendar of events, and news sites into the mobile site’s modules. For example our News module displays the latest news for the college, alumni and SUNY news through XML data feeds. You have the option to set the module to extract the content and display it in a mobile friendly format or get the content at the specified URL. The Calendar module allows you to extract and display events from an iCalendar (ICS) feed. In our case, we used our “Bedework Feed URL and Widget Builder” where we generate an URL to an .ics file and we fed this URL to the feeds.ini configuration file. Events are then displayed in a mobile-friendly format.
Customized modules such as Admissions, Courses, Dining Services, and Library, extract content from our full site using HTML ID tags. Another great and useful module is the Emergency module. In addition to being able to display emergency contact information, we also took advantage of our CMS feeds. With regard to emergencies, our full site’s homepage displays an emergency notice. We built this page as a XML feed and reuse it in the configuration file on the mobile site. This same notice will appear on the mobile site’s homepage. No need to enter copy twice in two separate places.
For us, the most powerful module within the framework is the Map module. It allows you to browse and search for places and view them on a map. We created the feeds in Google Earth; each feed is a pin and then we exported the map as a KML file. The Map module reads from this file and each feed or pin is displayed as a category on mobile devices. The most amazing feature for this module is that it takes advantage of mobile devices’ geo-location to add to its functionality. When you search on the map for a building, it will give you directions from Google Maps on how to get there based on where you are. Further, when you view an event in the calendar module, you can find the event location on the Module map thanks to the Meta tags included in the KML file. These are just some examples of how powerful open-source can be.
Today having a mobile presence is a must. If responsive design is not an immediate option, like in our case, a mobile framework can be a great temporary solution, because you save time on the initial coding, configuration and customization. However, there are numerous debates out there about whether or not is good to have an additional mobile site in addition to the full site; as opposed to just developing a responsive web site. Using our case, we will analyze both approaches.
As we have heard, the advantages of Responsive Web Design are that one design fits all; no domain redirects; and you conveniently maintain your code and content in one single place.
However, because a RWD site is a scale-down version of your full site, some tend to hide images or content as the resolution goes down; this content and images still downloads to mobile devices creating bandwidth issues for mobile users (Blog design, 2013). On the other hand, if you decide not to hide your content, users will have some scrolling to do if too much content on the page. RWD also takes an estimated 30% more time to design and implement.
A mobile site on the other hand, is created with specific content geared to mobile situations, therefore download time is faster; a mobile site also takes advantages of mobile devices features such as geo-location, initiating calls from links, and touch events that lead to instant sharing.
Disadvantages are that not all content from the full site is available on a mobile site; you have two separate places for content and code to maintain; and URL redirects from full site to mobile and vice versa not always work great.
One of the advantages of a mobile framework is that it comes with useful out-of-the-box modules. When you install a pre-built mobile framework like Kurogo, it comes with several modules ready for you to customize. It also gives you the tools to create new modules according to your institution’s needs. Calendar, News, Map and Athletics are some of the modules that already come with Kurogo. Admissions, Libray, and Dining Services are some of the modules we created.
Our two cents… We used mobile disadvantages to our advantage.Another great advantage with this framework is that it allows you to reuse content from a full site. One of the big reasons some oppose having a mobile site separate from a regular site is because you have to update content at two different locations. True, this could be annoying and time consuming having to update content in two separate places and nobody is denying that.However, with this framework we are able to extract information from another site using HTML id tags or through RSS feeds. For example, our Admissions module gets all the information from our Admission’s full web site. Anytime the CMS content contributor for the Admissions office makes a change on the Transfer Applicants page, that change automatically is reflected on the mobile site without having to touch the mobile site at all. You may set the mobile framework once, but how often do you change colors and layout versus content? Content is what is continuously changing. Content gets updated in one place with this approach.
According to others, another disadvantage with separate mobile sites from the regular site is the URL management. When someone goes to www.institution.edu some institutions resolve this issue with scripts that detect the device being used and then the user is automatically redirected to m.institution.edu when using a mobile device. As a mobile user, I find it very annoying when I go to a site from my phone and automatically I am redirected to the mobile site when in fact I want to go the full site. As a developer, how then can I be so sure that anybody accessing www.institution.edu from a mobile device actually wants to go to m.institution.edu? I have seen other institutions tackling this issue by having an option on the mobile site’s landing page to either stay on the mobile site or go to the full site.
In our case we do have two separate URLs and we don’t have a device detection script to redirect. m.farmingdale.edu will take users to the mobile site and www.farmingdale.edu will take them to the full site. As long as we provide cross-links on both sites, the option is there, and we let the user decide, not us, where to go. Based on our analytics and heat maps, we included only essential content on our mobile site and for anybody desiring more information there is always a link that directs to the full site.
Giving users the feeling of deciding where they want to go by providing them all the options available is what makes any design successful regardless of mobile, full or responsive. Over the years I have learned to never assume what users want because you will NEVER win. According to Brad Frost article, “Separate Mobile Website Vs. Responsive Website”, responsive sites avoids “disparate experiences” that “deprive certain users of valuable information and features”; while mobile dedicated websites are “only a fraction of the full website’s features are included.” It is true that our mobile site only displays essential information from our full site, but as a temporary solution while we go responsive; we find that it doesn’t compete with our full site but enhances the user experience (UX). Mobile and desktop experiences are totally different and each platform provides features that the other one cannot, like touch vs. click.
While some may argue that the only way is going fully responsive, others affirm that a mobile site or an app can be best way to go. After all it depends on your audience and every institution is different with unique needs. As Ethan Marcotte, the father of RWD stated in its book Responsive Web Design, “Responsive Web Design isn’t intended to serve as a replacement for mobile sites.” It should be viewed as part design philosophy and part front-end development strategy. “Research how your audience accesses your site: not only the devices and browsers they use, but how, where, and why they use them.” (Marcotte, 2011, p. 108). If your institution’s development strategy requires a RWD site only go for it. But if your audience requires a RWD, a separate mobile site, plus native apps, by all means you must go for it as well.Once we move our site to a responsive design, we still will keep our mobile site. We feel the features it provides our mobile users, like the interactive Map and the Emergency modules, address mobile-specific situations and enhances our users’ experience. With a virtually zero budget and limited staff we were able to provide a robust mobile site from open-source software. In our case the only investment was a new server where the mobile site resides.
Wrapping up… Nothing is impossible, no need to reinvent; there are plenty of open-source solutions out there.There is no right or wrong when deciding on a responsive, mobile app, a mobile site, some, or all. Know your audience and provide them with what will serve them best.Make an inventory of your web assets to see what can be reused.Follow your analytics like your sixth sense.If deciding on a dedicated mobile site, do your homework when researching for open-source mobile frameworks. Yes, you want support with that!If using URL management for redirects, always provide a choice for going to the full and mobile site. Also provide a link on your full site’s home page to your mobile site.Always provide cross-links from both platforms.
Some links that may help you with your mobile solution quest:Open Source Mobile Frameworks geared to Higher Ed:
RWD resources to get you started…
More good stuff…
Thank you all, I hope this lecture can guide you in some way. Last year it help us tremendously what we learned at this conference and this is a way for us to “give back”. Enjoy the rest of the conference.