About a year ago, I began thinking seriously about an eText authoring platform that could be used to write and publish openly-licensed texts. I work at a large research university<\/a> in the American midwest, which means that a large percentage of my colleagues are engaged directly in both high-level academic research (and publishing) and the more quotidian task of teaching undergraduates and graduate students in their chosen research fields. A large chunk of student time (and money) is spent focused on instructor-selected instructional materials (including books and textbooks), and there have been all kinds of efforts to control and reduce these costs, including interest in producing lower-cost, higher-capability electronic texts (eTexts), and some exploration of self-publishing. On our campus, our CIO published an enthusiastic prediction about the future of eTexts<\/a> nearly three years ago, and our central IT organization had led a series of four progressively larger \u2018e-Text\u2019 pilots.<\/p>\n By and large, however, the eText pilot efforts I saw happening locally ended in disappointment, with hard-working content experts (i.e. faculty and grad students) and well-intentioned technologists generally failing to make durable, useful texts. In my opinion, these failures happened for a number of reasons, but chief among them was the lack of a suitable publishing environment or workflow within which to do the eText authoring. In the report on the most recent centrally-supported eText pilot (which concluded in June 2015), the project\u2019s managers confessed that \u201capplicants who wanted to create a textbook were also looking for advanced interactivity and multimedia integration. While some of our creators were able to find authoring tools that fit (even if awkwardly) the scope of their project, others soon realized the technology we had access to simply would not meet their expectations.\u201d When I read this report, the phrase \u201cwe had access to\u201d caused me to raise my eyebrows most quizzically, and I became even more distressed when later in the report\u2019s appendix I found the following admissions:<\/p>\n We assumed, going into this pilot, that there must be many authoring platforms that could meet the needs of our authors, provide easy ways to incorporate interactivity, and produce a product that would be easy to access and read on a reader or other technology without an author needing to know a lot of code.\u00a0\u2026 After many attempts and forays into different technologies, our team realized that there isn\u2019t a good, publisher agnostic solution yet.\u00a0\u2026<\/p>\n Frankly, we spent very little time on this aspect\u2026<\/p><\/blockquote>\n These two passages distressed me quite a great deal. As a technologist, I don\u2019t want to ever be in the uncomfortable position of offering to provide support for a complex project with a mere assumption <\/em>that there must be a tool out there that can do what the user wants\u200a\u2014\u200aI want to know, clearly and well in advance, that there is a tool that will meet the user\u2019s needs, and I want to know precisely how it operates and what the major constraints and limitations of that tool are before<\/em> I ask the user to make major investments of time and effort into a tool\/workflow. Furthermore, publication and distribution of an eText seem to me as integral to a text\u2019s utility as creation, and to spend \u201cvery little time on this aspect\u201d seemed to me to decision to avoid in any future efforts to make usable eTexts.<\/p>\n Once I finished reading this report, I felt very strongly that the any future efforts to produce usable electronic texts for higher education on our campus would need to focus first<\/em> on the technical development (or selection) of a suitable authoring, publishing, and distribution environment, and that this focus seemed to me to have been neglected in previous efforts to develop eTexts on our campus.<\/p>\n While I felt hopeful that there would be authoring platforms that could meet the needs of authors, rather than assuming such a tool already existed, I thought it would be wise to make a clear list of principles or capabilities such a tool would need to satisfy before being considered for use as a development option. After some thought and reflection, I developed the following list of six core principles\/features that any eText authoring\/publishing platform should satisfy before being considered for adoption to produce texts for use in higher education.<\/p>\n I believe that an ideal eText authoring\/publishing tool for use in higher education should be:<\/p>\n This feels self-explanatory, but it\u2019s of crucial importance. It seems to me that the best authoring environments for text creation, especially open texts, are the most democratic. An ideal eText authoring tool should have a low technical barrier to entry and should not be more difficult to learn to use than a basic word-processor.<\/p>\n An ideal authoring tool should allow many authors to work together to produce a text. It should also keep track of past revisions, and allow authors to review or restore previous edits. It would be ideal if it allowed authors to establish a basic editorial workflow as well (a system of editors, commenters, proof-readers, etc.) and could hand role-management and permissions for a variety of different production roles. It almost goes without saying that if these are the requirements, the tool should probably be web- or cloud-based.<\/p>\n By this I mean several things. First, the tool should be built on broadly shared, open standards<\/a> whenever possible, and should use these standards in its output. For the web, this means that it should make well-formed HTML5 output, and should be styled with CSS3. Generic output should be cross-browser<\/a> and cross-platform<\/a> compatible and stylesheets should be built with responsive design<\/a> in mind\u200a\u2014\u200ain very simple terms, this means that the content should probably take fluid or flowing rather than fixed form, and should display with minimal issues on a variety of web-connected devices of all shapes and sizes.<\/p>\n In the United States, many institutions of higher education are subject to legal requirements for accessibility mandated by the Americans with Disabilities Act<\/a> or by Section 508<\/a> of the Rehabilitation Act of 1973. In addition, many institutions have local policies of access and inclusion designed to ensure that a broader segment of the public is able to make use of their materials and services. At the very minimum, the tool itself should be fully accessible to potential users and should produce content which satisfies the relevant legal requirements, and, if web-based, should also strive to fully implement the latest web content accessibility guidelines<\/a> issued by the W3C (an international organization founded by Tim Berners-Lee<\/a> which develops web standards).<\/p>\n By this I mean that the tool maker or publishing platform should exert no control over content. Content creators should have exclusive power to decide how texts are licensed and should be able to quickly and easily publish material with the license of their choice, including Creative Commons licenses<\/a>. The tool should also permit content creators to export to any\/all of a wide variety of standards-based formats (like HTML,\u00a0.epub,\u00a0.mobi,\u00a0.pdf, or text) and make persistent copies of the text available to interested users in any\/all of these formats.<\/p>\n eTexts, particularly those based on the web, provide a number of possible enhancements that are not available to those working in traditional print formats. Chief among these is the inclusion of native or embedded audio and video resources. An ideal eText authoring tool should allow for the easy insertion of audio and video content, ideally through a dedicated media server which handles streaming issues so that users on different browsers\/platforms have a uniform experience.<\/p>\n An ideal eText authoring tool would also allow content creators to design interactive learning experiences. These experiences should include a range of activities permitted by modern web technologies, and should be simple to create and insert in the text. At the very least, the tool should allow for robust formative assessment<\/a>, and should be capable of giving timely, helpful feedback to learners.<\/p>\n An ideal authoring tool should produce an eText that is fully capable of standing alone as a fully-functional web object or being wrapped in some kind of file format (see principle 4). In addition, these eTexts should also be able to be easily integrated with a Learning Management System, so that interested instructors can quickly and easily bring their content into a course they might be teaching. This is primarily an institutional need, but the principle remains valid, I think. When content is used with an LMS, the content should allow for assessment\/some analytics, particularly in relation to any of the interactive pieces described in principle 5. If we\u2019re speaking about IMS Global standards<\/a>, the tool should provide LTI<\/a>, QTI<\/a> and\/or Thin Common Cartridge<\/a> integration at the very minimum, with full Caliper Analytics<\/a> compliance as the gold standard. If your eyes glazed over at the acronym soup, what it means is that we want a clear and system mechanism for wrapping or inserting the text inside of the LMS, so that it looks and feels like other kinds of content that a learner might encounter there [step 1]. The trickier piece [step 2], is that if a learner engages with the content from the LMS, it should be possible, under certain conditions and with the learner\u2019s full consent, for the LMS to measure and report about what a learner does in or with that text.<\/p>\n\n
Step 3: Choose an Authoring Platform<\/h4>\n
Step 6: Publish and distribute<\/h4>\n
\nCore Principles for an eText Authoring & Publishing Tool<\/h3>\n
1. Relatively easy for novice users to work with<\/h4>\n
2. Collaborative, with robust version control<\/h4>\n
3. Open standards-based, device\/platform agnostic, and compliant with both Federal accessibility law [Section 508] and local policies<\/h4>\n
Open Standards & Device\/Platform Agnosticism<\/h5>\n
Accessibility<\/h5>\n
4. Able to export to multiple, nonproprietary formats without intellectual property issues<\/h4>\n
5. Capable of including multimedia and interaction<\/h4>\n
Multimedia<\/h5>\n
Interaction<\/h5>\n
6. Able to function both apart from and inside of multiple Learning Management Systems.<\/h4>\n