Paamsongre Courseware, as I came to name this platform after six years of organic development, began as a graduate school assignment which tasked us [graduate teaching assistants] with creating our own professional website. Some of the suggested tabs for this website were an AboutUs page, a teaching philosophy page, a CV page, a scholarship page, and a pedagogy page. This latter page originally had a list of courses taught alongside the course descriptions and links to course syllabi. Upon completing the assignment and realizing the kind of flexibility that iWeb, Apple’s then template-based website creation tool, offered in terms of the spatial arrangement of items compared to my institution’s LMS, I decided to add more content to the pedagogy page such as course assignments and calendar and used it in tandem with my institution’s LMS for teaching.

Two years after creating the site, the cloud-based movement led Apple to retire iWeb. This decision forced me to migrate my site to a different web host, and this process led me to explore a wide range of applications that could be used for teaching. This exploration was guided by students’ input, often in the form of suggestions or their experiences using various applications. As semesters passed, more applications were tested and sometimes adopted and more course materials were moved to the site. At some point, students only used my institution’s LMS for submitting their papers and checking their grades.

My web development skills were further enriched by my experience working as content developer for a digital textbook company and co-authoring a digital textbook for first-year composition. From this collaborative work with education consultants, technology experts, video producers, graphic designers, marketing agents, and fellow content developers, I came to realize that writing instructors need to be at the forefront of online teaching platform development for writing instruction. Said simply, online teaching platforms should not be designed for us to use, but instead, we should be designing them. 

Upon taking on a full-time teaching position and building on my teaching, content development, and web development experiences and skills, I decided to take my teaching website to another level by making it a stand-alone teaching platform with the full features of an academic LMS. Academic LMS products, as Foreman (2018) describes, typically include 1) user management, 2) course management, and 3) administration. User management supports the creation and maintenance of user accounts, enables users to log in to their accounts through authentication, and stores important information about each user through associated profiles. Course management supports the integration of course materials such as lessons and assignments, course syllabus, learning goals, and schedule. It also supports interactive tools such as surveys, quizzes, and pools, web conferences, instructor-to-student and student-to-student messaging systems, discussion topics, group and collaborative workspaces. Administration supports features not available to students such as grouping users based on assigned roles, permission management, online classroom creation, class roster and gradebook, reports, analytics, and statistics. 

The initiative to grow my teaching website into a full-featured academic LMS was also motivated by the fact that my institution provides substantial teaching-with-technology funds in the form of grants for faculty to apply for. As such, designing the LMS ‘on paper’ in the form of a grant proposal was the next logical step. Writing this proposal helped generate comprehensive answers to crucial questions such as “What problem will the LMS solve?” “Is the problem concrete, demonstrated, and documented?” “What are my objectives in designing it?” “What specific tasks or activities need to be implemented in the development phase?” “What members of my institution will be involved?” “Will there be any third-parties involved?” “Who are the users of the product?” “Where are they coming from?” “What device(s) will they use to access the LMS?” “In what kind of an environment will they be using it?” “What is the timeline for creating it?” “How much is it going to cost?” “How will it be paid for?” “How will it be sustained?” “What methods, mechanisms, or evaluation tools will be used to measure its impact or effectiveness?” “How will the feedback generated through these evaluation tools help improve it?” Answering these questions at the proposal stage helped with anticipating potential challenges that could arise in the building phase. 

For the proposal to have more persuasive power and with my own financial means, a prototype of the LMS was built and linked for the evaluators to explore. It was built on the extensive ‘informal’ user research I had been conducting during the first six years of using a website for writing instruction, a time when I had no idea of what my teaching platform could grow into. As Hall (2013) explains, user research is neither  a method of determining students’ personal preferences nor an effort to establish some type of scientific truth. It is simply a process of gathering useful insights about technology use, which could be used to improve that particular technology. Having used my website for teaching face-to-face for many semesters, I have had the unique chance of observing students use the platform in and even outside the classroom and have gathered useful insights about what works and what does not work so well. This approach aligns with Blythe (2001) user-centered model, which centers on designing “from observations of actual technology use” (p.332). It also promotes “accessibility,” OWI Principle 1 “Online writing instruction should be universally inclusive and accessible” (CCCC, 2013). 

Building the prototype began with defining the learning outcomes and working backward to identify the  assessment tasks and learning activities that will assist students in meeting these outcomes. After the learning activities and assessment tasks have been determined comes the task of identifying the modalities and technological tools students would use for executing specific activities.  This model, also known in the literature as backward design (Wiggins & McTighe, 1998) aligns with OWI Principle 2, as it ensures that the lesson focuses on writing and not on technology (CCCC, 2013). Building the prototype took hundreds of hours reviewing and evaluating various applications and watching tutorials on how to use and integrate them into a single platform. It helped flesh out the design of the homepage interface, the lesson interface, the assessment interface, and the specific learning activities to be implemented. It also helped brand the LMS through designing a logo and defining color schemes and a stylesheet. The proposal yielded the initial funding, which was used for licensing the various applications and plug-ins that went into building the LMS. From the prototype design to the final design, there were several changes resulting from pilot-testing it. Some of the initial applications were kept in the final design, and others were dropped for not being suitable. This iterative principle is at the core of Paamsongre Courseware design, as it is revised based on ongoing usability research. After presenting the final product one year after initial implementation during a Fall Faculty Colloquium Series, my institution agreed to support the technological cost of the platform, and students enrolled in my online writing courses use it at no cost. It is this preparatory work that yielded Paamsongre Courseware.