Edit.

Empowering professors to be in control of their courses and pave the way for market growth with authoring tools.

Client

Next Thought

Role

Lead Designer

Contributions

Competitive Audit

Concept Modeling

Low-Fidelity Wireframing

High-Fidelity Prototyping

Behavior Specifications

First Run UX

UI Design

Visual Design

Shipped

Business Case for Authoring

Refocusing the Company

When our Chief Product Officer Rob Reynolds joined the company, he outlined a three-front approach to focus the company’s efforts over the next two years. Those fronts were robust course authoring, rich data analytics, and enhance our social layer. I was proud to be lead designer on course authoring and lead designer on what would become communities.

Introduction to LMS

Authoring is most significant when contrasted against the climate around Learning Management Systems (LMS) and content publishers. Those who buy LMS and content publishing systems are mostly universities offering courses to students and other entities wanting to distribute professional development material. Many learning management systems are purchased by administrators at the top of the entity’s hierarchy, but who often are not the intended users. In my experience, administrators want their online ventures to: bolster a future looking image, simplify logistics, and analyze the success of their investments. With these blazoned and forward-thinking ideas, it is often left to the LMS and content publishing organization to create the modes in which the product is viewed, placing emphasis on content and media.

Traditional Approach

When a new course was being developed, content would flow from our clients, which would be a mix between upper administrators and users, to our project manager. The project manager would then forward this to our content developer who would send it through data entry and markup. If a client wanted to make a change, it would go through the same process. Brass tax slow turnaround for our client and more overhead for our team. This translates to courses taking longer to produce and fewer launching.

The Team

We had four developers on back-end server, two front-end developers, one quality assurance tester, and me as the user experience and user interface designer. I checked-in every other day with our Head of User Experience Aaron Eskam for status updates and for valuable feedback on explorations.

Outcomes of the Project

  1. Ability to Scale Course Launches
  2. Increase Sales Advantage
  3. Empower Professors to Edit Courses without Aid

Process

Establish Product Requirements

Our core product team knew we were committed to starting the transition to fully user authored platform. However, the scale and complexity of the product meant we needed to launch a subset of features that would provide immediate value in a realistic timeline. Phase one was creating the larger framework and manipulation of existing content. Phase two, establishing a protocol for creating new content.

  1. Create, Reorder, Name, Delete Lessons and Units
  2. Add, Remove, Reorder Content and Sections on Lessons
  3. Manage Publication of Lessons

Acknowledging Technical Challenges

By anyone’s standard, the timeline that we were using to accomplish our objective was ambitious. Our development team faced a host of technical difficulties, that would impact and challenge our course design. One technical challenge we knew about, that would close the doors on certain interactions in the short term, had to do with live data binding. As soon as you made an edit to the course, users would see the change. In the short term there was not a good way to batch save changes to a lesson, meaning edits would need to be saved on each object to prevent unfinished changes from being visible to students. We tried to look at how others might have remedied this situation if there were many live data edits occurring in their program.

Agile Development Cycle

It was a busy year. By the time the fall semester settled, there was not a lot of time to design and develop authoring before the new year. This led to the undesirable effect of design and development starting near the same time. Staying one step ahead, often meant figuring out the flows and high level interactions during whiteboarding session to get developers started and having to finesses and produce visual treatments and assets at the same time they were building the scaffolding. Having the project developers across the same room and the project sprint meant more conversation and less formal documentation.

Bi-Daily Scrums

Being agile during this sprint meant being transparent about who needed what, and when they needed it by. Our development team uses scrum methodology to keep everyone up to date. Because I was designing the system they were building in parallel, it was imperative that I was a part of the bi-daily scrums to update the team about what stage of the design I was in and receive updated prioritizations. Our team worked around the clock for two months trying to get authoring designed and built.

Users and the Generational Divide

Designing an authoring tool for the university professors to interact with for something as important as course authoring was challenging. Mostly because of the generational divide when it comes to integration and confidence with digital products. More technology savvy users prefered cleaner aesthetics and needed less visual cues to anticipate possible interactions. Less technology savvy users needed more hints. Many times I reached for Alan Cooper’s book About Face referencing topics such as his chapter fully documenting drag/drop pliancy as a guide through more advanced interactions. I also looked at leveraging interaction patterns from products that most users are comfortable with like Microsoft Office.

Iterate, Iterate, Iterate

Publication States

When you are a young product company that sells your product to new clients and they have specific use cases, they need to support you often amass a wide range of possible configurations. It very tempting from a developer perspective to conclude that if a client requested it, we build it, and that validates it as a use case. And, by that mode of thinking, if it is a valid use case, that configuration, even if obscure, needs a UI control for authors to use. The problem with this line of thought, is that given the right set of circumstance you can almost justify anything, but building a focused product is giving deference to the useful and minimizing the excessive.

Balancing Clarity with Complexity

One example of this, came around the topic of “lesson publications.” I was told that we needed to support all possible configurations of these three attributes: visible in the course outline, clickable in the course outline, and published. I debated for a week about whether or not visibility, clickability, and publication status should all be independent or not. In the end, I was reminded of an article Simplicity on the Other Side of Complexity where Jon Kolko argues that is not enough to see and capture information you must go a step further to understand. I wanted to make it simple, but not simpler.

The solution I took focused on understanding user intent. By doing this, I was able to communicate that there are three states of publication.

Draft
The first state, draft, is when a user has created some content but it is not ready for consumption. If it is not ready, then no one except the user who created the content should be able to see it or navigate to it.

Schedule
In the second state, schedule, a user has content and would like it to go out at a specific time. For classes and quizzes, many users will have created them ahead of time and would like them to be published at a specific time for everyone to have access to. Because we are talking about courses that affect people's grades and jobs, it is important we do not surprise them. The schedule feature allows the user to see content in the outline in a deactivated state, and shows when it will become available.

Published
The final state, published, means that a user has created content, and placed it so all members of the course have access to it. Published content should be visible in the course outline and its content accessible.

Drag & Drop Pliancy

Our Lead Front-End Developer, Andrew Ligon, had been working on an initial prototype for the drag and drop feature on the course outline and lesson overview. After reviewing the prototyping, there were a few things that needed more tweaking. I turned to Alan Cooper’s About Face, to try to think through and describe to him how certain triggers should behave.

Outlined Suggestions

  1. Object should move immediately on drag event
  2. Object placeholder should be invisible
  3. Object placeholder should be same size as Object
  4. Object placeholder should displace objects as you drag it around
  5. Containers that are valid drop zone should make space to indicate pliancy
  6. There needs to be an indication of invalid drop zone
  7. Cursor should switch to open hand on hover, close hand on drag start

As we moved through the edits, we realized that we could not stop there. We had a problem: If the outlined suggestions were applied to a tall container, the amount of space displaced would be as large as the screen. Andrew and I continued to prototype. The solution that we arrived at was transform a container and its placeholder so it would be scaled to be no taller than a certain percentage of the screen.

Course Outline

Editing the course outline allows you to create, name, move units and lessons. Lesson are enclosed in a unit module so that they can be moved as a set. The choice to repeat creation action on a lesson by lesson basis was an attempt to localize where the new lesson would be dropped and reduce reorder distance through the node. I explored hover based interaction and while the best experience for mouse input I wanted to remain open to touchscreens as an input method.

Lesson Overview

Sections In sections where the user chooses a lesson in the course outline, they are taken to the lesson overview page. On the lesson overview page, there are sections of content that divide the space. In viewer mode, these sections are colored tags that act as signposts through a lesson, but in edit mode they take on a more container-based appearance. There are two main reasons for this. The first reason, is because I wanted sections and their content to move together, not independently. The second reason when dragging content objects up and down a lesson page, the colored blocks establish spatial relationships. This way, when dropping an object, it was easier to identify section boundaries.

Creation Wizard When you choose a lesson in the course outline you are take to the lesson overview page. On the lesson overview page you see section of content that let you divide the space. In viewer mode these section are more just colored tags that signpost your way through a lesson, but in edit mode they take on a more container-based appearance. There are two main reasons for this. The first is that I wanted section and content within section to move together not independent. The second is that when dragging content objects up and down a lesson page the colored block establish spatial relationships and when dropping an object it was easier to identify section boundaries.

Content Creation Flow

I wanted to make the actual content creation form feel very similar in appearance to resulting card. This approach would put us in a better prepare us for the future when we can offer a more inline editing experience.

User Feedback

Where is the reading I just added?

During the sprint, it was easy to take small things for granted. Choosing to focus on the big system and framework for course authoring, gave way to microinteractions having unfortunate effects. Early feedback during the sprint suggested that users were a little jarred and resorted to reading content objects when trying to find the piece they just added. I utilized a simple animation that is triggered after the content modal is dismissed to emphasize newly added content.

Global Sections

Another topic that came up during early testing, was that many instructors were using a section scheme for their lessons. The implementation of the design I created had section names and colors scoped on a course by course basis. This often resulted in inconsistencies between lessons or authors having to choose a section tag and color, close the modal go refresh their memory of the previously authored lesson, return and edit the section name and color to match their scheme. This very common user story caused us to revisit sections to support both global and local sections.

Celebrating a Turning Point for Next Thought

After the directors demoed the new functionality to the Board of Directors and the Provost at the University of Oklahoma, we all felt the need to celebrate a company milestone. One of the project managers here at Next Thought ordered a cake fitting for occasion. The one humble blue button labeled “edit” was a symbol for the future of the platform.

Today

Today authoring tools are being used by internal staff to input course objects. We have also brought in professors from various universities and organizations as early adopters. I am currently on a project team to bring native assignments and native content creation to the platform. The next release is scheduled for end of summer 2016.

Thanks
for
reading.