Abstract
Mobile devices and associated applications (apps) are an indispensable part of daily life and provide access to important information anytime and anywhere. However, the availability of university-wide services in the mobile sector is still poor. If they exist they usually result from individual activities of students and teachers. Mobile applications can have an essential impact on the improvement of students’ self-organization as well as on the design and enhancement of specific learning scenarios, though. This article introduces a mobile campus app framework, which integrates central campus services and decentralized learning applications. An analysis of strengths and weaknesses of different approaches is presented to summarize and evaluate them in terms of requirements, development, maintenance and operation. The article discusses the underlying service-oriented architecture that allows transferring the campus app to other universities or institutions at reasonable cost. It concludes with a presentation of the results as well as ongoing discussions and future work.
1 Introduction
The Internet promised to make information accessible anywhere and anytime. The use of mobile devices completes this vision by spatially and temporally independent mobile Internet access. This is an increasingly important factor for consumers (Stotz/Hoppe/Breitner 2004). This trend also affects the way consumers use mobile technology, which can be verified by several statistics. In Germany the use of mobile Internet has almost doubled in 2013. Furthermore the duration of use increased by about 30 percent to 133 minutes on average per day (Eimeren/Frees 2013). The mobile Internet is primarily used for the location-independent search of information and for the communication via e-mail (ibid.). These are followed by video and audio file retrieval as well as discussion forum usage (ibid.). All these activities are relevant to the university environment too, but are they offered or even demanded?
While in the fields of social media and online shopping the mobile usage is highly pushed and supported, the efforts at universities on this point only start slowly. Basically, the mobility of university services is expected and requested by the students. Therefore the issue needs to be emphasized and addressed by the universities. “Students are mobile and have expectations about the availability of university services while they are on the go” (Wilson/McCarthy 2010). In the context of a university, small applications are often used. In the field of learning support, gamification (Zender et al. 2013a), the support of creative learning processes (Cochrane/Antonczak 2013) or participant activation in huge university courses (Wegener/Prinz/Leimeister 2011) are brought into focus.
The development of mobile applications (apps) for the whole university context is heavily promoted by the commercial sector. For example, the products campus-to-go®1[1] and CampusNet®2[2] offer wide functionalities around the area of study organization. In addition, some universities are working on their own apps, for example the TU Bergakademie Freiberg with MyTU3[3], the University of Duisburg-Essen with MyUDE4[4] and the University of Mannheim with the UMApp5[5]. A comparative analysis of existing apps in the German university sector can be found in (Zoerner/Gößler/Lucke 2013).
These apps mostly deal with the study organization. The didactic innovation that originally had been promised by the use of mobile applications and that is implemented in the individual projects mentioned above is less within the focus of these apps. The use of mobile applications for group scenarios in a personal learning environment is also considered in an outlook of the MyTU App (Gommlich/Heyne 2013). In addition, the field of campus apps is not appropriately discussed in scientific literature. Usually, only individual projects (Wegener/Prinz/Leimeister 2011, Cochrane/Antonczak 2013, Zender et al. 2013a, Bührig/Guhr/Breitner 2011, Bernoth et al. 2012) and occasionally campus apps (Bischoff 2011, Gommlich/Heyne 2013) are described with the focus on functional details. Far-reaching technical aspects are considered only sporadically, e. g. in the project InnoCampus6[6] and a few other publications (Bischoff 2011, Gommlich/Heyne 2013, Bührig/Guhr/Breitner 2011).
However, the usefulness of location- and time-independent learning is also considered critically (Kerres 2000) and should therefore be designed and located in a pedagogically useful way. This raises the question of the functionality of a campus-wide mobile app. Existing projects and literature suggest to combine study organization and small-scale applications. In this context the authors see the provision of a mobile campus app for the university as an important component. This article presents an approach to tackle this challenge. We provide a framework to guarantee the embedding of all mobile learning applications that are currently in high demand and will constantly grow into a consistent solution (Kiy/Hofhues 2014).
This article is organized as follows. In order to achieve a systematization of the existing solutions, the following paragraph provides an overview of campus apps and an approach to categorize them. The technical integration of different applications is not trivial, especially when the application development is organizationally and geographically scattered. The subsequent paragraph will therefore focus on how the various apps can be effectively integrated and which further technical challenges must be considered when developing a mobile app for a university. Here, the heterogeneity and the rapidly progressing technology development are especially challenging (Bührig/Guhr/Breitner 2011). The article continues with the presentation of the designed system architecture, the state of development and an evaluation of current results. It concludes with a critical discussion and an outlook to upcoming work.
2 Concept of a mobile campus app framework
In the following section, the development of the mobile campus app framework is discussed. Based on a media consumption survey, essential technical requirements are presented. Afterwards, the main functions of the app are derived from a comparison of existing campus apps. Based on a short evaluation, section three compares common ways of development and the corresponding design strategies to deduce results for a mobile campus app. The section concludes with a presentation of the architecture of the developed framework and an overview of recent developments.
2.1 Requirements and major objectives for a mobile campus app
A mobile campus app is supposed to be the central entry point to all mobile services of the university. The access via one interface to both central and distributed individual applications (which may be platform specific and highly individual) is essential for such an app. Distributed individual applications are, for example, assistive services to organize campus routines (Knoth/Kiy 2014), educational games (Zender et al. 2013a, Zender et al. 2013b), hybrid applications for team-specific instructive courses/lessons as a resource supplement7[7] or as an extension of central university services like MoodleMobile8[8] and cloud storage9[9]. In the following, a selection of central services and information of a university are referred to as essential features (core functions) of a mobile campus app. All other mobile applications, mobile websites as well as other services which can be accessed using a mobile device are classified as optional features (mostly third-party applications).
A media consumption survey carried out at the University of Potsdam with 1247 students (Brückner et al. 2013) showed that:
89.7 percent of the respondents use their notebook
72.7 percent of the respondents use their smartphone
16.7 percent of the respondents use their tablet
to access services for studying. Already 27.3 percent of the students use mobile applications for learning, while a much higher degree is using mobile applications for private purposes. Therefore, it seems a reasonable objective to create, establish and maintain mobile services in order to appropriate support studying at the universities. Furthermore, in order to retain an overview on the scattered learning applications and services of the university and thus to simplify the access to them, the integration of the university apps within one consistent single app-wide navigation structure may help. Thanks to the media consumption survey, some central services could already be identified. For example, 64.6 percent use course-specific E-learning material and 76.3 percent take advantage of online library services. With respect to the survey, the services must be offered for the most common platforms, i. e. Android, iOS, Windows Phone as well as popular tablet and desktop operating systems. Also, other operating systems and platforms that may come up in the future have to be kept in mind.
Several campus-related information, that is consumed via a mobile campus app, consist of non-critical data like the cafeteria menu, the library search or the program of the athletics department and can thus be transferred unencrypted. Other services are subject of strict privacy regulations, e. g. the query and display of personal data from the campus management system such as grades, individual schedules and personal documents. That's why querying secured and unsecured data must be considered in the overall architecture of a mobile campus app framework.
In addition, the application must be able to access the hardware and thus the sensors of the mobile devices. GPS and compass are necessary for the navigation on campus and in buildings as well as to provide context-specific information on public transportation. Moreover, functionality like NFC (near field communication) and the camera to comfortably recognize QR codes in the library or at door signs must be accessible. Additionally, it must be possible to start and run external applications from within the mobile campus app to access third-party applications, e. g. Moodle or ownCloud. Third-party applications offer features that are difficult to replicate and maintain with reasonable efforts. There are some additional requirements, sorted in descending order according to relevance. A mobile campus app shall:
provide a clear added value and advanced features for the user
be performant and offer a good user experience
be extensible in order to integrate more features and third-party applications
be device and platform independent
be cost efficient and maintainable with little efforts, i. e. shall use only a minimum set of programming languages and technologies
minimize the current costs of implementing, testing and distributing
allow the release of the code as open source and therefore ensure a certain level of sustainability
enable data exchange with existing apps (to pass pieces of data to other applications)
separate the design and the logic of the app
be available as a mobile website
On the one hand, such a mobile campus app contributes to an inward identification with the university. On the other hand, it acts as a figurehead of the university and must therefore be distributed in the official app stores. Taking the existing policies of the app stores into account, the app must offer essential core functions and isn't allowed to only be a container for individual applications.
2.2 Core functionalities of a mobile campus application
The full support of all possible and conceivable functions involves the risk of not reaching a sufficient quality of the resulting application and not sufficiently focus on the users’ needs. To tackle this problem a selection of essential features must be made. The selection process must take various criteria into account. The relevance for teaching and learning as well as the support of the motivation of the user must be weighed in the decision. Furthermore, the user group of students is very heterogeneous. Various personal characteristics, changes along the study phases and specific needs in different areas of study result in diverse requirements. Additionally, diversity issues such as different cultural backgrounds and various disabilities have to be taken into account. The selection of appropriate functions for a mobile campus app is supported by an analysis of relevant and already established campus apps at other universities (Zoerner/Gößler/Lucke 2014). From this comprehensive analysis some representatives are compared (see table 1).
Comparison of core features of selected campus apps.
| Tub2Go | HS Niederrhein | UP.App | TUM-App | Campus-To-Go | |
|---|---|---|---|---|---|
| campus events | X | – | – | X | X |
| location maps | X | X | X | X | X |
| cafeteria menu | X | X | X | X | X |
| campus news | X | X | X | X | X |
| lectures schedule | X | X | X | X | X |
| opening times | – | – | X | X | – |
| emergency numbers | X | – | – | – | – |
| public transportation | – | X | – | X | X |
| library search | X | X | X | – | – |
| contact search | X | X | – | – | – |
| grades | – | X | X | – | X |
| campus-wide services | X | X | – | – | – |
| athletics program | – | X | – | – | – |
Features that are available in all 58 investigated campus apps were gathered to assemble a list of core features of a mobile campus app. The most prominent among them are:
an overview of events and the possibility to export event details to the local device calendar
maps of the campus including additional information such as smart card terminals, parking lots and so on
the cafeteria menu
the news channel of the university
the lecture schedule (overview of all university courses as well as individual ones)
The group of optional core features is formed by features present in at least some mobile campus apps. Among them are:
the public transportation (timetables and current departures)
search interfaces for the library, for the staff directory and other available information directories of the university
emergency numbers and opening times for central departments
the possibility to query or to get notifications of exam results
For the final consolidation of the core features, 13 technology-savvy E-learning experts from different disciplines were invited to arrange the optional core features and features which appeared in only one of the examined campus apps according to their subjective importance. As a result, all optional core features and the following features were added to the core functionality of the mobile campus app. The features added to the core functionality are:
a list of the currently enrolled courses, the associated material and notifications
access to campus-wide services such as printing, password reset or integration of instant messaging services
The core features were grouped thematically and inserted into an overarching navigation logic (see Fig. 1).
The navigation concept arranges the necessary core features of the mobile campus app in a compact menu structure. Features requiring a login are marked.
The evaluation of the required features of a mobile campus app provides only a snapshot of current user requirements. The technological, cultural and pedagogical requirements may change over time. For this reason, technical concepts are required to ensure maintainability and adaptability of an app in order to support an iterative and continuous adaption process according to the needs of the students and their environment. To promote an app's maintainability, the source code should be published in an open repository like GitHub10[10]. Furthermore, maintainability is strongly supported by an appropriate software architecture, a low diversity of technologies used and a well-structured documentation to simplify the first steps of development. This will be discussed in the architecture chapter in more detail.
3 Implementation of the mobile app "Mobile.UP"
3.1 Native, hybrid or web-based development strategies
Currently, there are three fundamental ways of developing a mobile application. The first one is the implementation as a native application using a platform-specific programming language. The second way is based on pure web applications and has little in common with developing native applications. The third variant either makes use of a generic framework to compile HTML, CSS and Javascript to native code or creates a hybrid application where the sources are packed into a container and interpreted on execution. There are a number of frameworks for the development of hybrid applications. Among the best known and widely used ones are Cordova11[11], PhoneGap12[12], Steroids13[13], Titanium14[14], Rhodes15[15], Mono16[16] and Corona17[17]. Each framework comes along with its particular advantages and disadvantages.
A central challenge is the possibility to expand the mobile campus app by further third-party applications, web services and mobile learning applications under a single consistent navigation. In order to ensure the integration of existing mobile applications on the one hand as well as the exchange of data between the apps on the other hand, the implementation as a platform independent web application has to be excluded. To decide whether to use a hybrid or a native application for the mobile campus app, experimental results for functionality, performance, user experience and hardware / sensor access were compared. To be able to evaluate hybrid applications, the common and well-known framework PhoneGap was chosen because it already uses established technologies such as HTML and Javascript. Furthermore, according to the official documentation, PhoneGap supports all necessary platforms as well as all essential smartphone functions needed to fulfill the requirements such as the access to camera, NFC, compass or GPS. PhoneGap applications are developed using HTML, CSS and Javascript and are rendered into a web view using a platform-dependent web browser. To allow conclusions comparing native and hybrid applications according to the previous mentioned criteria, a sub-component of the future mobile campus app was implemented as a native Android application and as a hybrid PhoneGap application. Thus, it was possible to evaluate all the necessary test cases including the hardware access or even performance-critical operations for huge item lists. Basically, both, view and functionality, did not differ from each other. However, the performance of the hybrid application was noticeably worse (reaction time about 1000 ms) than that of the native application (100 ms). With the use of plugins like FastClick.js18[18], the performance could be improved to be acceptable with a reaction time about 200 ms. During the implementation phase, the poor documentation of PhoneGap, which was partially severely outdated, hampered the work. For the selected test cases, the hardware access worked without significant restrictions. Besides, the user experience was almost equal. Since PhoneGap makes use of the native browser of each operating system, only limited design options can be used and the developer is handicapped by cross browser compatibility problems with HTML, CSS and Javascript. Another negative point is that part of the hardware access is controlled by the browser which can cause platform- and version-dependent problems.
In consideration of performance and user experience on the one hand and to guarantee device- and platform independence, maintenance and a low technology diversity and therefore minimized development costs (programming, testing, maintenance, development and reusability) on the other hand, the implementation of the mobile campus app as a standalone web application or as a native application do not qualify as solutions. The implementation as a hybrid application is deemed feasible for the mid-term.
In order to ensure a good structure of the source code with respect to improved code quality and maintainability, a combination of standard technologies like HTML5, CSS3 and Javascript as well as some additional libraries is used. Among them are:
In order to enable the integration of third-party applications, the mobile campus app can't be implemented as a monolithic application containing all features in one system. Thus, an architectural construct must be found to implement the core features on the one hand and to ensure the access to third-party applications, mobile websites and other services on the other. This architecture is presented in the following section.
3.2 Architecture of the mobile campus app framework
The mobile campus app framework consists of a hybrid application component that ensures the overall navigation and the access to central information and services. In addition, there is a server component consisting of a web interface and a database where university-wide third-party applications can be inserted. When a user searches for an application from within the mobile campus app, the corresponding results are returned and displayed (see Fig. 2). The results take the current platform into account. For example no Android apps are listed when searching on an iOS device. The search results include a link to the platform-specific app store or alternatively a reference to the app store of the university or another vendor. Finally, the third-party applications appear as a separate link within the navigation point “applications”. Using web intents28[28], the previously installed third-party application can be utilized. As usual, the applications can also be used independent of the mobile campus app.
Overall system architecture of the mobile campus app framework, consisting of the third-party application database, the mobile campus app and the services.
The mobile campus app framework consists of a three-tiered architecture (see Fig. 2). The actual mobile campus app is only present in the presentation layer. The data layer is formed by the university-wide web services. The logic layer between the presentation and data layer uses a service-oriented architecture with a special implementation of an enterprise service bus as a central system component (Kiy/Lucke/Zoerner 2014). While some necessary data of the campus app is available within the application, other systems and services are connected via standardized interfaces. Where possible, established standards for data transport and data formats are used. To query the news and events, RSS and the Facebook-API are used. The access to the existing learning management system Moodle is realized by using the Moodle Mobile web service29[29]. The search of the library relies on the HTTP protocol Search/Retrieve via URL (SRU)30[30] and on the Document Availability Information API (DAIA)31[31] to retrieve the location information and the circulation status of the library resources. For information on the public transportation, the VBB API is used, which is based on the General Transit Feed Specification Format (GTFS)32[32].
In the other cases, the existing systems do not offer machine-to-machine communication interfaces. Therefore, the data exchange for the room management, the campus management system, the cafeteria menu and the contact search is based on self-defined web services and exchange formats. An adaption of the mobile campus app for other institutions can be implemented by adjusting the configurations or by using an XSL transformation.
Finally, there are several data records within the university that only exist locally and that are not machine-readable. This data is collected manually and stored locally within the campus app. This applies to the emergency numbers, opening times, and the location maps. Emergency numbers and opening times use a custom JSON format whereas the maps exist in the JSON-based GeoJSON format. Table 2 gives an overview of the interfaces and formats used in each case.
Overview of interfaces used and the corresponding data formats for the core features of the mobile campus app.
| feature / functionality | interface | data format |
|---|---|---|
| news | web service based on RSS | JSON |
| events | Facebook API | JSON |
| public transportation | VBB-API | GTFS (General Transport Feed Specification) |
| Moodle | Moodle Web Service | JSON |
| campus management system including the personal schedule, lectures schedule and grades | web service | JSON |
| library search | SRU | JSON (MODS) |
| resource availability information | DAIA | JSON |
| library user account | PAIA | JSON |
| Cafeteria menu | web service | JSON |
| room management | web service | JSON |
| contact search | web service | JSON |
| location maps | local | GeoJSON |
| opening times | local | JSON |
| emergency numbers | local | JSON |
3.3 Implementation and state of development
The mobile campus app framework described and the core features of the app from section 2.2 have already been implemented. In addition, the setup of standardized interfaces such as SRU and DAIA was initiated and several interchangeable interfaces e. g. to query the cafeteria menu, news, events or information from the campus management system were established using comparable exchange formats. Decoupling the data and presentation layer using an enterprise service bus opens up the possibility of simply reusing the established interfaces for other applications. This systematic integration approach offers the possibility of drastically reducing the expense when developing new software components. This can be, for instance, websites for room information panels or apps to support the study entry phase. Also, it becomes possible to model cross-system processes in order to enhance existing campus services because the development efforts can usually be limited to the presentation view.
The following figure 3 shows the view of the public transportation of the mobile campus app framework as a realization of the app Mobile.UP as well as a screenshot of the opening times. The app with its core features was released to production using a staged rollout in autumn 2014. To make this possible, a person in the university management had to be found feeling responsible for the app store account on the one hand and being legal representative of the university on the other hand. Afterwards, the app store entry was set up and prepared for beta testing and production release. While approaching the release date, every single stakeholder involved developing the mobile campus app must be asked for approval in order to give them the possibility for feedback or urgent change requests, be it the final interface and interaction, the data formats or the safety requirements of special interfaces.
Screenshot of location maps where places are marked according to their type and a screenshot of the lectures schedule.
Finally, the German law prohibits releasing a mobile application without the existence of an imprint. Thus, an official imprint agreed by all relevant staff members was created and inserted into the application. It has to be always available, easy recognizable and directly accessible (accessible from each view within two clicks).
4 Evaluation
After the completion of the first implementation phase, the app underwent extended user tests for several months. The goal was to derive improvements and enhancements based on the previous user tests to revise, remove or add functions of the application. Therefore, the evaluation consisted of four phases: The first evaluation phase included functional testing and user tests by the developers. Each feature implemented was tested by the other developers. In the second phase, e-learning experts from different disciplines conducted user tests with their personal devices. Here, the core features of the mobile campus app were pre-structured into case studies and assigned to testers. This ensured that each function was tested at least twice by independent users. The testing of further functions beyond those defined in the case studies was optional. As a result of the first tests, major errors in sub-functions of the app and problems regarding the general operation could be identified and resolved. The third phase finally includes continuous and ongoing evaluation and development of the mobile campus app framework in the production phase. Based on feedback in form of e-mails to a ticket system or usage of the feedback functions of the platform stores, the corresponding functions are revisited or supplemented in short development cycles. In order to draw conclusions about the use of core features in the application and to prioritize further developments, a continuous quantitative evaluation based on the API access for the web services is carried out.
So far, valuable user feedback over a period of about two months was collected. Each month the resulting revisions are returned to the user in form of a new version. Smaller presentation and spelling errors were fixed and the navigation and control structure was unified. Until now, most of the errors could be traced down to the use of libraries such as jQueryMobile and the use of different browsers and versions (browser compatibility and outdated browsers). Partially, erroneous representations of images were related to the use of high resolution displays (HR) which were not included in the first test phases. The following improvements had sustained positive impact on the user experience of the application. Among them are:
a visual feedback in form of a loading spinner when querying information
the use of caching mechanisms for all core features
a revision of the navigation structure, reducing the structure from three to two levels (see Fig. 5)
the arrangement of core features as tiles instead of nested lists on the home screen (see Fig. 3)
the reduction of the page transition time from 600 ms to 200 ms
the reduction of the start time of the application by dynamically loading necessary modules.
Revisited navigation concept of the mobile campus app. In contrast to figure 1 the features are grouped in only two main categories and the navigation consists of only two navigation levels.
Implementation of the revisited navigation concept presented in figure 4. The partition of features into tiles enables a more compact view and therefore an improved access for the user. Furthermore, long lists and sub menus are removed, which were criticized by the users in the first version.
The first revised version of Mobile.UP has over 2600 active Android users and, taking all versions into account, over 4100 active Android users. The release for iOS is scheduled for March 2015 in order to add some usual iOS specific user interactions.
Many of the changes presented improve the perceived speed of the application. Based on the average API access, important conclusions for the future development can be derived. For instance, an average of 2000 devices produce 75 requests for the public transportation, 38 for the library search, 1766 for the cafeteria, 1883 for the learning management system, 294 for the campus management system and 3575 to search for free rooms within 24 hours.
5 Summary and outlook
The mobile campus app framework presented enables the provision of university-wide information and services on mobile devices. Moreover, it allows for the modular integration of third-party applications under a uniform and homogeneous app navigation for the first time. The underlying service-oriented architecture and the use of standardized interfaces and data formats results in a scalable und extensible framework. This simplifies transferring the mobile campus app to other institutions. The hybrid development of the mobile campus app with the core features, which can mostly be reduced to information display, has run smoothly with existing frameworks and libraries so far and is thoroughly recommendable.
In subsequent development phases, the application will be developed further based on the collected user feedback. This will include:
the integration of VPN and email
the possibility of shortcuts and bookmark favorites in core features
the extension of the existing library search (pin boards, QR codes and the connection to the spatial information system of the library, the integration of book covers and the common advanced OPAC search)
a way to import contacts from the people directory into the address book of the device
the possibility to reserve rooms
tips and tricks for students
the integration of further university related sources, e. g. different event calendars, media information, news and dedicated information from departments or the public relations office
the possibility to rate cafeteria food and add personal food recommendations
a layout optimization for tablet devices
a unified and strengthened modularization of the application
a way to dynamically add and remove core features
a refinement of the campus plan and supplementing of indoor maps with additional pieces of information on rooms and contacts
the enrichment of the application with contextual information (e. g. through GPS) as well as the linking of features with each other (maps, opening times, people directory and so on)
During development, further tests on the user experience will be performed with random subjects. Therefore, a reusable tool based on the Questionnaire for User Interaction Satisfaction is currently prepared. The mobile campus app framework is available under the public license and will be further developed in a community-driven process.
About the authors
Alexander Kiy ist seit 2011 Mitglied am Lehrstuhl für Komplexe Multimediale Anwendungsarchitekturen am Institut für Informatik und Computational Science der Universität Potsdam. Im Rahmen des eLiS Projekts (E-Learning in Studienbereichen) befasst er sich mit der technischen Konzeption und Entwicklung von Architekturen und Softwaresystemen. Seine Forschungsschwerpunkte liegen in virtuellen Umgebungen und der Integration heterogener Systeme.
Hendrik Geßner ist seit 2013 Masterstudent an der Universität Potsdam. Im Bereich Computational Science setzt er sich intensiv mit Informationsverarbeitung und angrenzenden, häufig interdisziplinären Themen auseinander. Seit 2012 arbeitet er am Lehrstuhl für Komplexe Multimediale Anwendungsarchitektur in den Bereichen E-Learning und pervasive Lernspiele, wobei er seine langjährige Erfahrung bei der Entwicklung und Implementierung serviceorientierter Systeme einbringt. Derzeit ist er im eLiS-Projekt mit der Entwicklung einer Universitäts-App betraut.
Prof. Dr.-Ing. habil. Ulrike Lucke ist seit 2010 Professorin für Komplexe Multimediale Anwendungsarchitekturen am Institut für Informatik und Computational Science der Universität Potsdam. Zudem ist sie als Chief Information Officer der Hochschule für strategische Fragen rund um IT und E-Learning zuständig. Ihre Forschungsschwerpunkte liegen in der Interoperabilität heterogener IT-Systeme, insbesondere im Anwendungsgebiet E-Learning.
Dr. rer. nat. Franka Grünewald promovierte bis 2014 am Hasso-Plattner-Institut zum Thema Verknüpfung von Social Web und Topic Maps mit Tele-Teaching zur Bereitstellung nutzerfreundlicher Interaktionsmöglichkeiten mit E-Lectures. Als Projektkoordinatorin ist sie aktuell im eLiS-Projekt der Universität Potsdam tätig. Ihre Forschungsschwerpunkte liegen im Bereich E-Learning, dazu zählen insbesondere die Verknüpfung von Social Web und Semantik Web sowie die Nutzerperspektive auf digitale Medien zum Lehren und Lernen.
Acknowledgement
Special thanks to Mrs. Maren Schulze from the audiovisual center of the University of Potsdam for the design of the navigation structure and the look of the mobile campus app.
References
Bernoth, J.; Kortsch, A.; Kaatz, V.; Lass, S.; Zender, R.; Lucke, U.: Studi.UP - Mobile Mehrwert-Dienste für konventionelle Legacy-Applikationen des Campus Management. In: Rensing, C.; Akbari, M.; Böhnstedt, D.; Breme, C.; Chatti, M. A. (ed.): Workshop Mobile Learning - Einsatz mobiler Endgeräte im Lernen, Wissenserwerb sowie der Lehr-/Lernorganisation der DeLFI, Fernuniversität Hagen, 2012.Search in Google Scholar
Bischoff, A.: Dienste für Smartphones an Universitäten - ein plattformunabhängiges Augmented Reality Campus-Informationssystem für iPhone und Android-Smartphones. In: Werner, M.; Roth, J. (ed.): 8. GI/KuVS-Fachgespräch Ortsbezogene Anwendungen und Dienste, Logos Verlag, Berlin, pp. 127–135, 2011.Search in Google Scholar
Brückner, C.; Hafer, J.; Henze, L.; Schumann, M.: Wer sind typische E-Learner? Auf den Spuren der aktiven Mediennutzer/-innen unter den Studierenden der Universität Potsdam. Sekundärauswertung einer Mediennutzungsbefragung. In: Bremer, C.; Krömker, D. (ed.): E-Learning zwischen Vision und Alltag, Medien in der Wissenschaft, Band 64, Waxmann, Münster/New York, München/Berlin, 2013.Search in Google Scholar
Bührig, J.; Guhr, N.; Breitner, M.: Technologieakzeptanz mobiler Applikationen für Campus-Management-Systeme. In: Heiß, H. U.; Pepper, P.; Schlinghoff, H.; Schneider, J. (ed.): INFORMATIK 2011 - Informatik schafft Communities, Bonner Köllen Verlag, Berlin, 2011.Search in Google Scholar
Cochrane, T.; Antonczak, L.: A Mobile Learning Community of Practice - Facilitating Conceptual Shifts in Pedagogy. In: EC-TEL 2013 - Scaling up Learning for Sustained Impact, pp. 430–435, Springer, 2013.10.1007/978-3-642-40814-4_34Search in Google Scholar
Eimeren, B. van; Frees, B.: Ergebnisse der ARD/ZDF-Onlinestudie 2013 - Rasanter Anstieg des Internetkonsums - Onliner fast drei Stunden täglich im Netz. Media Perspektiven, vol. 7–8, pp. 358–372, 2013.Search in Google Scholar
Gommlich, F.; Heyne, G.: Persönliche Lernumgebung - Architektur für Smartphones. In: Horbach, M. (ed.): INFORMATIK 2013 - Informatik angepasst an Mensch, Organisation und Umwelt, pp- 279–292, Bonner Köllen Verlag, Koblenz, 2013.Search in Google Scholar
Hilse, M.; Lucke, U.: Systematische Verankerung von E-Learning in der Breite der Hochschule. In: Neues Handbuch Hochschullehre, Raabe, Berlin, 2013.Search in Google Scholar
Kerres, M.: Potenziale des Lernens im Internet - Fiktion oder Wirklichkeit. Deutsch global, pp.170–195, 2000.Search in Google Scholar
Kiy, A.; Hofhues, S.: Persönliche Lernumgebungen im Spannungsfeld der institutionalisierten Lehre der Hochschule: Designprinzipien für eine hybride PLE. erscheint in: Reihe Blickpunkt Hochschuldidaktik (in Druck).Search in Google Scholar
Kiy, A.; Lucke, U.; Zoerner, D.: An Adaptive Personal Learning Environment Architecture. In: Maehle, E. et al. (ed.): Architecture of Computing Systems, ARCS 2014, LNCS 8350, pp. 60–71, Springer, 2014.10.1007/978-3-319-04891-8_6Search in Google Scholar
Knoth, A; Kiy, A.: (Selbst-)bewusst durch die Studieneingangsphase mit der Reflect-App. In Proc. of DeLFI Workshops 2014 co-located with 12th e-Learning Conference of the German Computer Society (DeLFI 2014), Freiburg, Germany, September 15, pp. 172–179, 2014.Search in Google Scholar
Stotz, L.; Hoppe, G.; Breitner, M. H.: Interaktives Mobile (M) - Learning auf kleinen Endgeräten wie PDAs und Smartphones. IWI Discussion Paper Series, 12, 2004.Search in Google Scholar
Wegener, R.; Prinz, A.; Leimeister, J. M.: Entwicklung innovativer, mobiler Lernanwendungen für den Einsatz in Massenveranstaltungen. In: 6th Conference für Mobile und Ubiquitäre Informationssysteme (MMS), Kaiserslautern, 2011.Search in Google Scholar
Wilson, S.; McCarthy, G.: The mobile university - from the library to the campus. Reference Services Review, vol. 38(2), pp. 214–232, 2010.10.1108/00907321011044990Search in Google Scholar
Zender, R.; Dehne, J.; Geßner, H.; Lucke, U.: RouteMe - Routing in Ad-hoc-Netzen als pervasives Lernspiel. In: i-com Zeitschrift für interaktive und kooperative Medien, band 12, Heft 1, pp. 45–52. ISSN (Print) 1618–162X, DOI: https://doi.org/10.1524/icom.2013.0007, 2013b.Search in Google Scholar
Zender, R.; Falkmann, N.; Wegner, D.; Lucke, U.: WordsUP - Tabu für das Lernen von Fachvokabular. In: Proceedings der Pre-Conference Workshops der 11. e-Learning Fachtagung Informatik DeLFI 2013, pp. 25–30, Koblenz, 2013a.Search in Google Scholar
Zoerner, D.; Gößler, F.; Lucke, U.: Hochschul-Apps im Überblick. In: Proceedings der 44. Jahrestagung der Gesellschaft für Informatik, Freiburg, 2014.Search in Google Scholar
© 2015 Walter de Gruyter GmbH, Berlin/Boston
