More Than Assessment: What ePortfolios Make Possible for Students, Faculty, and Curricula


For one of my first major assignments as the graduate assistant for Auburn University’s ePortfolio Project, I developed a special website that our office termed an article-as-ePortfolio. The article-as-ePortfolio began as a possible submission idea for an online journal, The Journal of Interactive Technology and Pedagogy (JITP). The journal features articles on innovative uses of technology in teaching, learning, and research. In this issue, the JITP was open to accepting “multimodal submissions.” I began communicating with the lead editor of the upcoming Issue 10 of JITP, and we determined that the ideal multimodal submission would be an interactive article, to be sent as HTML and CSS files, along with other resources. I employed the skills and best practices I gained from Dr. Susan Youngblood’s ENGL 7060 Web Development class to create what would become “More Than Assessment: What ePortfolios Make Possible for Students, Faculty, and Curricula,” the published article-as-ePortfolio in Issue 10 of JITP. I also authored much of the section titled “Looking Ahead,” specifically focusing on digital affordances and accessibility teaching opportunities.

Web Development Project Management

The article-as-ePortfolio was a collaborative effort from all four members of the ePortfolio Project. I took on all web development tasks from concept to execution. We quickly found a need for the implementation of a workflow that allowed for me to develop the website’s code. Each week, the team would meet to discuss progress on the article, where I would demonstrate the latest version of the website. This workflow approach resembles an Agile workflow, but is a bit more informal; where a typical Agile development would involve the creation of fixed cycles with end dates, my team only set one deadline before the first submission. I thought of my work as the implementation of features (the smallest development component) within the website’s code, another term from Agile development. These two Agile elements allowed for my team and I to assemble parts of the article-as-ePortfolio independently, which increased our productivity, and without this approach I doubt we would have sent our submission on time.

Before starting on the website, I gathered information from our team that I used to develop a low fidelity, or lo-fi, prototype of the website’s information hierarchy and page layout. A lo-fi prototype can be useful when demonstrating general concepts and a global vision for a project. I learned about lo-fi prototyping techniques in the context of designing print documents, but the technique translates well to communicating information architecture and web page layout. The prototypes were well received by the ePortfolio Project team, and I began to develop the website based on my wireframes and information architecture.

Usability and Accessibility

The article-as-ePortfolio follows the usability principles of Steve Krug, specifically his “don’t make me think” philosophy found in his book of the same name (2006). To reduce the number of questions users might face, I relied on the genre conventions of journal articles; this approach turned pages into the sections a reader might see as they read through a print article, and I included a bibliography page as the “last” page, at the far end of the navigation bar. Given the affordances of an interactive article, we also included hyperlinks in the article text, adding locations where readers could choose to access more text immediately, a mode of reading (and writing) impossible to reproduce in print. The article-as-ePortfolio was developed with potential mobile phone and tablet users in mind, and the website’s navigation, text, and images are all responsive and mobile-friendly. The website was also built to be accessible to screen readers through the implementation of alternative text, following the guidelines on the WebAIM alt text web page. I ensured alt text was present for all images needing a text alternative; this opens the website to participation from a much wider audience and allows people with disabilities to use the website “as normal” users, which empowers users through increased control. While I would have liked to include more accessibility features, the nature of the submission limited my control over the final product’s code. Despite this limitation, I am comfortable claiming that the final product is a usable, accessible website for a wide range of users, thanks to the various approaches and features I implemented in the article.