Expanding the Toolbox
Historically on our platform content is developed and passes from professors to members of our team and ported to our platform. In that model the only way we can ship on time and not hold up classes is having all the content prepared prior to courses starting. The are several disadvantages to that model. When you are teaching in an industry that is rapidly changing, the content you are making may be outdated by the time you teach your course. Secondly it offers little flexibility for professors to modify content to match the needs of students. The solution to address those concerns is authoring tools and it has been a big part of our team’s focus over the last year. In our first phase we allowed professors to create and edit units and lessons. On lesson pages professors were able to add, remove, and organize content on their lessons. While the content itself is still created by our team. The subsequent passes on authoring tools aim to provide distinct editing environments for all the content types you can add to your lessons. The first of those authoring environments is for assignments.
- Allow Professors to be Responsive to Industry and Student Needs
- Faster Turnaround Time on Fixing Human Errors in the Course
- Create on the Platform Not in Google Docs / Slides
- Working with Native Tools Exposes Platform Capabilities & Restraints
- Separate Manpower from Growth
- Decrease Learning Curve for New Internal Content Developers
- Expand Market by Offering Affordable Alternative to White Glove Service
- Increase Sales Position by Adding Tools Supported by Our Competitors
- Reduce Burden on Developers to Fix Typos, Errors
“Being the best professor I can be means constantly changing my content to respond to the industry and to my students.”
Pain Caused by Lack of Authoring Tools Prior to authoring tools our platform necessitated that content be prepared prior to the course starting. The lack of authoring tools meant communicating changes to our team and updating content through the backend. Lack of control over courses meant professors were less likely to put in content requests that respond to changing industry standards or student needs.
Strain of Learning Multiple LMS's While doing interviews with our clients a noticeable pain point arose. While learning to use and be familiar with 1 Learning Management System can be tricky. Some of our clients have their professors engaging with up to 3 LMS’s. This pushed me to even further consider if the solution I arrived at was easy enough to understand without instructions.
Shift in Persona I am always trying to find the right inputs to stress test assumptions. While doing more and more solutions for professors I began noticing in interviews and discussions with professors that teach courses online are more tech savvy and crave more powerful tools than I anticipated. As a result it has shifted my persona of who I am designing for.
Scope & Roadmap
After deciding on a level concept. We began discussing and sharing product requirements and slotting certain features into a product roadmap. While the platform does support a wide breadth of options for assignments. It was time to take stock in what features are utilized and which features we felt confident could translate into intuitive editor. The first phase in the roadmap was an MVP of the assignment editor. It supported 6 question types. The ability to create, edit, preview, delete, and place an assignment on a lesson. In addition the editor supported drag and drop, autosave, and a range of advanced options.
The competitive audit helped set expectations around the feature set offered to faculty on alternative platforms. While our early release would not match the feature depth of alternative platforms, there were clear indications that intuitive UI could be disruptive in this market. One simple concept model can illustrate the need for why training is often not optional, but required.
Explicit Most of our competitors in the LMS space opt for objects to be made discreetly on their own and then require users to make explicit connections between them. This felt like an unnecessary amount of overhead to achieve the desired result.
Implicit I opted for an interaction model that allowed connection to be made implicitly at creation time. Basically where you created something is where it lives. You can however share and move questions and assignments afterwards.
Creating user flows helped get a high level understanding of the tasks our tool would let users accomplish. User flows help build consensus and problem solve technical challenges as we collaborated throughout the project. Producing an artifact like this also provides point of reference during conversation and has long term value as a form of documentation.
Component Based Design
After user flows I started sketching individual screens on paper. Because of speed and the value of seeing of higher fidelity rendering, I normally skip wireframes and start visualizing options in Sketch. I normally start lose and slowly and as options show merit add fidelity. I have adopted a component based of exploring and refining UI elements. Taking a component out into its own artboard allows me to really focus and start creating divergent ideas. When I feel like an element is working on its own, I’ll integrate the component back into larger flow and resolve any alignment hierarchy issues that may have occurred.
“I use a lot of integrations on other platforms and even do my own HTML/CSS.”
Assignments are one of those objects that can be infinitely complex. While we did want to simplify the experience from our competitors, we did not want to make the experience simpler than it actually is. One of the first challenges was seeing how we would represent settings and options you can have on an assignment. Here I explored two different directions that ended up both being canned. The first solution was an accordion flyout menu. There were two main issues with this solution the first is the controls that were set are not visible when the menu is closed and secondly I did not feel like it would scale well. In the second solution I explored a familiar UI pattern of including a creation wizard before arriving at the editor. One issue with this pattern is that it is often reserved for making an upfront choice, meaning that it is not necessarily expected you can modify them afterward. The second issue with this solution is the overall first impression of the product would reinforce expectations that our tools were just as complex as our competitors.
Most screens of our web application follow a common layout pattern. We set the max-width to be 1024px. We subdivide that into a 768px content area and the remainder as a sidebar area. We have consciously made this choice knowing that most of our new features ship first to our web app and are later ported to our native iPad app. Working on small design team, high return system logic like a unified layout pattern that translates to other platforms helps boost translations. While authoring tools are initially reserved to the web app experience, being conscious of this pattern and using it when appropriate is always preferred. In the case of authoring tools I decided that the content area would be reserved for the editor and the sidebar would house the library of objects for professors to add to assignments.
While there were other explorations this became the foundation for the shared anatomy between the question types. Drag and drop grippers aid in recognition of how to reorder questions and choices. As a fallback for larger and harder to drag and drop questions I included a move up and move down arrow. All of the manipulation tools are exposed without hovering to increase discoverability.
Get Out of the Way of Content
While working out global controls like bold, italic and underline, I was also working on a local control to manipulate questions. Originally I was sold on including controls toward the bottom of a question block. After critiquing with the design team, I began exploring an alternative control bar out to the side to not disrupt the flow of content.
One thing I was adamant about was how the keyboard behavior should work. There were obvious inclusions like tab to jump between fields, but I imagined another intuitive inclusion. I was exploring with dev to see if there was a way we could build it in such a way that it feels like you are editing one complete text block, allowing you traverse between previous and next fields in an intuitive way. Basically hitting enter would create a choice below the current choice similar to how hitting enter creates a new row in a text editor. Likewise hitting delete after all the choice’s content has been removed would delete the choice and focus the previous choice at the end of the row.
One aspect that came up during build out, was around network latency. I designed the question type icons to either be dragged into the scene or tapped to create an instance of that question type. That quick add behavior supported a normal user flow for professors to quick add 20 multiple choice and then go fill the content in. While that works well for users, it creates issues for how we were handling requests. Instead of disabling the button until a newly added question is created, we allowed for rapid fire add. The side effect of this was that the editor felt unresponsive in some cases because you pressed the button 5 times and only saw 2-3 until the rest were loaded in. Since development felt it would not be seamless (user would lose focus on the field) to put a placeholder editor in and swap when the actual question came back we needed to find a new solution. I proposed we insert skeleton frames that match the structure of the question type and fill in the editor controls as the questions come in. While development was able to radically reduce wait time between requests, this implementation was still useful in situations with low network connectivity.
While exploring a variety of solutions for error handling I opted for a straightforward inline error message local to the object causing the error. Because you could be saving and save be sent to the server and return with an error after you scrolled away we also collected errors in the action bar with quick links to get you to the question causing the error.
Professors Use Predetermined Amounts of Question Types
As I mentioned earlier, a typical design story for professors is creating an assignment with x number of certain question types. I wanted to support this common behavior without professors having to manually counting and recounting during the creation process like they do offline. I explored where there was datavisualization or local indicator on the question itself. In the end I thought the best location was on the question type icon itself. I thought this was a strong solution for a couple reasons. The first is that the library is always visible meaning that seeing a count is a quick glance. The second and more important reason is that it forges a connection between the action of adding a question and incrementing the number. The cause and effect have close proximity.
Icons on our platform have historically been problematic to deal with for a couple reasons. The first is that implementations solutions varied by area of the app. Some spots were good for SVG. Some places were good for an icon font. Some places were limited to a 1x asset. The other issues was the lack of bounding boxes and variety in scale that made us cautious to update icons for fear of local implementation methods. Realizing the importance of high resolution icons and consistency across the set, I collaborated with development to start expanding and consistently implementing the icon font across the platform. All icons are designed and hinted within a 16px bounding box. I utilized a grid system to negotiate the relationship between circular, square, and vertically or horizontally bias icons once at the grid level so negotiation does not have to happen with every new icon.
“Here’s the deal, our faculty is using up to 3 Learning Management Systems.”
Sweat the Details Even More
Hearing from our professors and the challenges they go through juggling up to 3 learning management systems at the same time gives you a different perspective into how important efficient and clear UI are to their ability to perform their job to the best of their ability. Many of those tools as I mentioned earlier, require training for professors to just feel comfortable conducting an online course. While professors have to grapple with complex tools, there is also the desire for more fine tune controls. Balancing giving professors power through UI and not making the experience feel complex is the key.
At one point, that communication tool was Trello for our team and it is now Jira. Going where your developers are and inserting unexpected interactions and visual design bug tickets, the same way they document server errors, ensures that design concerns are captured, tracked, and fixed. Even if it gets a medium or low priority, it is in their queue and in my experience since adopting this habit many will not forget about it.
Better Communication with QA Throughout
I always try to communicate with teams and see if there is a way to improve our internal processes. Our quality assurance team is critical in catching bugs and identifying edge cases recently raised concerns that they wanted to be included on discussions earlier and in projects and have the ability to be included in informal conversations and pivots products undergo during the development process. Two solutions we have implemented involve communicating less in direct messages and more in channels where they can follow along. The second is more formal hand off meetings at the end of buildout so QA can raise questions or concerns.
Look Ahead Sooner
I definitely have a greater appreciation for what it takes to maintain consistent patterns in the experience, over time. and across the product. Developing authoring tools in pieces is a balance between what is possible now, with what will be possible later. I have definitely learned that is not only enough to be conscious of what is coming and have thoughts about how certain patterns will scale to new environments. Finding a way to explore current projects in parallel with what is coming allows you to stress test and see how components will evolve. It will ultimately lead to shipping stronger components that scale well instead of needing to be replaced.