Engineering Hybrid Learning Communities: The Case of a Regional Parent Community ^†

Abstract

We present an approach (and a corresponding system design) for supporting regionally bound hybrid learning communities (i.e., communities which combine traditional face-to-face elements with web based media such as online community platforms, e-mail and SMS newsletters). The goal of the example community used to illustrate the approach was to support and motivate (especially hard-to-reach underprivileged) parents in the education of their young children. The article describes the design process used and the challenges faced during the socio-technical system design. An analysis of the community over more than one year indicates that the hybrid approach works better than the two separated “traditional” approaches separately. Synergy effects like advertising effects from the offline trainings for the online platform and vice versa occurred and regular newsletters turned out to have a noticeable effect on the community.

1. Introduction

Early childhood education is of tremendous importance and lays the basis for later (educational) success [1,2,3]. Education can be seen as supporting children in their development (e.g., learning to use their senses). Especially in early childhood stages, education often means direct interaction with children, either with or without support of technology [4,5].

Parents and family have an essential influence on the course of early childhood education processes and the development stages of children. Hence, a viable way of improving early childhood education is to motivate, encourage, and support parents to educate their children. However, Büchner [6] and Davis-Kean [7] suggested that the social origin and the level of education of parents have a bearing on the future and academic achievements of their children. Training parents might help, but there are often significant problems to reach and motivate parents from disadvantaged backgrounds or underprivileged families (in this context we define “underprivileged” as both parents having a low level of formal education, which often results in fewer socio-economic resources). Bauer and Bittlingmayer describe this as the so-called “prevention dilemma”: Underprivileged parents often have more problems parenting their children and require more support—while being the ones who make the least use of educational offers or trainings [8].

Traditional face-to-face trainings are well established and have shown to be an effective way of educating parents. Here, trainers and trainees (parents) know each other, trust can be established, and trainers can adapt to their trainee’s needs easily. However, those trainings have major drawbacks as they do not scale, provide no low-threshold access, and are problematic regarding participation of underprivileged parents. The trainings are limited in the number of possible participants, and the attending parents are bound to opening hours [9]. It is also important that trainings can be taken without “losing face”. In particular, parents who have little confidence in their parenting skills often hesitate to make their feared or actual deficits publicly visible [10]. Many parents consider family life as private, and thus they do not disclose it to strangers without an important reason [10]. This means that there are certain groups of people who have a fear of “losing face” or social shame and, therefore, often do not participate in face-to-face trainings.

With the advent of the social web, several Internet online parent communities emerged where parents can get access to educational resources and can also interact with each other. Contrary to local face-to-face trainings, interactive online trainings and platforms scale better, provide a low-threshold access to educational resources, and allow parents to get in contact with each other easily and (if desired) anonymously. Nevertheless, most online trainings and platforms are not regionally bound. This makes it very difficult for the providers/trainers to meet the needs of parents of a specific region (like a district or town), to meet needs of specific parents, or simply to meet in person with parents—which may sometimes just be the best option, despite all information technology.

In order to fill this gap and to mitigate the prevention dilemma, we propose a hybrid community approach which combines the advantages of face-to-face trainings with the advantages of an interactive online platform. The online and offline aspects of the parent community do not only exist side by side, but are intended to be tightly connected and intertwined with each other (e.g., via regular e-mail and SMS newsletters informing about upcoming and contents of past local face-to-face events). Our main research hypothesis is that this hybrid approach is more effective than the two components separately. This main hypothesis can be broken down into several sub-hypotheses: (H2) The majority of the community members will be from a regionally bound area but (due to the hybrid approach) there will also be other members; (H3) parents registered in the online community will attend more face-to-face events than non-registered parents (based on a stronger binding to the community); (H4) regular SMS and e-mail campaigns are vital for the community (by working as a reminder), and (H5) the hybrid approach brings synergy effects in the sense that face-to-face events promote the online platform and vice versa (based on mutual advertisement effects). Further explanations regarding the hypotheses and the evaluation results can be found in Section 5 of this article.

The remainder of this paper is organized as follows: The next section gives an overview of related research. In Section 3 we detail our approach and describe the stakeholders and requirements. The fourth section explains the design process and challenges of the socio-technical system. Section 5 describes the scenario of the example parent community and presents our research questions and hypotheses in more detail. In the last sections, our results are presented and discussed.

2. Related Research

Community based approaches are widely used in educational contexts. Communities can be classified in two dimensions as either non-hybrid (i.e., entirely face-to-face or entirely online) or hybrid and as either formal or informal. In the remainder of this paper, formal learning communities are understood as classroom based or settings in which learning is controlled by trained teachers only. Informal learning communities are the opposite—settings where people meet, control their own learning and share experience. In the field of parent training, face-to-face communities typically make use of traditional methods such as local meetings or seminars [2,11]. Such communities are usually supervised by pedagogues and regionally bound by design (members of the community cannot meet or communicate easily with each other over longer distances; especially one-to-many communication is often problematic). Normally these face-to-face communities are informal; however, also formal meeting structures exist (e.g., parents’ evenings about specific topics or information events provided by family care facilities). In contrast, pure online communities are accessible from everywhere via the web, and their members are usually regionally distributed. Communication is mainly mediated through the online platform. Formal and informal online communities with distributed learners have been investigated especially by the CSCL (Computer Supported Collaborative Learning) research field. For instance, Cho et al. [12] analyzed how 31 distributed learners collaboratively designed an aerospace and investigated relationships between communication styles, social networks and learning performance. One of the main results of this study was that communication styles and pre-existing friendships significantly affected the way the students developed collaborative social networks. A conclusion from the study was that “communication and social networks should be central elements in a distributed learning environment” [12] (p. 2). Brown [13] proposed a theory about the process of community-building in distance learning courses. In a study with 21 students and 3 faculty members in 3 classes, three levels were distinguished using a grounded theory approach: making friends online, acceptance of the community, and camaraderie—each level was characterized through a greater degree of involvement of the members in the community and also in the classes. Nielson [14] proposed a similar theory for generic communities: The user engagement pyramid—a broad basement of passive users and fewer more active users “on top”. Despite this (and other) research on learning communities in general, specific research on parent communities is lacking—despite the fact that several (informal) online parent communities are established (like eltern.de, mamacommunity.de or community.parents.com), most of them without pedagogical supervision.

Hybrid communities combine face-to-face and online aspects. Hence, members of such a community are often mainly regionally bound and can communicate or meet both online and offline. Typical examples of hybrid communities can often be found in school or university scenarios, connected to terms such as “extended classrooms” or “blended learning”. For example, Harrer et al. [15] provided university students a platform with a wiki and discussion boards in order to work on group projects in combination with a presence lecture. Communication processes and structures of their platform were evaluated. None of the two communication forms proved to be superior to the other, however, a combination produced better results (according to final scores). Cho et al. [16] provided their students with a discussion board and a mailing list. One of their results was that the mailing list was a better communication channel than the discussion board (due to the push character of e-mails). Dohn [17] discusses inherent tensions, challenges and opportunities of using collaborative content development in schools and university education based on her practical experience in several courses. In her analysis, she stresses that using web technology like wikis or blogs for teaching alone does not make for a collaborative learning setting (e.g., in the case that content is only provided by the teacher). Due to their rising popularity, social networks have also been investigated by researchers regarding hybrid community aspects (mostly in university contexts). Ellison et al. [18] explored the use of Facebook for the formation and maintenance of social capital and the social ability of students to stay connected to members of a community of which one previously was a member of. One of their main results was that Facebook has a high utility for maintaining or solidifying existing offline relationships, as opposed to meeting new people. In a study, Shaoke et al. analyzed the type of friends of students on Facebook and came to a similar result: 88.9% were local friends whereas 41.1% are current local friends and 47.8% were previous local friends [19]. Wong et al. [20] point out that Facebook can also be a place for (informal) learning since it provides discussion forums, instant messaging, the ability to share videos as well as pictures, and has a sophisticated group feature. They explicitly stress that the group feature can be easily used to build a Community of Practice (or Interest) and instantly share resources within such a group. Madge et al. [21] and Bosch [22] used Facebook for building a hybrid learning community at their universities. Madge and colleagues conclude that Facebook is mainly used for socializing and “talking to friends about work instead of actually doing work” [21] (p. 141). Facebook was called the “social glue” for students and helped to propose and plan (social, offline) events [19,21]. However, Madge et al. and Bosch point out that Facebook was also used by some students for informal learning purposes (such as organizing group meetings for academic project work, replicating classroom networks and informally exchanging course-related questions and discussions) [21,22]. In the study of Madge et al. 91% of the users agreed that Facebook and formal teaching should be kept strictly separate (they did not contact academic staff via the social network and did not want them to do so either) [21]. Sickler found something similar in a qualitative study: Some students view faculty participation in Facebook as an encroachment into their own space [23]. Bosch similarly describes that also lecturers ignored friend requests of students [22]. However, Bosch reports about a quality study performed by J. Dubroff in 2005 at Yale University (the direct source is not available any more), indicating that Facebook helped to break down barriers between faculty staff and students. Bosch also describes that Facebook enabled and supported some students to ask questions based on the relative degree of anonymity on Facebook. Going into the same direction, Ellison et al. suggest that Facebook is especially helpful for students with low self-esteem and low life satisfaction and provides greater benefits for them to stay in contact [18]. In summary, social networks such as Facebook are already used for managing locally bounded communities and can lower social barriers; however, some of those (with the exception of Google+ circles) are not optimal for separating the private from the formal learning context.

A noticeable research result is that community systems are not automatically accepted by an intended target group. It is not enough to just deploy a technology and make it available on the web, hoping that the target audience will eagerly use it [17,24]. In school or university scenarios, students as the target group are oftentimes required to use an online community system in order to pass a course [12,17]. Yet, there are also other scenarios in which an online community system was deployed on request of the users or in order to bring people together. Here, one example is the work of Rohde et al. [25] who investigated a hybrid student community which was successful in connecting students and allowing them to discuss discipline-related and organizational topics; however, it was restricted to students of a specific major of the University of Hamburg, Germany. In universities, community support can also be designed for different user roles, including faculty, staff and research groups (in order to exchange knowledge), alumni (for information flow and creating a common identity), and students (for teaching and linking with alumni). In a related study of Koch [26], e-mail notifications and newsletters were found to be a key feature of a community platform.

In addition to the community approaches discussed above, there is also research focusing on “digital parenting” investigating the ways that parents (of different social classes) use online resources to support parenting decisions (and organize their children’s media consumption, cf. [27]).

Concluding, there is already ample research on hybrid communities. Yet, this research almost exclusively focuses on closed communities where access is limited to specific users (e.g., students of a specific course) in formal school or university settings. In the field of parent education and in the context of open regionally bound communities, research results on design or evaluation of hybrid (informal) learning community support systems are largely missing.

3. The Mobile2Learn Approach: A Hybrid Parent Community

In this section, our proposal for building a regionally bound Community of Practice [28] which integrates real and virtual elements is explained in more detail. We then describe the stakeholders and requirements which are highly relevant for a design of such a socio-technical system in Section 3.2.

3.1. Developing a Hybrid Parent Community

Our approach relies on using information and communication technology (ICT) in form of an interactive web platform as well as real-world events to motivate parents (especially from educationally and socially disadvantaged families) and support them to educate their small children according to age. The approach aims to combine the mutual advantages (especially scalability, low-threshold access, and established trust) of real-world events and online interactive media. According to Smolka [9], getting into contact with parents (especially from socially disadvantaged families) requires the use of many different channels. Moreover, our goal was to build an active parent community through the provision of personalized learning contents. Generally, it is important to note that such a community cannot be announced as being focused on underprivileged parents publicly, but as open for all parents (otherwise, probably only few persons want to be part of the community). Additionally, events and the usage of the online platform must be free—otherwise it is unlikely that parents (especially of the target group) will use it.

The offline aspects of the hybrid approach are based on traditional parent seminars and parent-children events. These events should take place at central and neutral locations which are easily reachable and accessible by parents [9]. Conducted by experts of the current topic of event, the events are not only for communicating educational ideas and materials and building the community, but also serve as direct contact to the attending parents to find out about their needs and feelings as a guide for future activities (offline and online).

The online aspects of the hybrid approach consist of an interactive educational online platform using Web 2.0 technologies and methods. It aims to offer parents a low-threshold access to the content (such as education articles, interactive quizzes) or pictures of the events and also further and deeper information on the topics of the events. Of course, the education articles have to be written in an understandable language and in an attractive form for the target group. With this approach, parents who did attend an event can deepen their knowledge. At the same time, also parents who did not attend any events could view the photo galleries and educational resources. Thus, they can (hopefully) be motivated to attend events in the future. Furthermore, a key function of the online platform is to “bridge” the time between each event and allow parents to stay in contact with each other and the community more easily and continuously. It is also very important to stay in contact with the target group, regularly remind parents of the existence of the community, and push news to parents. In addition to traditional e-mail newsletters and notifications, mobile phones (with SMS messages) are included in the approach. The motivation for this integration is the high reachability of the target group through mobile phones (while not all parents might have an e-mail address). In 2006, nearly all (97.9%) households of couples with a child in Germany were equipped with mobile phones [29]. Also, SMS messages are pushed to the devices, so that there is no need to actively retrieve or collect information manually. In addition, mobile phones are mostly worn closely to the owner. Thus, parents are directly reachable; however, this communication channel has to be used with caution because it is quite invasive.

In order to get an initial contact to the target group, a broad regional network of institutions, facilities and services needs to be formed (in the following called “partners”). Good choices are partners which are typically frequented by the target group or have access to the target group in the context of their activities (e.g., child doctors, or family services). This network is used to directly and personally inform parents (especially of the target group) and invite them to participate in the events and to register on the online education platform. In addition, partners should also be integrated in the community, provide their professional expertise and have a benefit from this by advertising themselves. A way for doing so is to highlight postings/articles in the online education platform and allow them to create an extended profile page.

The key design goal of our approach is a mutual support of both parent education forms (online and offline, cf. Figure 1): On the one hand, Haythornthwaite et al. [30] and Ellison et al. [18] showed that contacts established offline and trust already built can be maintained online. On the other hand, it is a goal that parents who have not participated in any event yet can be motivated to do so via using the online platform.

Figure 1. Example of the hybrid approach (left: screenshot of online platform, right: photos of events; Note: Persons shown are not necessarily underprivileged).

Figure 1. Example of the hybrid approach (left: screenshot of online platform, right: photos of events; Note: Persons shown are not necessarily underprivileged).

On the online platform, some content needs to be accessible without registration. However, some content should to require login. This way it is possible for parents to explore some of the educational contents anonymously. This may provide some incentives to register and to become a more active part of the community. Research and rich experience in the field of ecommerce provide appropriate strategies for binding users to an online service or a community via different stages (from a “random visitor” as the passive consumer to an active user who passes his knowledge on to others; [14,31,32]).

Registered users have unrestricted access to view all contents. Being a part of the Community of Practice, registered users need the capability to communicate [33]: They can use the internal messaging system for one-to-one communication or a bulletin board for one-to-many communication. In order to allow parents to ask also potentially embarrassing questions, the discussion forum should allow users to stay anonymous in such a thread. Answers of partners should be highlighted to indicate that they come from professionals. A Community of Practice also requires the capability for members to share practices and experiences. Thus, registered users should be able to submit their own contributions (e.g., articles and pictures). For quality and copyright reasons, these should not be published online to the community immediately without review of a professional author. Another form of communication is commenting on and rating articles and photo galleries. This feedback can also be used as a guide for further development of the community (e.g., suggestions of new topics for events or other adjustments).

This approach was collaboratively developed by experts of traditional parent trainings (members of the community college Goslar, Germany, members of the registered association for rural adult education LEB, experienced day-care workers, and a teacher of a local vocational school) and members of the Institute of Computer Science of Clausthal University of Technology, Germany, who are experienced with HCI (Human Computer Interaction), community building, and web technologies. The idea for the approach emerged based on the described shortcomings of traditional parent trainings and was inspired by the motivation of using “modern” technologies to overcome these shortcomings.

3.2. Derived Requirements

In this section, we are presenting the requirements of the socio-technical system in a more formalized form. Our hybrid approach consists of the Mobile2Learn web platform and the offline presence meetings. The web platform (the computer supported part of our hybrid approach) is addressed with the term “system” in the following (specifically, in Figure 2). It is accessed by the members of the community using their computers and/or mobile devices in order to perform tasks (e.g., retrieve educational contents, contact other community members, publish contents, or manage the community, cf. Section 3.1 and this section). The devices of the users are not considered part of the system as they are no special devices and there is no need to install special software on them, but they are used to interact with the system (e.g., indirectly by reading SMS and e-mail newsletters or directly by accessing the web platform using a web browser). The web platform also interfaces with other systems in order to fulfill some its functions (e.g., a mail server for sending newsletters or an SMS gateway for sending SMS messages, cf. Section 4.2). This list of requirements has been derived based on a systematical analysis of the goals and ideas described in Section 3.1 by applying prevalent requirements engineering methods (such as stake holder identification as well as interviews and use case identification). Figure 2 shows a Unified Modeling Language (UML) use case diagram depicting the stakeholders and the system functionality they use.

The different stakeholders manifest in the following five user roles: Anonymous visitor, parent, partner, lecturer, and author.

• Anonymous visitors are normal people visiting the website without being logged in. They have read-only access to a limited set of articles (as incentives for registration) and the discussion forum.
• Parents are visitors who already created an account and are logged in. They are able to read all articles, view all galleries, recommend items, comment on items, rate items, and hand in ideas and drafts for new articles or taken photos. They can also use the internal messaging system, the discussion forum with read-write access, and can create their own profile page.
• Partners are special accounts, not for individuals, but for institutions such as kindergartens, daycare providers, and (child) doctors. The reason for differentiating between normal users (parents) and institutional partners is to highlight professionals on the platform. If parents have questions and a doctor answers them, it should be clearly visible that this is a professional answer. Also, institutional partners have extended options for their profile. This way they can use the platform for advertising themselves (e.g., providing some text describing the institution and a link to their website).
• Lecturers are partners who conduct an educational event in the offline (real) world. Thus, they provide official documentation of the events as educational articles.
• Authors are accounts which are able to create, edit, review and publish content (articles, photo galleries, quizzes) on the platform. They are also able to send e-mail and SMS newsletters. Tagging is limited to authors in order to ensure a consistent taxonomy.

Figure 2. Unified Modeling Language (UML) use case diagram.

Figure 2. Unified Modeling Language (UML) use case diagram.

Based on the described stakeholders and the ideas of the approach, the (functional and non-functional) requirements on the community platform can be clustered to the following eight categories: basic functions, community features, content management system, mobile phone (SMS) integration, privacy options and sophisticated rights management, support for different user roles, advanced logging/tracking, and easy extensibility. The clustering was done by grouping all use cases regarding common requirements in order to provide a better overview of the central requirements of our social-technical system. Note that this clustering is a design decision and not the only possible way of grouping our requirements (e.g., Mobile phone (SMS) integration could also have been included into Easy extensibility, however, SMS integration was so central to our approach that we decided to include it as a separate cluster).

• Basic functions include minimum requirements for community platforms such as providing ways to register, log in and retrieve lost passwords as well as an administrative interface for managing configurations, users, etc.
• Community features include communication support (internal messaging, e-mail newsletters, forums, commenting of artifacts, invite friends, recommend articles), rating of artifacts, and avatars.
• A sophisticated content management system (CMS) which allows for easily adding and editing content online. The CMS must also be capable of providing different templates as well as layouts (e.g., for a different look of official and user-generated content) and workflow support (users can add new articles, reviewing/publishing by some other person).
• Mobile phone (SMS) integration across the whole system (to be usable for users without an e-mail address just by a mobile phone number or in addition to e-mail). This includes registration (including verification of the mobile phone number), lost password functions, SMS newsletters, and artifact recommendations. If a user provides a mobile phone number as well as an e-mail-address, the default should be to use e-mail for cost reasons (except for the newsletters which are specifically designed for SMS).
• Privacy options and sophisticated rights management as required by German law, the German user base and their expectations, and the design of our approach. Parents should be able to use a nick name in order to mask their real identity, the forum needs to be read-only for non-registered users, galleries and articles need to be configurable as public or not, and the avatar and user profile page of parents have to be visible to registered users only. Especially the public vs. non-public articles need special attention. Often (links to) not readable articles are just hidden. If one wants to use them as incentives for registration however, they need to be visible, but highlighted as “non-accessible” (e.g., by a lock symbol). Moreover, if a user tries to access a non-readable article, a page containing the option to login and explaining the advantages of registering should be shown instead of a plain “access denied” message.
• Support for different user roles (i.e., partners and parents) which requires different registration pages (different attributes are requested for each role; also, partner profiles need to be verified and activated manually), highlighting of partner posts in discussion forums, and public extended profile pages for partners, and a public list of all partners.
• Advanced logging and tracking is especially required for evaluation of the system and generation of (anonymized) statistics for authors. Thus, the system needs to track who accessed what artifacts (articles, galleries, clicks on newsletters, logins), who recommended what to whom, who invited whom, and meta-data of internal messaging.
• Easy extensibility for adding further special requirements and modules/plugins: This particularly includes a software license which allows editing the source code (commercial or open source) as a key requirement. Our special requirements include changes to the forum in order to allow parents to start anonymous threads. Modules are also required for providing automatic recommendations (of artifacts and upcoming events), offline registration (parents fill out a paper form for registering to the online platform, authors create an account and send an activation key to the e-mail-address and mobile phone number in order to allow registering “from everywhere”), a module for interactive quizzes, and a special module for managing the offline events (i.e., managing of event locations, the events themselves, and keeping track of event attendances of parents, whether registered in the system or not).

These eight categories of requirements provide a holistic view of all requirements and therefore are a mix of functional and non-functional requirements (which are often closely interdependent in our scenario). In Table 1 and Table 2, the functional and non-functional requirements are listed in a separate fashion and in more detail. Note that not all requirements in Table 1 map to exactly one of the eight clusters in order to reduce the number of requirements in the table. For example, FR1 maps to Basic functions, Mobile phone (SMS) integration and Support for different user roles and was indeed split into three sub requirements in our requirements analysis: FR1.1 Support different roles, FR1.2 Mobile phone integration and FR1.3 Verification of e-mail addresses. Table 1 also includes a mapping to the use cases (presented in Figure 2) from which they are derived.

Table 1. Functional requirements.

No.	Title	Short Description	Cluster(s)	Use Case(s)
FR1	Register online	Allow visitors to register to the community platform. Registration should request visitors to enter a nickname, a password and to confirm the privacy statement. The registration process needs to support the different roles of parents and partners. Parents additionally need to enter a mobile phone number and/or an e-mail address, their real name, (postal) home address, birth date, gender and optionally the names and birthdates of their children. For partners the institutional name, the postal address, a telephone number and the name of a responsible person is required additionally. The process needs to make sure that entered e-mail-addresses and/or mobile numbers are valid. Partner registrations should not be enabled by default. The system should send a confirmation/welcome message to the e-mail address and/or mobile phone number.	Basic functions, Mobile phone (SMS) integration and Support for different user roles	UC1, UC1.1, UC1.2
FR2	Input offline registrations	Allow authors to input the data of parents who registered (offline) using a paper form into the system. The system should send a confirmation/welcome message to the e-mail address and/or mobile phone number.	Easy extensibility	UC1, UC1.1, UC18
FR3	Log in	The system needs to allow users to log in using their e-mail address or mobile phone number and their password.	Basic functions and Mobile phone (SMS) integration	UC8
FR4	Retrieve new password	Registered users who lost their password need a way to retrieve a new one (by e-mail or SMS), For cost reasons e-mail should have precedence.	Basic functions and Mobile phone (SMS) integration	UC14
FR5	Manage users	Authors and system administrators must be able to manage registered users (e.g., listing, activating, deactivating).	Basic functions	UC18
FR6	Use internal messaging	Logged in users need the ability to send internal messages to each other.	Community features	UC7
FR7	Use forums/bulletin board	The system must provide a forum, which is readable by all visitors. Creating new threads or answering should be limited to registered users. Logged in parents need to ability to create threads anonymously. Answers of partners need to be clearly displayed as such. The forum also should send notifications on new activity on monitored threads.	Community features and Privacy options and sophisticated rights management	UC6, UC6.1, UC6.2
FR8	View and edit user profiles	The system must support user profile pages and avatar pictures for registered users. This also includes editing the profile and related information. The system also needs to support different styles of profile pages for parents (simple) and partners (more advanced). The profiles of parents must only be visible to logged in users; the profiles of partners should be publicly viewable (same applies to the avatar pictures).	Community features, Support for different user roles and Privacy options and sophisticated rights management	UC2, UC9, UC9.1, UC13
FR9	Invite friends	Logged in users should be able to send invitation e-mails to friends.	Community features	UC10
FR10	Comment on artifacts	Logged in users need to be able to comment on artifacts. Comments should be visible to all users who can view the artifact. There also needs to be an interface for authors to see/review all new comments.	Community features	UC5
FR11	Rate artifacts	Logged in users need to be able to rate artifacts on a one to five star scale. Ratings should be visible to all users who can view the artifact.	Community features	UC12
FR12	Recommend articles	Visitors should be able to recommend articles via e-mail or social media. Registered users should also be able to recommend articles using predefined SMS messages.	Community features and Mobile phone (SMS) integration	UC10
FR13	Send newsletters	Authors must be able the send personalized newsletters to users via e-mail and SMS. Recipients need the ability to unsubscribe.	Easy extensibility and Mobile phone (SMS) integration	UC19
FR14	Retrieve personalized information	The system should use the name of the user to greet them and should provide personalized recommendations to users logged in (artifacts and events) on the start page and in newsletters.	Community features, Mobile phone (SMS) integration and Easy extensibility	UC4
FR15	Add, edit and manage pages/articles	The system must allow the management of articles and pages by authors. Authors should be able to use templates and select different optical layouts for specific articles. Editing of the articles should be done using a WYSIWYG editor which allows to hyperlink other articles easily. The CMS must allow articles to be structured in a hierarchy (in order to reflect the topics of the event series).	Content management system	UC16
FR16	Add, edit and manage photo galleries	The system must allow the management of photos and photo galleries by authors. Photos of the galleries should be usable using the CMS module in order to hyperlink or include them in articles easily. The galleries need to be structured in a hierarchy (in order to reflect event series and concrete events).	Content management system	UC16
FR17	View and manage interactive quizzes	The platform should provide interactive quizzes (e.g., in the form of self-tests) for registered users. This also includes authoring functionality for authors.	Easy extensibility	UC16
FR18	Tag contents	Authors need the ability to tag artifacts in order to link similar artifacts and providing a structure regarding different aspects (based on tags) independently to the hierarchical structure.	Content management system	UC15
FR19	Submit articles/photos	Logged in users should be able to submit photos and articles. Submitted articles should be inserted into the CMS and marked for review for authors. Same applies to photos.	Content management system and Easy extensibility	UC11
FR20	Define visibility/accessibility of contents	Authors must be able to define visibility states (published/under-review state) and accessibility restrictions for anonymous visitors. This includes that links to artifacts which are not accessible are visible and marked with a lock symbol. If such a link is clicked on, the system should provide a special page which contains the advantages of registering, a link to the registration page and a log in form for registered users. Artifacts in the under-review state must be completely invisible to all users despite the editors.	Content management	UC3, UC3.1
FR21	View public list of partners	A list of partners with links to their corresponding profiles must be visible to all visitors.	Easy extensibility	UC2
FR22	Manage offline events	The system must be able to add and edit event series and concrete events (i.e., location, date and time) in order to display it in a structured way. This also includes the ability to enter attendance lists with the platform (i.e., which registered user attended which events).	Easy extensibility	UC17
FR23	Retrieve (real-time) statistics	For continuous feedback and evaluation reasons the system needs to present detailed statistics. This includes statistics about ages of the users, ratings, comments, visit durations, number of read articles (also differentiated between parents who visited a corresponding event or not), number of events attended, distances of parent’s locations of attended events, number of registered user by event location, numbers of parents (total, who visited an event, who live in the district of Goslar, etc.) and partners, information about the timing and order of visiting an event and registering online, number of internal messages sent or friends invited, and reactions/clicks to/on e-mail and SMS campaigns.	Advanced logging and tracking and Easy extensibility	UC20
FR24	Log and track user behavior	The system needs to log errors and collect data about the usage of the platform for statistical evaluations (closely related to FR1, FR3, FR6, FR7, FR9-14, FR22 and FR23).	Advanced logging and tracking	UC20

Table 1. Functional requirements.

No.	Title	Short Description	Cluster(s)	Use Case(s)
FR1	Register online	Allow visitors to register to the community platform. Registration should request visitors to enter a nickname, a password and to confirm the privacy statement. The registration process needs to support the different roles of parents and partners. Parents additionally need to enter a mobile phone number and/or an e-mail address, their real name, (postal) home address, birth date, gender and optionally the names and birthdates of their children. For partners the institutional name, the postal address, a telephone number and the name of a responsible person is required additionally. The process needs to make sure that entered e-mail-addresses and/or mobile numbers are valid. Partner registrations should not be enabled by default. The system should send a confirmation/welcome message to the e-mail address and/or mobile phone number.	Basic functions, Mobile phone (SMS) integration and Support for different user roles	UC1, UC1.1, UC1.2
FR2	Input offline registrations	Allow authors to input the data of parents who registered (offline) using a paper form into the system. The system should send a confirmation/welcome message to the e-mail address and/or mobile phone number.	Easy extensibility	UC1, UC1.1, UC18
FR3	Log in	The system needs to allow users to log in using their e-mail address or mobile phone number and their password.	Basic functions and Mobile phone (SMS) integration	UC8
FR4	Retrieve new password	Registered users who lost their password need a way to retrieve a new one (by e-mail or SMS), For cost reasons e-mail should have precedence.	Basic functions and Mobile phone (SMS) integration	UC14
FR5	Manage users	Authors and system administrators must be able to manage registered users (e.g., listing, activating, deactivating).	Basic functions	UC18
FR6	Use internal messaging	Logged in users need the ability to send internal messages to each other.	Community features	UC7
FR7	Use forums/bulletin board	The system must provide a forum, which is readable by all visitors. Creating new threads or answering should be limited to registered users. Logged in parents need to ability to create threads anonymously. Answers of partners need to be clearly displayed as such. The forum also should send notifications on new activity on monitored threads.	Community features and Privacy options and sophisticated rights management	UC6, UC6.1, UC6.2
FR8	View and edit user profiles	The system must support user profile pages and avatar pictures for registered users. This also includes editing the profile and related information. The system also needs to support different styles of profile pages for parents (simple) and partners (more advanced). The profiles of parents must only be visible to logged in users; the profiles of partners should be publicly viewable (same applies to the avatar pictures).	Community features, Support for different user roles and Privacy options and sophisticated rights management	UC2, UC9, UC9.1, UC13
FR9	Invite friends	Logged in users should be able to send invitation e-mails to friends.	Community features	UC10
FR10	Comment on artifacts	Logged in users need to be able to comment on artifacts. Comments should be visible to all users who can view the artifact. There also needs to be an interface for authors to see/review all new comments.	Community features	UC5
FR11	Rate artifacts	Logged in users need to be able to rate artifacts on a one to five star scale. Ratings should be visible to all users who can view the artifact.	Community features	UC12
FR12	Recommend articles	Visitors should be able to recommend articles via e-mail or social media. Registered users should also be able to recommend articles using predefined SMS messages.	Community features and Mobile phone (SMS) integration	UC10
FR13	Send newsletters	Authors must be able the send personalized newsletters to users via e-mail and SMS. Recipients need the ability to unsubscribe.	Easy extensibility and Mobile phone (SMS) integration	UC19
FR14	Retrieve personalized information	The system should use the name of the user to greet them and should provide personalized recommendations to users logged in (artifacts and events) on the start page and in newsletters.	Community features, Mobile phone (SMS) integration and Easy extensibility	UC4
FR15	Add, edit and manage pages/articles	The system must allow the management of articles and pages by authors. Authors should be able to use templates and select different optical layouts for specific articles. Editing of the articles should be done using a WYSIWYG editor which allows to hyperlink other articles easily. The CMS must allow articles to be structured in a hierarchy (in order to reflect the topics of the event series).	Content management system	UC16
FR16	Add, edit and manage photo galleries	The system must allow the management of photos and photo galleries by authors. Photos of the galleries should be usable using the CMS module in order to hyperlink or include them in articles easily. The galleries need to be structured in a hierarchy (in order to reflect event series and concrete events).	Content management system	UC16
FR17	View and manage interactive quizzes	The platform should provide interactive quizzes (e.g., in the form of self-tests) for registered users. This also includes authoring functionality for authors.	Easy extensibility	UC16
FR18	Tag contents	Authors need the ability to tag artifacts in order to link similar artifacts and providing a structure regarding different aspects (based on tags) independently to the hierarchical structure.	Content management system	UC15
FR19	Submit articles/photos	Logged in users should be able to submit photos and articles. Submitted articles should be inserted into the CMS and marked for review for authors. Same applies to photos.	Content management system and Easy extensibility	UC11
FR20	Define visibility/accessibility of contents	Authors must be able to define visibility states (published/under-review state) and accessibility restrictions for anonymous visitors. This includes that links to artifacts which are not accessible are visible and marked with a lock symbol. If such a link is clicked on, the system should provide a special page which contains the advantages of registering, a link to the registration page and a log in form for registered users. Artifacts in the under-review state must be completely invisible to all users despite the editors.	Content management	UC3, UC3.1
FR21	View public list of partners	A list of partners with links to their corresponding profiles must be visible to all visitors.	Easy extensibility	UC2
FR22	Manage offline events	The system must be able to add and edit event series and concrete events (i.e., location, date and time) in order to display it in a structured way. This also includes the ability to enter attendance lists with the platform (i.e., which registered user attended which events).	Easy extensibility	UC17
FR23	Retrieve (real-time) statistics	For continuous feedback and evaluation reasons the system needs to present detailed statistics. This includes statistics about ages of the users, ratings, comments, visit durations, number of read articles (also differentiated between parents who visited a corresponding event or not), number of events attended, distances of parent’s locations of attended events, number of registered user by event location, numbers of parents (total, who visited an event, who live in the district of Goslar, etc.) and partners, information about the timing and order of visiting an event and registering online, number of internal messages sent or friends invited, and reactions/clicks to/on e-mail and SMS campaigns.	Advanced logging and tracking and Easy extensibility	UC20
FR24	Log and track user behavior	The system needs to log errors and collect data about the usage of the platform for statistical evaluations (closely related to FR1, FR3, FR6, FR7, FR9-14, FR22 and FR23).	Advanced logging and tracking	UC20

Table 2. Non-functional requirements.

No.	Title	Short Description
NFR1	Extensibility	System must be modular and has to provide application programming interfaces (e.g., for adding new features/modules and for inter module communication).
NFR2	Permissive license	We need the right to edit/modify the source code of the system.
NFR3	Privacy	The system must comply with German privacy laws and provide low threshold access with nicknames (closely related to FR1, FR7 and FR8).
NFR4	Security	The system must be properly designed and implemented with regards to security (e.g., it needs to be resistant against cross-site scripting, SQL injection, session hijacking and other attack vectors of web-based systems).
NFR5	Usability/optics	The usability and optics of the community platform must be adequate for the target group.
NFR6	Interoperability	The web-based system needs to be compatible with the different wide-spread browsers on desktop and mobile devices.

Table 2. Non-functional requirements.

No.	Title	Short Description
NFR1	Extensibility	System must be modular and has to provide application programming interfaces (e.g., for adding new features/modules and for inter module communication).
NFR2	Permissive license	We need the right to edit/modify the source code of the system.
NFR3	Privacy	The system must comply with German privacy laws and provide low threshold access with nicknames (closely related to FR1, FR7 and FR8).
NFR4	Security	The system must be properly designed and implemented with regards to security (e.g., it needs to be resistant against cross-site scripting, SQL injection, session hijacking and other attack vectors of web-based systems).
NFR5	Usability/optics	The usability and optics of the community platform must be adequate for the target group.
NFR6	Interoperability	The web-based system needs to be compatible with the different wide-spread browsers on desktop and mobile devices.

4. Designing the Socio-Technical System

In the first part of this section the design process and approaches employed are described. We then elaborate on (initial) design challenges and gained insights which resulted in changes to both the online platform and offline events over time.

4.1. Design Process

The design process employed a participatory action research approach [34] and agile software development methods [35]. Being a stakeholder of the implementation of our approach ourselves, participatory action research gave us a framework at hand for structured research. Having short cycles of feedback allowed us to analyze the current situation, implement new ideas, and reflect on the outcomes in a timely manner. This implies that the global process did not follow a strict classical linear software development process from requirements engineering over architecture design, detailed design, to implementation, quality assurance and deployment with a sequence of fixed releases. Also, there was no predefined fixed plan describing how and when a new feature would be implemented. Instead we followed the principles of the development of Web 2.0 applications (incremental prototyping) where the priorities of changes are based on user feedback and current needs with regard to the Mobile2Learn approach. This approach of continuous modification and integration of new features in quite short cycles is common for (social) web applications (e.g., there is no Google or Facebook version 1.4). It helps to stick to the real needs of the users, instead of building a fixed predefined product. Note, however, that following these principles does not mean that no steps of the classical software development process are applied. Each cycle included the steps requirements analysis, design, implementation and test (see Figure 3; the backward arrow symbolizes the iterative aspect of our process).

Our agile design process was not limited to the design and development of the software, but was also used for the offline events and their planning. In case of the offline events we chose a nested approach: Some events for a topic took place in a series several times at different locations. Here, a reflection phase was conducted after each event as well as at the end of the series (i.e., the test phase in the software development process; see Figure 4). This way, we were able to react on issues which arose and could develop strategies to improve the following events (e.g., wrong assumptions about the ages of attending children). For each new event series, a new iteration of the global cycle for planning was started. However, in the nested cycle no global changes to the fixed topic of the series were made.

Figure 3. Flow diagram depicting the software development process cycle.

Figure 3. Flow diagram depicting the software development process cycle.

Figure 4. Flow diagram depicting the event series development process cycle.

Figure 4. Flow diagram depicting the event series development process cycle.

Even if our global process did not follow a classical linear software development process, the first cycle was special in terms of length and depth of the initial system design (i.e., the selection of a proper system or web framework as a basis for the community platform based on the functional requirements; cf. Section 4.2). The first cycle included the initial development of the described approach and implementing a first “version” (which did not fulfill all functional requirements, but the central ones: Basic functions (requirements FR1, FR3-5 as of Table 1), CMS (FR15, FR18, FR20), mobile phone integration (FR1, FR3, FR4), basic community features (FR6-12), support for the different roles (FR1, FR7, FR8, FR21), advanced logging (FR24) and offline registration (FR2)) of the online platform as well as plans for the first event series. Therefore, the first cycle was the longest one and took seven months.

Further iterative shorter cycles followed. In these, we added new features to the online platform, changed the functionality based on user feedback, and gained experience. We also changed some aspects of the offline events. Based on the hybrid approach, feedback for the online platform could be (and was frequently) gathered in face-to-face events as well as vice versa.

4.2. Design Challenges and Changes over Time

In the first development cycle, the main (technical) design challenge was to build the online platform. The usage of existing social networks as Facebook, MySpace, or meinVZ (German Facebook clone) directly or via integrated apps was not an option due to a lack of control (especially regarding logging and limited options for extendibility) and privacy issues (cf. Section 2).

Instead of developing a full system from scratch, though, we intended to use an existing system and extend it for our needs. A detailed requirements/features matrix is not provided here, since our initial systems survey was conducted in 2010 and all systems and available modules evolved since then (see [36,37] for a more recent comparison). It is not just that the richness of features is an important factor, also the license and architecture of system matters in terms of extensibility (cf. NFR1, NFR2). A system should also include a global artifact concept so that artifacts (like articles, photo galleries, or quizzes) provided by (different) extensions/modules can be used across modules, e.g., articles of the CMS, pictures managed by a photo gallery module, and quizzes of a quiz module can be commented on or found by a global search module.

During the time of our system review, several different kinds of potentially suitable systems existed: content management-systems (CMS; we subsume blogging software into this category), wikis, generic web frameworks, bulletin boards, and social network engines. The following list is not intended to be exhaustive but should give a rough overview:

• CMS: Concrete5, Drupal, Joomla, Plone, Typo3, Contao (renamed from TypoLight in May 2010), WordPress
• Wikis: MediaWiki, DokuWiki, MoinMoin
• Generic web frameworks: XOOPS, Zikula (based on phpNuke)
• Bulletin boards (discussion forums): phpBB, yaBB!
• Social network engines: Dolphin, elgg, phpFox, SocialEngine

Mapping these different system types to the clustered technical requirements (cf. Section 3.2) gives the following results: Community features are best supported by social network engines. Bulletin boards are also often used for community support. There are also (third party) plugins available for some CMS. Sophisticated CMS functionality is best supported by systems specially built for this: CMS or CMS modules which are available for some generic web frameworks. Some wikis can also implement parts of the requirements by using namespaces. Bulletin boards typically neither have support for CMS functionality nor for extensions in this direction. Mobile phone integration is not available in any system type. Thus, this has to be seen as part of the requirement Easy extensibility. Enhanced privacy options are often based on a sophisticated rights management which is best implemented in generic web frameworks: A lot of frameworks provide a generic rights management architecture. This can then be used across the whole framework and modules. Support for different user roles is often limited to a fixed set of roles (e.g., admin and normal user) or based on group memberships (in combination with the rights management). A clear-cut statement for any of the mentioned system types is not possible due to the variety of implementations within the system types. Logging can partly be implemented by web server logs; hence, it is independent of the used system type. Concerning other aspects of advanced logging, no general judgment is possible since this depends on how much logging and tracking functionality is included in a concrete system. Easy extensibility is best provided by generic web frameworks which were especially developed regarding this aspect—they also often provide a global artifact concept for that reason. Some CMS and social network engines can also be extended easily. However, a global artifact concept is sometimes missing. Wikis and bulletin boards often only have limited extendibility (e.g., only new content types for artifacts/posts).

Table 3 contains a compressed overview. Plus or minus signs indicate that a specific requirement is well (or not well) supported by a system type. A plus surrounded by parenthesis means that this is requirement/feature is provided for some concrete systems in the form of extensions.

Table 3. Requirements/features provided by system types.

	CMS	Wikis	Generic Web Frameworks	Bulletin Boards	Social Network Engines
Basic functions	provided by all system types
Community features	(+)	−	(+)	(+)	+
Content management system	+	+/-	(+)	−	−
Mobile phone (SMS) integration	−	−	−	−	−
Privacy options and sophisticated rights management	+/−	−	+	−	+/−
Support for different user roles	no general judgment possible
Advanced logging and tracking	no general judgment possible
Easy extensibility	+/−	−	+	−	+/−

Table 3. Requirements/features provided by system types.

	CMS	Wikis	Generic Web Frameworks	Bulletin Boards	Social Network Engines
Basic functions	provided by all system types
Community features	(+)	−	(+)	(+)	+
Content management system	+	+/-	(+)	−	−
Mobile phone (SMS) integration	−	−	−	−	−
Privacy options and sophisticated rights management	+/−	−	+	−	+/−
Support for different user roles	no general judgment possible
Advanced logging and tracking	no general judgment possible
Easy extensibility	+/−	−	+	−	+/−

No system (type) fulfilled all requirements out of the box. Bulletin boards, wikis, and social network engines were ruled out because those did not contain a sophisticated CMS module or there was no such extension available. A sophisticated CMS seemed to be too complex to implement in a timely manner. Social network engines provided lots of functionality that was not needed in our application scenario (e.g., video chats, URL like features) but which often could not be turned off. Plain CMS systems are often back-end based (for all configuration) and do not provide proper community functionality. Thus, the focus lay on generic web frameworks which also often include a sophisticated artifact concept. We finally chose the Zikula framework (in version 1.2; [38]) because it fulfilled most requirements at the time of our system comparison. Zikula is a GPLv2 licensed PHP-based web application framework which implements the web variant of the Model View Controller (MVC) (NFR2). The core of Zikula provides a generic search function, options to define different themes/layouts and a number of application programming interfaces (API, e.g., database abstraction via object relational mappings, data access objects, HTML form validators, session management, internationalization, security manager, etc.; NFR1, NFR3, NFR4). New modules can easily be plugged into the framework. Therefore, the framework provides an API for inter-module communication (e.g., the search or the recommendation module can access articles of the CMS or the photo gallery module; NFR1).

Figure 5. General architecture of the Mobile2Learn web platform.

Figure 5. General architecture of the Mobile2Learn web platform.

The global architecture of the system is relatively typical for a web-based system (cf. Figure 5). It includes the Zikula framework as the core component (including provided and newly developed modules), a database management system (MySQL server) as well as an SMS gateway (cf. Mobile phone (SMS) integration requirement) and a mail server (for sending welcome e-mails, notifications, and newsletters). Users use their computers or mobile devices in order to access the Mobile2learn community platform (via HTTP or HTTPS) and read received e-mails. SMS messages are pushed to mobile (smart)phones.

The user interface (i.e., the layout) of the Mobile2Learn platform was designed with regard to the target group (cf., left side of Figure 1) by an experienced web designer (NFR5) and was then optimized for wide-spread browsers (Firefox, Internet Explorer 6.0+, Safari, Opera and Chrome; NFR6).

Further development cycles are not explained in as much detail as the first cycle in this paper. Instead, we describe interesting challenges and developments that occurred during these cycles of socio-technical system design. We begin with the “offline perspective”.

Several changes to the events and their structure were applied during the project. During the first events, an “internet station” was available. We set up a table, a laptop with internet access and computer projector, and posters describing the online platform in a separate room during the event. There, we explained the online platform to parents and answered questions about it. Assisted registration on the online platform was also provided. Small adaptions to this procedure were applied after several cycles: After the first event we noticed that not all parents visited all activities (including the internet station) we presented on that event. So we created a “collector card” for all children where a stamp for visiting an activity (including the internet station) was provided. This resulted in a major incentive for the children to visit all activities and, thus, collect all stamps. The next change was to provide a kid’s corner (with games etc.) near to the Internet station so that parents had more chances to concentrate on the explanations. Finally, however, we decided based on the attendance and observations of the internet station that such a station did not fit into all events and parents could also explore the platform online on their own (see evaluation section for more details). So we replaced it by posters we put up and teaser cards (advertising flyers in the size of business cards with the URL of the online platform on it) we gave to parents.

The first events targeted parents with children of a specific age only. While potentially beneficial for targeting the event to the children, it turned out that this assumption was problematic since some parents have multiple children at different ages. Those parents did not want to find a baby sitter for one child just for attending an event with the other child—instead, parents attended with all their children.

Another notable change concerned the way events and the information about the events was developed. For the first event series, the online articles were published by a project team member before the events. This was mainly due to the fact that the web platform went online before the first events took place (on purpose—since the online platform was expected to increase attendance of the events). For the other event series, hired external lecturers developed and held the events first. The creation of the articles about the events on the web platform was then done after the event sequence was completed.

We also made changes to the online platform. Offline registration (FR2) was possible, however, it was never really widely used. It turned out that this way of registration was not practical since it caused additional work involving the collection of the registration forms and entering the information into the web platform.

An early “version” of the online platform required e-mail addresses to be confirmed in a challenge-response process where the system sent an e-mail containing a link to activate the account and validate the e-mail address (FR1). Based on feedback we gathered during events, parents reported that this process was too difficult (for various reasons, e.g., Greylisting [39]). A high number of non-activated registrations confirmed this. Thus, we changed the process to not require activation, but include an explicit contact address in the welcome mails for reporting abuse. Existing unconfirmed accounts were activated after sending the welcome mail—no abuse reports were received.

After some days, however, we noticed several non-delivery notifications [40] caused by welcome messages and invalid e-mail addresses entered. Most of the time this was based on typos, only 2 fake addresses seemed to have been used on purpose. Since the accounts were activated without any check, it was possible for the users to login to the online system but not to receive any e-mails. We were able to mitigate this issue by integrating a small SMTP client into the registration process [41]. This client connects to the mail exchange (MX server) of the entered domain and initiates an SMTP session in order validate the e-mail address (by using the address as RCPT-TO argument). If the server replies with a permanent error (ignoring temporary errors which are often caused by Greylisting) we assume that the e-mail address does not exist or is invalid. In this case, the registration form is redisplayed with all other data prefilled in and pointing out that there is a problem with the mail address—no false positives or false negatives were observed so far.

Other notable early integrations were the SMS and e-mail newsletter module (by the middle of November 2010; FR13) and the photo gallery included just after the first events took place (by the middle of December 2010; FR16). Support for interactive quizzes (FR17), management of offline events (FR22), statistics (FR23) and submission of parent’s articles (FR19) was added around mid-2011.

Another central challenge was how to motivate parents to register and read articles. We introduced a so-called “article of the week” which was linked directly from the home page and ensured that this article is publicly available in that week. This highlighted article served as an incentive for unregistered parents to register and also as a starting point for other articles for registered parents. Parent’s reactions were not overwhelming. However, once we put the photos taken on the events on the website and announced this in the kindergartens, this seemed to be a major incentive for parents to register (based on parent’s comments). On August 25th (2011), we send letters to all 156 parents who attended an event but did not register on the platform. In this letter, we advertised the online platform and emphasized that the pictures of all the events were available now. Within 14 days, there were 11 new registrations (cf. Figure 6). We also performed different steps and development cycles: In order to stay in close contact with the community, we increased the frequency of the SMS and e-mail newsletters to two weeks. Results are described in the next section in more detail. We also noticed the need for regularly published new articles to motivate registered parents to revisit the community website independently of the newsletters. As a consequence, we built a partnership with a local child care worker school. Students had to develop concepts and learning materials for their own learning there. Based on this partnership, a win-win situation could be established as their developed material could be used in a real scenario. Also, a special recommendation system was implemented which automatically generates personalized recommendations (FR14). Recommendations for events, photo galleries and articles were included on the homepage (for registered users) and in all e-mail campaigns. Based on the reading behavior, ratings given by a user, and events attended, articles and photo galleries were recommended. Also, recommendations for upcoming events were generated depending on the residence of the user and already visited events. Using this approach, high quality recommendations could be generated and the average number of articles read per user could be raised [42].

Figure 6. Usage graph of registered users of the online platform correlated to campaigns and events.

Figure 6. Usage graph of registered users of the online platform correlated to campaigns and events.

5. The Mobile2Learn Hybrid Parent Community after One Year of Usage

Mobile2Learn is a small parent community which is based on the proposed hybrid community approach. It focuses on general early childhood education topics. The Mobile2Learn project was started by the community college Goslar (an institution for rural parent education) and Clausthal University of Technology in Germany. The online community platform was launched on November 1st 2010 with a basic feature set which fulfilled the majority of all requirements. At this date, a small number of 30 articles were available on that website. The first face-to-face event took place on November 3rd 2010—further events followed regularly. Even if the project was aimed at reaching underprivileged parents, the community website and the face-to-face events were advertised and accessible for all parents without any costs or fees. The project (funding) ended in February 2012. However, the online community platform is still available, a few members of the team still work for the community on a voluntary basis, and the community college Goslar offered further events also after the funding period (cf. Figure 6).

The educational activities were structured into six areas (e.g., “learning with all senses”, musical education, nature discovery, and “speaking and listening”; based on a guideline of the state of Lower Saxony, Germany). For each area (except “nature discovery”), six different regional kindergartens in the district of Goslar were chosen where thematically related events were conducted. All parents were invited to attend (not only parents whose children attend the facility hosting the event). While focusing on parents, the events/trainings were designed in a fashion that parents could attend along with their children. For the area “nature discovery”, the events took place at a farm and an adventure playground near to a forest. For evaluation reasons, some locations were visited several times and others not. The goal was to investigate if recurring event locations are necessary for community building processes in the context of hybrid communities (cf. Section 6.3).

As already mentioned, the online platform provides educational articles, photo galleries, and interactive quizzes. Photos taken during events and articles about the contents of the events were put online en bloc once all events of the regarding thematic series had taken place (except for the first thematic series where most material was published online before the events started). Ratings of all articles and photo galleries with one to five stars and commenting by (registered) community members was possible. In order to access all features, users had to register. Registering required entering an e-mail-address, and/or a mobile phone number, nickname, date of birth, gender, and residence. The majority of the articles on the online platform were created by pedagogues, the hired lectures, and project team members, but also a few parents submitted draft articles and photos (less than 10% of the user base, which corresponds to “typical” community behavior, cf. user pyramid in [14]). These were reviewed by pedagogues of the Mobile2Learn team before publication.

Regular personalized messages sent to parents via SMS and e-mail newsletters turned out to be a factor of key importance for our approach. These messages called campaigns were sent approximately every other week (between April 2011 and February 2012) and informed parents about (new) articles, pictures, and upcoming events. E-mail newsletters often contained preview thumbnails and deep links directly to advertised articles. SMS messages, however, had to be much shorter (max. 160 chars). Thus, these contained a short message with appeal character (e.g., “Hello John Doe, try out our new indoor game ideas for rainy days! Check out Mobile2Learn.de”) and the URL to the community platform in order to motivate parents to become active. Starting from July 2011, automatically generated personalized recommendations were provided to parents on the homepage (for registered users) and in all e-mail campaigns. This direct and repetitive way of contacting community members was chosen to continuously and actively “push” information about educational opportunities to parents. This way, parents were regularly reminded that the project still exists and could easily access all new and “interesting” items.

While the long-term practical goal of the Mobile2Learn project was to build a self-supporting and self-organized learning community about early childhood education where parents get active, help each other, and provide new contents for the platform (cf. [14,17,31,32,33]), the more specific main research hypothesis investigated in the remainder of this paper is that (H1) the hybrid community approach works better than any of its two components alone. This main hypothesis can be broken down into several sub-hypotheses: (H2) The majority of the community members will live in the district of Goslar but (due to the hybrid approach) there will also be other members; (H3) parents registered in the online community will attend more face-to-face events than non-registered parents; (H4) regular SMS and e-mail campaigns are vital for the community, and (H5) the hybrid approach brings synergy effects in the sense that face-to-face events promote the online platform and vice versa. The main hypothesis (H1) is directly based on the goal(s) of the presented approach (cf. Section 3)—in particular, it takes into account that reaching (underprivileged) parents requires many different channels [9]. Our literature review (cf. Section 2) suggests that existing hybrid communities are often regionally bound and sometimes restricted to specific users [12,19,25,26]; however, existing parent community platforms are not—H2 relates to this. Our hypotheses H3 and H5 are inspired by user binding models [12,13,18,30] and advertisement effects of the intertwined offline and online aspects [19,21]. Research findings on communication styles and methods, especially push based communication, in (online) communities give a foundation for H4 [16,26,29].

6. Evaluation

In this section, we first give an overview of our data gathering methods, the community structure, the participation in the face-to-face events and the usage of the online platform. After that, we come back to our five research hypotheses.

Since development was performed iteratively over the whole project (i.e., funding) period, there were no distinct design and evaluation phases. The evaluation was not conducted on a fixed system version, but was done on a smoothly changing system. This evaluation approach allows us to spot some interesting effects of changes we made during the project in the data.

For our evaluation, we collected data from several sources. We analyzed the normalized log files from the webserver of the online platform (search engines, crawlers and visits of the project team were excluded), clicks on links in newsletters, and attendance lists of face-to-face events (these paper-based lists were synchronized with the database regularly). After face-to-face events, small questionnaires were conducted by putting questions on a poster and allowing the attending parents to pin stickers on designated areas which reflect their opinions on these questions. This approach enabled us to get feedback of almost all attending parents quickly in a relatively anonymous setting. In addition, at the end of the project funding period we conducted a final paper-based questionnaire including all parents with a valid postal address. This anonymous questionnaire was sent to 478 persons by postal mail together with a stamped return envelope. We received 84 answers (17.6% return rate). In our analysis, we focus on the data from within the funding period; however, we will also give some results about the time afterwards.

At the end of the funding period, the total parent community consisted of 505 parents who got into contact with the Mobile2Learn project—including both online users and offline users (i.e., persons who attended events but never registered online). 234 of these registered on the online platform (46%). Even if this is a small community, these numbers have to be seen in the light that the district of Goslar only has 142,000 inhabitants (of which only a fraction has small kids) and is thus rather small, too.

6.1. Face-to-Face Events

During the project, 30 face-to-face events were conducted (workshops, trainings, etc.). On average, 14 parents (with 18 children) took part in each event. In total, 369 parents (73% of total community) took part in at least one event. Sixty-three of these attended at least two events, and 15 attended at least three events.

The average distance between the residences of the attendees and the event locations was 4.23 km (sd = 4.18 km). If we exclude the topic “nature discovery” where the events took place on two farms and in nearby forests, the mean distance was smaller: 3.47 km (sd = 3.92 km). The expected regional focus of the community can be observed here. However, this is rather unsurprising since parents would rarely drive a long distance just for attending an early childhood education training event.

As already mentioned, we conducted a small questionnaire after each event using stickers. We asked the parents if they liked the event (ratings possible from 1, disliked, to 5, liked) and if they would recommend it. For 9 of the 30 events, only the best possible ratings were given. Only for 3 events, some ratings were below a score of 3. However, no event got an average rating of worse than 3.4. Also, all parents (except two) stated that they would recommend the events. The results of the anonymous mail questionnaire confirm this: Approximately 50% rated the events with the best score, and 25% with the second best. Overall, this data (subjective statements and attendance of multiple events) indicates that the attending parents seemed to have enjoyed the educational events.

6.2. Online Community Platform

In total, 182 educational articles (plus 14 articles by partners), 16 administrative pages (like recommendations, news, “About us”, legal notes, upcoming and past events), and 6 quizzes with 28 questions were created and published on the online platform (as of September 2012). In order to help parents find resources easily, the articles were organized in a tree structure where the main branches reflect the six thematic areas of early childhood education addressed in the project. Additionally, 51 photo galleries (one gallery for face-to-face event plus several additional thematic galleries) containing approximately 3000 photos were available on the platform.

On average, each registered user visited the online platform 4.3 times and read 9.8 educational articles. The average visit duration was approximately 8 min, while 77% of all visits lasted longer than 2 min and 51% lasted between 2 and 15 min (cf. Table 4). As these times are based on the webserver log file, these numbers describe the durations from the first to the last page access and, thus, cannot measure the time spent on the last accessed page—as such, the numbers underestimate the actual access time. Sixty-six articles were rated by community members (scale from 1, dislike, to 5, like) with an average rating of 4.55. In the mail questionnaire, community members were also asked if they used the online platform and how they liked it: 14 parents said that they did not use the platform (17% of 84 respondents), 25 parents (30%) gave the best rating of 5, 20 parents (24%) a rating of 4, and further 16 parents (19%) a rating of 3. Concluding, we can state that overall, community members spent considerable time on the platform (they did not just scan it), and that the subjective opinions about the platform were largely positive.

Table 4. Visit durations of registered users on the online platform.

Visit Duration	#	Per cent (n = 1008)
0 s to 30 s	111	11
30 s to 1 min	86	9
1 min to 2 min	128	13
2 min to 5 min	265	26
5 min to 15 min	255	25
15 min to 30 min	110	11
30 min to 1 h	45	4
1 h+	8	1

Table 4. Visit durations of registered users on the online platform.

Visit Duration	#	Per cent (n = 1008)
0 s to 30 s	111	11
30 s to 1 min	86	9
1 min to 2 min	128	13
2 min to 5 min	265	26
5 min to 15 min	255	25
15 min to 30 min	110	11
30 min to 1 h	45	4
1 h+	8	1

During the project funding period, 19 campaigns (via SMS and e-mail) were conducted. The links in the e-mail newsletters were clicked on 445 times (counting one click per user and newsletter) by 147 different users. Click rates vary between 5% and 30%, with an average of 14%. The reaction times on the campaign newsletters differed considerably. On average, the duration between sending the newsletter and clicking on a link was 93.3 h (approx. 4 days). However, the variance was extremely large here: The majority (80%) of the clicks occurred within the first few hours.

Figure 6 depicts the community platform access and the number of registered users on the online platform (vertical axis) over time (horizontal axis): The bars show the number of visits on a specific date (scale: left vertical axis). The line represents the total number of registered users on a specific date (scale: right vertical axis). Additionally, the figure contains markers for dates where face-to-face events (marked by “E”; dashed lines) and campaigns (marked by “C”; dotted lines) were conducted.

The bars in the usage graph show that the online platform was continuously accessed over the project funding period (November 2010 to February 2012). Also, a steady increase of the user base is observable (upper line in the graph). However, the graph also shows that there are periods where no new users registered. A detailed examination showed that very likely, circumstances like weather and school vacations seemed to have had an impact on registrations and the usage of the online platform: At the end of May and beginning of July 2011, there was a heat period in Germany which might have caused fewer registrations during that period. School vacations in the region of Goslar were at the end of December to end of the first week of January (2010/2011), end of April (2011), from July to the second week of August (2011), as well as at the end of October (2011). Correspondingly, Figure 6 shows that no new registrations are visible for July, August and October (2011) and that in December (2011), fewer registrations are recognizable. Also, after the end of the project funding period (which meant that fewer new articles were posted online by team members and that events were not conducted regularly any more), there were significantly fewer site visits and newly registered users (see discussion section).

6.3. Hypotheses Evaluation

In order to evaluate our research hypothesis H2, we analyzed the residence locations of the users. Figure 7 shows the spatial distribution of the members of the Mobile2Learn community. In the figure, light icons symbolize users who attended at least one face-to-face event but who were not registered online. Dark icons symbolize users who were registered online. Users annotated by an “@” symbol were only registered online but did not attend any events, and an asterisk symbolizes that this user attended more than one event. As is visible in the figure, members of the online community were distributed across Germany (left side). However, despite this spread, there still was a clear cluster of users in the district of Goslar which was the regional focus of the Mobile2Learn community. Four hundred and thirty eight of all 505 parents (87%) and 178 of the users who registered online (76%) originate from the district of Goslar—only 39 parents (8%) have a distance of more than 50 km to Goslar. On the right side of Figure 7, a detailed view of the focus area is provided, with the district of Goslar highlighted. It is noticeable that most community members are located here. Nevertheless, members are not homogenously distributed within this area: There are about eleven clusters but no members in the south. A deeper analysis yielded that the locations of these clusters precisely correlate with the locations where the face-to-face events took place. Consequently, in the south of the district (where no events took place), there are no clusters. Overall, our hypothesis H2 is confirmed: the majority of the Mobile2Learn community members originate from the district of Goslar (and, even more, from the parts within the district where the face-to-face events were held), but there still was some spread of the community across Germany, possibly explained by the online aspects of the community.

Figure 7. Distribution of registered users of the online platform.

Figure 7. Distribution of registered users of the online platform.

To evaluate our research hypothesis H3, we analyzed how often parents attended events, taking into account the information whether they were registered online or not. Due to the small sample size, it was not possible to statistically support or falsify our hypothesis that parents who were registered online attend more events than parents not registered on the online platform. Yet, the numbers show a tendency in favor of the hypothesis: Parents without an online membership visited 1.1 events on average (247 of the 271 offline members attended one event, 23 parents visited two events, and 1 parent three events). In comparison, parents who were registered online attended 0.9 events on average—while 136 parents of the 234 online users did not visit any events at all, for instance, if they lived far away from Goslar. At first sight, this data seems to be contradicting to our hypothesis, but the comparison is of course unfair. If we calculate the mean of all online community members who visited at least one event (which seems to be a fair comparison to the “offline community members” reported on before, since the latter also attended at least one event), the average number of attended events is 1.7: 59 parents visited one event, 25 parents attended two events, 7 parents visited three events, 4 parents went to five events, and two parents attended six events.

Examining the visits of the online platform in more detail (cf. “C” columns and peaks in Figure 6), a strong correlation between the campaign dates and the visitor peaks becomes visible. Without the campaigns, the online platform would probably have been accessed much less frequently. This usage pattern (together with the results on click rates and reaction times from above) can be seen as an indication that members of the target group were reachable by SMS and/or e-mail campaigns. Is also confirms our hypothesis H4: periodic newsletters/campaigns can have a measurable effect on the actions of members of the learning community.

The core idea of the hybrid community approach is that real-life events promote the online platform and vice versa. We hypothesized that synergy effects would evolve (H5). In total, 98 parents (19% of the total community) registered online and visited at least one event. In addition, 26 parents (27% of the registered online users) registered online before they attended a face-to-face event. 20 of these 26 parents registered more than one month before their first attendance of a face-to-face event, with many of them accessing information material (e.g., a photo gallery) about a past event online before attending an event themselves. It is very likely that these parents were motivated to attend a face-to-face event through the online platform.

On average, parents who registered online after attending an event did so 30 days after their last attendance (with 10 parents registering on the event day from home). Forty-nine parents registered online after their first event attendance, seven parents after two and one parent after having attended three events. A more “direct” approach for having parents become active in the online community did not work, however: In the first events, an internet station was available where the online platform was demonstrated and where and parents could register online immediately. Nineteen parents did so. However, two entered an invalid e-mail-address (thus their account was never activated), and the other 17 were considerably less active than the average user in the system. A reason for this might be that the parents who registered online during an event did that just for politeness reasons.

Looking at Figure 6 again, a direct correlation between dates of face-to-face events and online registrations is not visible. At the beginning of the project and after some specific events, increases of the number of registered users are observable. However, there are also visible increases which seem to be unrelated to events. However, even if the data does not support a direct correlation, the statistics also show that the number of registered users seemed to be more or less constant after the end of the funding period (i.e., after the last events), but increased again in September 2012 when a new event took place. As such, the face-to-face events (yet not their specific timing) seemed to have had an impact on the use of the online platform.

We also investigated which kinds of articles or photo galleries were accessed by parents who attended an event: 32% of the registered users accessed articles related to the thematic area of the event they visited. Yet, 60% read articles belonging to other thematic areas. Also, 9% of the users only read articles belonging to visited events, and 38% of the users only read articles which belong to non-visited events. Photo galleries of face-to-face events were accessed by 131 parents (56% of the online members). Sixty-seven parents visited a photo gallery of an event they attended (68% of the online users who attended this event). Ninety-seven parents (86 from the district of Goslar) accessed photo galleries of non-visited events. Moreover, 45 parents from the district of Goslar (54% of the online users without visited events) accessed at least one photo gallery of an event but did not attend any event. Overall, this data shows that there was quite some interest in photos and educational articles. Especially for the articles, we can state that the parents in the community did not just access articles related to events they visited, but also retrieved articles of not visited ones. As such, the hybrid approach worked in the sense that parents accessed more (and different) material online than what they experienced face-to-face. Overall, the results thus confirm our research hypothesis H5.

Based on all these results, our main hypothesis (H1) that the hybrid community approach works better than any of its two components alone can largely be confirmed. All in all, 505 parents were reached. 271 only attended “offline” events, and 136 (83 parents from the district of Goslar) only registered online and used the online platform. Without the hybrid approach we would have reached just one of these two groups at maximum. Besides that, the regional focus led to several synergy effects.

7. Discussion

As stated, one of the project goals was to reach also underprivileged parents as a special target group. However, operationalizing the term “underprivileged” and measuring corresponding data is hard (e.g., for privacy reasons). Asking parents upon registration or in a questionnaire if they were underprivileged was not an option, either. Also, based on the collected data (names and residence) no distinction is possible (German privacy law forbids merging of different databases). So we asked kindergarten staff if they spotted parents during events who could be underprivileged or who normally did not attend training events and report this to us in an anonymized fashion. Some staff reported that they did so, however, these statements were very subjective by nature, and they were only possible for parents that the staff knew. In our mail questionnaire, we asked the parents for their highest school degree: Only 10 parents (8% of questionnaire respondents) stated having the lowest school degree. Nevertheless, this result needs to be interpreted with some caution, since parents of the special target group might tend to give feedback less frequently than others. Finally, as part of the mail questionnaire, we asked all parents if they had taken part in other educational events or workshops prior to Mobile2Learn. Here, 51 parents (61%) answered that had not done so. We got a similar result in the small questionnaires after the events: Here, about 50% of the parents stated that they had not attended a similar parent training before. While all this information does certainly not count as hard evidence that underprivileged parents were part of the community, it at least is some support for the hypothesis that parents were reached who had not been reached before.

Higher-level questions are whether Mobile2Learn has helped the parents and whether Mobile2Learn has improved the education of the children in a more holistic sense. These general questions are hard to answer by nature. In the small questionnaire at the end of the events we asked the participating parents whether they got new ideas during the event and whether they planned to try some of these at home. The parents confirmed this, answering with a median rating of 2 for both questions (on a scale from 1 to 5 with 1 = strongly agree, and = 5 strongly disagree; see diagrams in Figure 8). There were only 5 resp. 4 events where parents voted with a rating of 4 and 5. However, this does not indicate that these parents did not find the presented contents of the specific event useful, but it could also mean that they already knew them. Further investigations were not possible during the time frame of the project, so that questions which require a longer lasting research methodology (e.g., whether the positive impressions had a lasting effect) cannot be answered.

Figure 8. Parent’s answers to questionnaires (1 = strongly agree, 5 = strongly disagree).

Figure 8. Parent’s answers to questionnaires (1 = strongly agree, 5 = strongly disagree).

Even though parents frequently indicated interest in the Mobile2Learn project and said that they liked the option of receiving educational tips via SMS, they rarely entered their mobile phone number (78 of 234 parents; 33%). On events, parents provided their number after a special explanation. This might be related to privacy concerns. However, there were also seven persons (3%) who only registered with a mobile phone number (i.e., no e-mail-address was entered).

The functionalities for internal messages and the forums were not used extensively. Also, only few articles or photos were submitted by users. Yet, the functionality for adding comments to pages, articles and photos was used frequently. Note, though, that an analysis of communication within the community needs to be done with care, taking into account that possibly a considerable amount of communication between parents likely took part in a “classical way” during the face-to-face events—a characteristic element of the hybrid community approach.

The online community development after the end of the funding period yields some interesting insights. After February 2012, it was not clear if further events could be funded. So, there was a period of about six months in which no face-to-face events were conducted and no campaign mails or SMS were sent out. The online platform was not shut down, though (cf. Figure 6). In this period, almost no new users registered, and the number of visits decreased significantly. In September 2012, new funding for some events became available, and the first “new” event was held, together with an announcement campaign about one week before. While Figure 6 clearly shows that the relatively small online community was not “self-sustaining” after one year, it also shows that the community could be “revived”: The pattern of peaks after campaigns occurred again, and also the number of website visits and registrations seemed to increase again until the event sequence was over.

Some events required prior registration for management reasons and space limitations. For such events taking place in kindergartens, we put up a “sign up” paper below the advertising poster. Parents could fill put their name on the list (which contained a limited number of free slots) in order to sign up for attendance. This way it was easy to see how many parents already signed up. Drawbacks, however, were that presence was required to sign up—and if a pencil was missing, no one was able to sign up any more. Also, only names were filled in by parents (thus, there was no easy way of contacting them). In addition, this way of signing up for events is likely too complicated for parents whose children did not attend the kindergarten where the signup lists were located. For events taking place at other locations, we had a phone hotline (equipped with an answering machine). We did not try to handle registrations online. Looking back, it is not clear why we did not try that. On the one hand, allowing only registered parents to sign up for an event might have been too restrictive, but it could also have been an incentive to register. Allowing all anonymous visitors to sign up for an event could have caused abuse. On the other hand, this could have been a lower-threshold way for signing up.

8. Conclusions

In this paper, we presented a hybrid learning community approach which combines real-world educational events with collaborative media (mobile phones and an online community platform) for parental education. We described the stakeholders and requirements of the socio-technical system as well as our iterative design process and the socio-technical design challenges we faced. Our main research hypothesis was that such a hybrid and regionally rooted approach has advantages over pure online or face-to-face approaches. We evaluated our approach in a long-term field study. Results include that this approach enabled us to reach more parents than separated online/face-to-face approaches, and also parents who did not take part in parent trainings before were reached. We confirmed that (young, “digital native”) parents with young children are used to e-mail-newsletters and are quickly reachable using this medium—interesting usage patterns of the community platform evolved. Even if the online platform was open for everyone from everywhere, a regional focus emerged, corresponding to the hybrid nature of the community. Synergy effects such as face-to-face events advertising online resources, and vice versa, could be observed. However, the online-community was still quite passive on the platform even towards the end of the project period, and seemed to have “died” after the end of the face-to-face events series (but could be revived via new events).

Hybrid scenarios like the presented one for parent education are not uncommon in practice, where education can benefit from some general resources available online, but also needs regional, personal context. In future research, one can investigate to what extent the presented approach can be transferred to other scenarios where reaching and bringing together people is also a problem (e.g., in the field of health education).