Eli Review is a web-based educational technology app designed to help teachers facilitate writing improvement in any discipline where writing is an essential practice. It is used at all instructional levels (K-12, higher ed) but used most at the college level.
The Eli Review website has a complete breakdown of what the app does and why it was created. The business is operated by a team of educators but has only two full-time personnel: Melissa Graham Meeks, director of professional development, and myself (Mike McLeod), co-founder and head of product.
Creating a Company, Launching a Product
I am one of three co-inventors of Eli Review and a co-founder of the business that it became. I’ve been with the project since day one, having built the prototype by hand using PHP and MySQL and co-authored its original patent applications. I worked to develop it initially as part of my job at the Writing in Digital Environments (WIDE) Research Center at Michigan State University where I was a UX researcher, designer, and software engineer focused primarily on information architecture.
When Eli was rebuilt to be commercial software, I took on the role of project manager and eventually head of product. I am still responsible for its information architecture and a good deal of the front-end engineering. My most important role is to develop requirements and document issues for the team of developers with whom we contract to maintain the infrastructure and do the bulk of the back-end work for new features as we need them. I am also responsible for quality assurance and user testing for all new development.
When not actively maintaining or developing the product, I am responsible for all technical writing, particularly maintaining up-to-date support materials for customers. I provide active user support across our various platforms. I also run the Eli Review social media accounts, lead teacher workshops, design marketing materials (lanyards, stickers, banners, flyers, etc).
Eli Review as a concept is much older than Eli Review as a commercial entity. It has gone through several phases of development, going all the way back to 2007.
Phase 1, Experiment
Eli began in 2007 as a project in the WIDE Research Center. Jeff Grabill and Bill Hart-Davidsons, directors of WIDE, were challenged by the College of Business to create an intensive 5-week writing course. They decided to focus on the two essential skills for writing improvement – feedback and revision – but were stymied by the lack of tools to teach those skills.
I built the earliest prototype for Eli as a feedback collection tool. I built it using PHP and MySQL (what I lovingly call “MacGuyver Code” – code good enough to accomplish the goal, but not good enough or stable enough to scale or even build upon). The prototype proved to be highly successful at facilitating the 5-week business classes, and we kept it running at the research center for several years as other faculty members learned about it and wanted to use it in their own courses.
Phase 2, Commercialization
The intellectual property behind Eli Review was spun out of the university in 2010 for the purpose of starting a business and developing it as a commercial application. The app was rebuilt by contract developers using my specifications but with a more stable and reliable codebase. Instructors at any institution could use the new version of the app for free, but students needed to purchase a subscription in order to participate in those classes.
Eli is still in Phase 2 as of September 2018. It has seen many upgrades and improvements since 2010, including a transition to cloud hosting and auto-scaling infrastructure and substantial new features as users have identified needs. I have overseen these developments at each stage, being responsible for all UX research and design, requirements, and a great deal of the engineering. The most recent addition was a course cloning feature released in August 2018.
Phase 3, Complete Rebuild
Every engineer knows that some day the technical debt has grown too large and that the most economic option is to start from scratch. We’ve anticipated that and already have detailed plans for Phase 3.
I have developed a complete set of specifications for a brand new version of Eli Review that would modernize the application. I started this process by developing a complete information architecture, making sure that all of the analytic data we need accounted for, before sketching even a single interface. If and when the means become available, Eli Phase 3 is ready to begin.
Key Intellectual Property
Code tends to be the most valuable currency in software development, but good code is the result of good writing. Eli is meant to support a series of concepts about teaching and learning and we have written at length about how we use software to accomplish those goals. Every bit of good code in Eli Review came from a good idea we wrote about or shared without our academic community.
- Patents: we pursued two patents out of the process of inventing Eli Review, Social Writing Application Platform and Systems and Methods for Tracking and Evaluating Review Tasks. Both were ultimately denied after extensive review, but the process of preparing and litigating them was informative.
- Whitepaper: this document was produced before the Phase 2 version of Eli was built and has served as a touchstone for each stage of development. It has helped us keep the user experience focused and prevent feature creep all tis time.
- “A method for measuring helpfulness in online peer review”: This article, published in the Proceedings of the 28th ACM International Conference on Design of Communication (SIGDOC ’10), laid out our helpfulness algorithm and has remains our most-cited scholarship.
- Designing Web-Based Applications for 21st Century Writing Classrooms: this book chapter describes the methodology we used to build Eli Review for others in the field of writing studies so that others might follow our lead. It focuses on placing information architecture at the center of the design process.
My academic resume (CV) has a complete list of all of our Eli-related publications and presentations.
Each of these tells a story about developing or improving key features within Eli Review. They help demonstrate how the product has evolved over time along with our understanding of what users need from the app.
- Reskinning Eli Review – developing a new layout to improve accessibility, responsiveness, and aesthetics
- Price Points and Bookstore Cards – adding support for multiple price points and printed subscription cards
- LMS integration – figuring out how to integrate Eli Review into another product without compromising our UX
- Time and UX in Eli Review – upgrading Eli Review to support global time zones and localized time displays
- Course Cloning – creating a new feature to clone an entire course and its contents
- Phase 3 Logo – developing a new logo and color scheme for the newest version of the app
Eli Review has six innovative features and designs that set it apart from other writing tools and educational technology.
Skills I’ve developed with Eli Review
It’s difficult to sum up all of the ways I’ve grown over the course of ten years working on a project, but these are some of the highlights:
- Leadership – I was a teacher and a mentor before Eli, but working on the app required me to develop new leadership skills quickly. I maintained product consistency by authoring our whitepaper, I wrote detailed requirements and used them to lead our developer teams, and I recruited, hired, and supervised a lot of design talent over the years (example).
- Developing on budget – I had to learn quickly how to do a lot with a little. We never had stacks of cash to throw at development problems, so each initiative had to be done as cost-effectively as possible. We got very good at this, and a number of the case studies included here were big features where we were able to maximize on productivity or draw from existing resources or some other way to get the best bang for our buck.
- Maintenance – Something I’d never imagined going into a project like this was just what keeping a large web app running meant. I’d run servers before, but never servers that needed to auto-scale to support traffic loads or monitor them for suspicious activity or routinely check error logs. Research and development are critical operations for a company, but not more so than the daily routine of checking logs and config files and keeping existing products stable and reliable.
- Thoroughness – I’ve learned that developers need requirements written out in great detail to fully understand a feature. The work of preparing requirements is critical not only for making development go more smoothly but also for documenting the work for users after development.
Most of my sample materials are related to Eli Review, but you can find all case studies, writing samples, presentations, or blog posts by following this tag.