The "Sticky" ePortfolio System: Tackling Challenges and Identifying Attribute

min read

© 2004 Ali Jafari

EDUCAUSE Review, vol. 39, no. 4 (July/August 2004): 38–49.

Ali Jafari is Professor of Computer and Information Technology and Director of the CyberLab at Indiana University Purdue University Indianapolis (IUPUI). His ePortfolio address is http://jafari.with.iupui.edu. Comments on this article can be sent to the author at [email protected].

At some point, the electronic portfolio, or ePortfolio, will become a fully implemented, successful tool. I am convinced that ePortfolio systems will play a significant role in higher education. However, the process of developing and implementing a successful ePortfolio project—one that is "sticky," one that works and is adopted by users—will first involve many challenges. Higher education will need to tackle those challenges in order to turn the ePortfolio concept into a working system. In addition, higher education will need to identify those ePortfolio system attributes that will lead to success. But by learning from past experiences with other electronic educational tools and by studying difficulties already encountered in those earlier projects, ePortfolio developers can more easily understand and more readily address potential future problems.

The ePortfolio Concept

The ePortfolio is a new concept, with the "e" part of the term suggesting that this is an online environment loaded with electronic tools that can be used to develop and present a portfolio package. Such an environment requires the invention of a new software-management system to offer services for the creation, management, maintenance, and presentation of electronic portfolios. Some developers view the ePortolio as a personal, lifelong content-management system for collecting, reflecting on, selecting, and presenting learning outcomes and other professional accomplishments.

For educators, the ePortfolio concept holds several various meanings. Groups such as provosts, career center directors, deans, department chairs, faculty, and students each perceive a different set of functional requirements for the ePortfolio software environment. Some provosts and academic leaders are excited about the evolution of the ePortfolio because it promises a new environment with tools to demonstrate and assess student learning and thus to map teaching and learning outcomes in accordance with each institution’s established principles of learning. Career center directors think of the ePortfolio as a valuable mechanism to aid students in career placement. Deans and department chairs view the ePortfolio as something to use when their programs are due for accreditation and external review. Faculty members see the ePortfolio as a powerful tool that eases the tenure process and the preparation of promotion dossiers, as well as provides a straightforward method for compiling annual faculty reports. Students, however, seem confused about the usefulness of the concept and apparently do not yet consider the ePortfolio to be sticky enough for adoption.

To reduce this confusion and to clarify the purpose of an ePortfolio project in an institution, some scholars and developers of ePortfolios have started to use an identifier to precede the name of their electronic portfolio, for example student learning portfolio, career portfolio, institutional portfolio, department portfolio, faculty portfolio, student portfolio, lifelong portfolio, or course portfolio. Certainly, many issues can be addressed to effectively encourage acceptance of the ePortfolio system so that users truly realize the considerable benefits of its versatility.

From Concept to Working System

Three key steps or tasks are necessary to complete the development of a new software project such as an ePortfolio system. As illustrated in Figure 1, the initial step is to conceptualize and define the overall system operation as determined by a delineation of the functional and technical requirements. In terms of developing an ePortfolio project, this first step is usually initiated by the provost section of a campus, typically the academic think tank and faculty members. The second step is to design the software and develop an environment that intelligently affords those requirements specified in the first step. This second stage could be completed internally by a group of software architects and developer experts, it could be outsourced to an external software company, or it could be purchased as a commercial software or hosting service. The third and last step is to implement and maintain the project. This final phase generally encompasses the operational components accessible through the campus IT service provider or a third-party company that supplies hosting and IT services.

Figure 1. Steps to Develop an ePortfolio System
Figure 1. Steps to Develop an ePortfolio System

The successful development of an ePortfolio project involves various challenges. First, the conceptual design (step 1) and the software design (step 2) must result in an environment that can both deliver all the ePortfolio functional and technical requirements and satisfy the expectations of ePortfolio stakeholders and end users. This challenge must be addressed by the invention of new software tools, since current electronic educational tools (such as the course management system or the campus portal) do not deliver the flexibility demanded by an ePortfolio system. Designing and developing the ePortfolio software environment may at first blush appear to be rather simple tasks, but they are intrinsically difficult. The difficulty does not lie in the development of the source code but rather in the requirement for an intelligent design that accommodates the human aspects essential to making the project work (aspects such as the construction of a well-reasoned navigational scheme and logical user interface design), which must then be followed by a smooth integration into the existing educational software environments, principally the course management system, the student information system, and the campus portal.

As Figure 1 illustrates, the software design (step 2) consists of two major components: the human aspects and the computer aspects. The human aspects are more difficult to design, whereas the computer aspects are becoming easier to engineer. In many instances, the failure to understand and harness the human aspects of software design, rather than the failure to machinate the computer aspects, is the major cause for the breakdown of an entire ePortfolio project.

The computer aspects of software design mainly concern the mechanical aspects; specifically, this side of software design deals with the building blocks used to create a software environment, such as J2EE vs. ASP.NET for development of the actual software source code or SQL vs. Oracle for creation of the database. Today, with new software-development tools such as Microsoft Visual Studio .NET, development of a new software environment is substantially advanced and thus easy to manipulate. Often an undergraduate student can create a rather sophisticated software environment, one that may have taken numerous experienced or professional programmers considerable time—and also considerable money—to complete just a few short years ago. Furthermore, in terms of educational software development, an increasing number of open source communities are offering free source code for the development of ePortfolio systems. With the notion of open source communities, software models are offered free of charge for developers to modify and integrate into a customizable ePortfolio software system.

The human aspects of software design essentially deal with those requirements intended to satisfy the desires and needs of the end user and to provide capacity for features not yet contemplated. The end user is a human being, and not all human beings have the same demands or expectations for human-computer interaction. Hence the human aspects are certainly the most problematic project issues to be addressed, since they directly affect both usability and user acceptance—issues that can make or break the success of an application. Unfortunately, the human aspects design component of the project cannot be resolved by simply being assigned to the typical computer programmer; hard-to-find, qualified expertise is required. Though many campuses have invested tremendous resources in the in-house development of software systems such as course management systems and campus portals, a significant number of those projects have failed—not because the source coding developed by the programmer was bad but because the environment was not sensitive to the user and did not offer an easy-to-use interface with the expected or desired feature sets, an understanding of the user’s natural habitat, or a multitude of other human aspects.

Another challenge in the successful development of an ePortfolio project is the generation of a robust business plan. Because the ePortfolio is a new application, shrewd budgeting strategies are required to buy or build it and then to promote, operate, and maintain it. The potential challenges can be understood by comparing and contrasting the ePortfolio with another higher education application: the course management system, or CMS, one of the most successful technology projects in academia today.

The CMS offered a new line of business for campuses: by providing courses online via the Web, institutions made classroom instruction available to students who could not otherwise come to a physical campus, thereby spawning a newfound source of tuition income for sponsoring institutions. Furthermore, the CMS made traditional in-class education more convenient by offering complementing services to both instructors and students. Soon the CMS became a source of new income and an asked-for tool. Although it is not yet clear whether the benefits of the ePortfolio business model will parallel the advantages of the CMS project, it is probable that campuses will generate additional income by furnishing desirable lifelong ePortfolio services to their alumni population.

Obviously, when a new ePortfolio system is offered to students and faculty, supplementary resources in IT services will also be required, leading to the call for additional annual budgeting for the promotion, maintenance, and support of the system. Since initially the ePortfolio will not likely have an income-generating business model as reliable as that of the current CMS, implementation could pose another serious challenge, especially for campuses with minimal funds delegated for technology projects.

Attributes of the Successful ePortfolio Project

Figure 2 illustrates the factors contributing to a successful ePortfolio project. The scale is numbered from 1 to 5, with 1 being the least successful ePortfolio project (a project that is likely to be dismantled) and 5 being the most successful (here also labeled as "sticky"). As Figure 2 reveals, a combination of several attributes can contribute to the development and implementation of a successful ePortfolio project. The ePortfolio Success Algorithm can thus be constructed as follows:

Successful ePortfolio Project = I + J + K + L + M + N + O, where:

I = ease of use,

J = sustainable business plan,

K = advanced features,

L = robust integrated technology architecture,

M = lifelong support,

N = standards and transportability, and

O = X.

This algorithm highlights the fact that the success of an ePortfolio project does not involve simply the mechanical development of computer source code. Although an increasing number of initiatives and partnerships are developing source code for electronic portfolios, it is wrong to assume that once source code has been developed and made available to the public, participating institutions are ready to deploy a successful ePortfolio system. Indeed, the source code—or the robust integrated technology architecture, as attribute L is labeled in the ePortfolio Success Algorithm—is but one of many important attributes necessary for a successful ePortfolio project. The ePortfolio is a new concept, a new paradigm, a new software environment; it will be a new and expensive service offered to educators.

Figure 2. The Successful ePortfolio Project
Figure 1. Steps to Develop an ePortfolio System

Ease of Use

In a successful ePortfolio project, the software environment must offer an attractive and simple interface with minimal or no training required. As noted above, the CMS did not gain full acceptance until it became easy to use. Although today’s students and faculty are more technologically savvy, they also have an increasing expectation for an easy- and fast-to-navigate software environment. Many students will use a Hotmail or Yahoo e-mail account, for instance, because going through Hotmail or Yahoo messages and managing those inboxes is much faster than using a cumbersome campus e-mail system. Those same students will similarly have a better response to an ePortfolio system that provides a good first impression as to its logic and usefulness, and the likelihood increases that they will return to the application because they find it appealing.

Ease of use is not limited to the modules within the ePortfolio software environment. A student may need to transport various academic accomplishments, such as a term paper with a certified assessment grade, from a CMS to his or her personal ePortfolio site. Cross-transportability of modules and electronic files among learning-management systems and ePortfolio systems should thus be effortless and immediate.

Again, the human aspects design is a major component of the total ePortfolio software design. Even though mixing different pieces of software created by different developers within an open source consortium may propose interesting applications, that mix could also easily compromise the human aspects design of the project, mainly because not each developer or working group will necessarily use the same interface. Consequently, each tool within an ePortfolio system could end up with a different user interface and navigational scheme design, resulting in an unnecessarily long learning curve and ultimately in the breakdown of an entire project. Users are known to quickly become frustrated and simply abandon a confusing application, so it is only logical that the human aspects should be heeded such that the management of each ePortfolio system tool is consistent with and applicable to other tools within that environment.

Sustainable Business Plan

The ePortfolio is a new service, mandating new budgets for software building and licensing, software maintenance and updates, user support and help desk, and faculty development. The success of an ePortfolio project thus certainly depends on a long-term, sustainable business plan.

The CMS was a successful project because it was developed using a healthy business model and because it provided valuable, unique services that created a new source of income for academic institutions. In other words, the CMS breathed new life into cash-strapped campuses by providing a system to offer and sell distance-learning courses for both certificate and degree programs. Unfortunately, the provision of ePortfolio services may not bring such an influx of income to campuses, at least not at the same level as CMS projects. Though not necessarily a weakness in the business model, this lack of strength may result in a longer implementation process for ePortfolio projects, especially at those institutions with limited technology budgets.

To address any budgetary dilemma, a campus alumni office could suggest a minimal fee to offset the expense of operating an ePortfolio project. By offering graduates lifelong ePortfolio services, for instance, the alumni office could promote a new alumni membership package that would include continuation and maintenance of a personal ePortfolio account after a student has graduated and left the college or university. A graduating student may be interested in this package for a number of reasons. For instance, a student may want to continue using his or her ePortfolio site to exhibit a professional Web site hosted by the institution or by a third party contracted through the institution. Also, a student may want to retain easy access to papers and other artifacts generated in class, especially those files stored in a certified file-management system. Without access to the certified file server, a student would have difficulty proving to a future employer the authenticity of such papers and artifacts and, moreover, would need to maintain a space-consuming physical portfolio and would need to keep track of a myriad of paper records and/or electronic files using various online storage services. Furthermore, the ePortfolio system could allow alumni to use their campus e-mail addresses as permanent e-mail addresses, which would greatly promote networking among alumni.

As a proof-of-concept model of an ePortfolio system applying this approach, the Epsilen Project developed by the Indiana University Purdue University Indianapolis (IUPUI) CyberLab (http://www.epsilen.com) uses a patent-pending method known as the Dynamic Personal Portal, or DPP, to dynamically and automatically create and maintain a personal lifelong portfolio Web site address for each new student and faculty member of an institution.1 Consider, for example, the ePortfolio project at Bowling Green State University. Suppose that there is a new student named John Smith with the following e-mail address: [email protected]. The university uses the DPP method to automatically and dynamically create an ePortfolio account for John. Using the DPP method, the campus ePortfolio system has assigned to John the following URL as his personal ePortfolio address: http://jsmith3.with.bgsu.edu. This "lifelong" personal ePortfolio address is very easy to deduce and remember, since it includes all the components of John Smith’s e-mail address. The ePortfolio Web address is simply created by substituting ".with." for the "@" character within an e-mail address.

The DPP method offers an incentive to graduating students to maintain their alumni membership—so that they can continue to take advantage of their personal ePortfolio sites after they have graduated from the institution and left the campus. The easy-to-guess Web address can be placed on the professional business card of each alumnus. Furthermore, just like the class ring that some alumni wear to show their school affiliation, the URL will reflect the domain identity of the institution that imparted the alumni’s education—in this case, Bowling Green State University, a university with which John will likely always want to associate.

Shaping a durable ePortfolio business plan is a major challenge in the effort to implement a successful ePortfolio project, but it is not an insurmountable task. The ePortfolio can offer such enticing benefits as the DPP, lifelong e-mail, professional Web hosting, certified file-server services, continuous college or university affiliation, and personal networking benefits. And further innovative thinking will surely lead to new ideas for funding sources for the ePortfolio project.

Advanced Features

Today, new Web services, even if free, may not excite many users, including students and faculty members. All of us get daily junk e-mail offering new and free Web services and software tools, but we immediately delete these offers unless one really catches our eye as extraordinary. To encourage users to try new Web services such as an ePortfolio, institutions must demonstrate advanced features, and such features must be attractive, unique, flexible, and interactive. Simply proposing to students that they try a new resume-builder software or career portfolio will not trigger campus-wide use. Some students already enjoy free resume services through commercial Web sites such as Monster (http://www.monster.com).

Thus, the conceptual architects of ePortfolio projects must include interesting, desirable services not conveniently available elsewhere. For instance, if a campus can offer a learning matrix as part of an ePortfolio system, this service will attract students who like to map examples of their academic accomplishments along with the grades received on their official transcript, and those students can incorporate that learning map into their personal ePortfolio site. John Smith’s learning matrix could provide a secure Web site that includes all the good papers and artifacts that he created and then mapped with the campus learning outcomes. Additionally, once John becomes excited about using this feature, he will soon learn to use other software tools and features, such as an internal messaging system, to tell his friends that they should try out the new ePortfolio system.

As the specifications for the next generation of teaching and learning software environments are being conceptualized, the forthcoming educational software systems are expected to be capable of offering advanced intelligent services.2 The ePortfolio software environment can offer advanced services after being designed to learn and to reason. Consider an ePortfolio system that uses a series of intelligent agents advising students on potential carrier opportunities, new coursework, and skill sets they should learn in their senior year based on a real-time market analysis of new jobs and that dynamically connects them to nearby companies for internship and summer job opportunities. Offering these advanced features can certainly contribute to the stickiness and success of an ePortfolio project.

Robust Integrated Technology Architecture

For any piece of software, technology must offer a very robust and "always working" software environment. This is a technological usability expectation rather than a human-computer interaction usability expectation. To create such a robust ePortfolio system is another challenging task because the system must interoperate with existing learning-management tools. If a campus is using technology developed by multiple vendors, data integration and exchangeability may prove to be unattainable.

There are currently two conceptual architectures that offer ePortfolio services: (1) architecture that features ePortfolio add-on components and services to an existing learning-management software such as the CMS, the campus portal, or the student information system; or (2) architecture that features a standalone ePortfolio software system with its own, independently developed tools. The challenges faced within both architectures are the integration of services and the transportability of resources across and among various environments.

For instance, when John is using his ePortfolio environment, he may want to place hyperlink access to his official transcript and control its access by various groups or by a potential employer. He may also want to import a term paper that now resides in the CMS server into his ePortfolio so that he can showcase it and yet still be able to control viewer access. Building services of this type requires tools that provide effective and dependable transportability among different learning-management systems and databases—efforts that could be problematic both because of the technical aspects and because of any licensing restrictions that may be present in the existing licensed technology.

Lifelong Support

A lifelong ePortfolio system refers to an ePortfolio program that promises access and maintenance beyond graduation. Building a lifelong ePortfolio system promotes additional incentives for users to create and maintain their ePortfolios, and any advancement of system use certainly contributes to the business success of an ePortfolio project. Once John Smith, for instance, matriculates from Bowling Green State University, he will be able to continue using his ePortfolio, still accessing all of the documents and artifacts created during his college life. Should John need to retrieve any file stored within his ePortfolio, whether he is looking for a new job or wants to apply to graduate school, those files are immediately available and quickly accessed. Offering the advanced feature of artifact certification in addition to lifelong support provides further incentive for students to use the ePortfolio system.

Standards and Transportability

A number of consortia and groups are trying to define and refine standards for the various learning technology systems, and most have determined that two types of standards are needed.

The first standard for interoperability is analogous to making sure that "the pipes fit one another." This is similar to the plumbing standards that kitchen faucet manufacturers follow so that their faucets will connect to pipes used throughout a building. In information technology, the design technology modules (the pipes) must speak common languages and follow certain protocols and communication standards so that the modules can connect with each other to facilitate the flow of data.

The second standard for transportability is that systems should have common functional requirements. For instance, in an academic CV (curriculum vita), what are the common denominator settings and the minimum number of expected categories? Should every career or faculty ePortfolio reserve a placeholder to list publications, and if so, should the publication category include fields such as "Name of Journal," "Refereed," and "Date"? If the answer is yes, and if Professor Johnson transfers data from his home institution to another university, where a different ePortfolio system is in use, none of his CV categories or fields will be lost when he makes the switch to the new ePortfolio system.

We do not yet have all the necessary interoperability requirements defined for various types of ePortfolios, and this is causing ever-increasing challenges for developers of ePortfolio software environments as the projects increase in size and complexity. Once more standards are in place, ePortfolio systems will gain speed in development. Despite the concerns expressed by vendors, these systems will still be able to maintain proprietary distinctions even with established standards.

The X—or Other—Attribute

The final attribute of the ePortfolio Success Algorithm is referred to as "X," indicating other important unknown attributes that may contribute to the success of an ePortfolio project. The X attribute may differ depending on the ePortfolio type and the method of implementation on a campus.

For example, the creation of a faculty development and incentive program could certainly play an important role in the faster adoption and success of an ePortfolio project. Since not all faculty members will appreciate the application of ePortfolio in academia, or be aware of its utilities in student learning or faculty tenure and promotion needs, offering discussion groups and round-table sessions, seminars, and workshops for faculty and technology administrators is a positive step.

Another "X" attribute might be a top-down initiative to refine freshman courses to include ePortfolio appreciation and awareness, offering new students a basic understanding of and appreciation for the ePortfolio system. This initiative could mandate refinements of some gateway and literacy courses to include learning modules and early training on collection for, reflection on, selection of, and presentation of a student learning ePortfolio.

Faculty and student incentive programs could create a faster and wider adoption of the ePortfolio. Faculty members are very busy with their required obligations for teaching, research, and service. Not every faculty member will have the time and/or the interest to embrace the idea of using a new tool and offering a new learning objective in his or her courses. However, should faculty discover the long-term benefits of the ePortfolio system, they will likely learn to appreciate its features, and once an instructor requires a class to use the system, students will soon follow in that discovery.

New campus policies and procedures may be necessary to support certain applications and implementations of the ePortfolio. The Family Educational Rights &Privacy Act (FERPA), for instance, is a federal law designed to protect the privacy of a student’s education record (http://www.ed.gov/policy/gen/guid/fpco/ferpa/index.html). Additional campus-level policy may need to be established to support some of the ePortfolio implementation features; for instance, if an institution chooses to share students’ assignments, such as term papers and projects, with outside accreditation reviewers, a policy must be in place to authorize the sharing of students’ work with a select number of communities without students’ consent.

Learning from Past Experience: The CMS and the Campus Portal

The course management system offers a model by which we can better understand and appreciate the ePortfolio Success Algorithm. In the late 1990s, the CMS was introduced as an innovative online technology with a new electronic toolbox. A number of vendors rushed into the market to deliver their early software releases, but for a couple of years, the CMS languished as a show-and-tell technology used by no more than a handful of instructors, albeit from leading institutions.

The CMS was finally accepted only after several significant events occurred. First, a template-based authoring interface was invented, offering a very easy-to-learn and easy-to-use software environment. The Oncourse3 and Blackboard systems (http://www.blackboard.com) were the first to create and promote the CMS template-based navigation scheme, which all CMS software products offer today. Second, major new programs and services were introduced that could be offered only with the application of CMS technology. For instance, online distance learning programs, such as those offering MBAs online, were developed based solely on the use of CMS technology. Third, the CMS presented many convenient utilities and features that eased the tasks of traditional classroom teaching and learning. Faculty members liked the CMS because they could take advantage of its simple tools to post the class syllabus, course announcements, grades, reading lists, and so on. Satisfied users caused the CMS to grow until it became a very sticky technology, with most institutions now offering a CMS for some or all of their courses.

Today, however, ePortfolio systems are still in the refinement stage of inventing a new, sticky software environment in addition to developing a viable, dependable business plan to fund and support the ePortfolio environment for current students and future alumni. Developers need to think outside the box about the future of interface design and navigational scheme to create a truly usable and sticky environment. We need smooth integration and easy interoperability, with the understanding that this new environment must be assimilated with the other related technology already in use, such as the CMS, personal file storage, the student information system, and productivity tools (such as word processors). We also need to develop advanced ePortfolio tools that offer unique services not accessible outside the ePortfolio.

Like the CMS, the campus portal has generated many discussions among higher education communities over the past several years. Many campuses used vast resources to develop a campus portal, whether by building it in-house, buying it off the shelf, or using some free, open source software. However, no more than a handful of institutions have managed to complete a successful, working, sticky portal project. The struggle to develop and implement a successful portal project has not been caused by a lack of software packages; rather, the problem has been the lack of innovative design for the human aspects requirements of the project.

The attempts to develop successful campus portals should offer insights for developers working to deploy successful ePortfolio projects. Maybe by looking at the less successful campus portal projects, developers will be able to understand the attributes that caused the failures of these projects. Such an investigation could suggest guidelines regarding which ePortfolio Success Algorithm attributes should be highlighted and which need more attention.

Conclusion

Academic leaders and the scholarly community have presented convincing cases for the use of ePortfolio software systems in academia and beyond. But there are many challenges that must be tackled on the way to building and implementing an ePortfolio software environment that will be sticky to end users and will be sustainable as a new enterprise service for students, alumni, and lifelong users. The ePortfolio Success Algorithm identifies several attributes that can be used to facilitate the success of an ePortfolio project. When these are considered in conjunction with both the computer aspects and the human aspects required for the design and development of such a project, and when use incentives, interoperability standards, and transportability features are added, the deployment of successful and sticky ePortfolio systems will surely be attained in the very near future.

Notes

1. Inquiries to use the DPP patent-pending system and method should be forwarded to the Advanced Research &Technology Institute (ARTI) at Indiana University: [email protected].

2. Ali Jafari, "Conceptualizing Intelligent Agents for Teaching and Learning," EQ: EDUCAUSE Quarterly, vol. 25, no. 3 (2002): 28–34, http://www.educause.edu/ir/library/pdf/eqm0235.pdf (accessed May 10, 2004).

3. For more information about Oncourse research and development, see Ali Jafari, "The Rise of a New Paradigm Shift in Teaching and Learning," T.H.E. Journal, vol. 27, no. 3 (1999): 58–68, and Ali Jafari, "Development of a New University-Wide Course Management System," in Lisa Ann Petrides, ed., Case Studies on Information Technology in Higher Education: Implications for Policy and Practice (Hershey, Pa.: Idea Group Publishing, 2000).

EDUCAUSE Related Resources

"Electronic Portfolios: Why Now?" was the topic of the February 11, 2004, EDUCAUSE Live! presentation (http://www.educause.edu/live/2004/live042/) delivered by Barbara L. Cambridge, Vice President for Fields of Inquiry and Action at the American Association for Higher Education. The hour-long interactive Web seminar discussed how electronic portfolios contribute to learning, assessing, and accountability.