Case study: table formatting tool
A redesign of TinyMCE table formatting tool
About the project
A table is one of the most used arrangement to organize and present information in a document that is supported by most modern content editors. In the past year, I have been working on a knowledge management system, and one of my focus was to learn how to facilitate the process of content creation. From our monthly survey, we found that one of the user's greatest paint points was the table formatting tool was considered hard to use, hence we started a project to investigate and redesign the table formatting experience. The system uses an open source editor TinyMCE, so the resolution could not only apply to our system but also benefits the TinyMCE community. (The assets have been recreated to protect the confidentiality
The process: An overview
The project began with a series of interviews. We set up multiple one-on-one sessions with our users to learn about how they create a table and what challenges they encountered. The findings later became the reference during the ideation process that together with the designer, we came up with a user flow for each feature and a few proposals about how the tool should be designed.
Have the prototype in hand, I conducted a usability study with six participants to see whether the new design matched with their mental model and to identify potential usability issues. And this is when we uncovered that some of the system logic behind our design was unclear that we began to an informal competitive analysis on other editors to learn about how they approach the challenge and to come up with our own solution.
Finally, the design and detailed spec were synced with the dev team for costing, and we re-evaluated and refined some of the design elements to ensure that it can fit into the next sprint.
The Detailed Design and research process
The background - What was the problem?
As a knowledge management system, the content editor is one of the most important element since it is likely to affect people's willingness to create and share contents using our system. For over a year we had conducted a satisfaction survey every month to learn about how people feel about the system, and one of the feedback we got was that the table formatting tool we provided was hard to use. After a discussion with the team, we agreed that this issue has to be resolved as soon as possible. Hence we started a series of research and design tasks to evaluate and redesign the table formatting tool.
The research question
For the redesign project, we designed a study to answer following research questions:
- How does the user create a table?
- What features were considered essential for formatting a table?
- What challenges had the user encountered while using our table formatting tool?
To answer these questions, we conducted 13 one-on-one interviews with our users. The interview was broken down into three sections. In the first section, I asked a few questions to learn how they used to create a table (with the editor they used to use) and what table formatting features they considered essential. In the second section, I asked them to show some of the tables they created before to learn what kind of formats they had applied to the table. Lastly, the user was asked to recreate one of their table in our system which is for me to learn about the usability issue with our table formatting tool. After the interview, following insights were generated.
How does the user create a table?
Most the users were used to use offline editors such as Word and Powerpoint to create their content, so they rarely create a table from scratch in our system. So except for tables that were small and simple, they preferred to create the table somewhere else and pasted it into our system. The user was expecting the system to provide a better copy/paste support that all source formats can be carried over.
What features were considered essential for formatting a table?
Some of the most important table formatting features are
- Merge/unmerge cells
- Cell border properties
- Cell shadings (colors)
- Text alignment (within the cell)
- Table alignment (Left, Right, Center)
- Distribute columns
- Apply templates
Sometimes the user might create a table template with all the formatting being set. This includes border properties, the text alignment, and cell shadings. However, the user reported that they often need to modify the content after entering it into our system, so they are expecting the system to provide some of the most commonly used format options.
What challenges had the user encountered while using our table formatting tool?
By observing how our table formatting tool is being used, we were able to identify following usability issues. And because of these challenges, many users would rather take a screenshot and paste the table into the content as an image instead of creating a real table. Doing this not only make the file size unnecessarily large but also causes accessibility issues since the screen reader can not access the table content.
- Users spent a significant amount of time to recreate and redesign the table when putting them into our system since we remove most of the formats and shrink the table down to fit into the page.
- Although most of the features users asked for were already existed in our editor, users were either unable to find the control option or were confused by how the setting works.
- Some of the table control options were considered cumbersome, especially for adding borders to cells.
- Without additional explanation, some users were unable to understand the terminology we used in the table and cell properties dialogue boxes that some of the terminologies we used did not align with what other text editors were using, and some features work differently but have the same name.
- The user was confused by different dialogue boxes for table properties settings. They often have to try different options to figure out how the system works.
- A lot of table control options are hidden inside the menu bar or right-click menu hence it was hard for the user to locate the control options. And although the table has its own toolbar, some of the most commonly used features were not accessible through the toolbar.
The design direction
Based on the insights, we suggested following table formatting control changes and improvements.
- Enhance current table control options by moving some of the most commonly used options from right-click menu to the top or table toolbar, so they are always visible and accessible.
- Use icon labels instead of text labels for some of the control options. (e.g., border settings and text alignment) In the meanwhile, use the text label or tooltip to show what the icon means.
- Allow the user to preview the outcome of the settings in real-time before applying.
- Refine the copy/paste to keep as many source formats as possible and to remove only unsupported formats
- Keep setting options and controls for one property in one dialogue box or tab, so users know what needs to be set and how to set it.
- Solution design and competitive analysis
On top of all the recommendation, one important thing that needed to be taken into account was how do we expect people to create a table in our system? As a knowledge management system, we restricted our user to use different font color, font style, and font size so that every content in our system has a universal look and layout. So for tables, should we provide a robust tool that can be used to create any kind of tables? Or should we provide minimum functions just enough for the user to get their work done? After a discussion with the team, we decided that the new UI should give people access to all the features our users considered essential. And to reduce the mental load of the user to locate each feature, we attempted to redesign the toolbar so some of the most commonly used features can be accessed easily.
With the comp in hand, we invited six users to try out the new design. Some of the key design questions that we would like to find out were:
- Could the user understand what each icon on the toolbar means?
- Could the user understand how to create a new table?
- Could the user understand how to apply cell shading?
- Could the user understand how to apply cell borders?
- What does user expect the borders to be set while the table is being created? Should it be no border or all border?
Overall, we got positive feedback on our design. Some of the icons were confusing, but it was not hard for our designer to come up with an alternative design. However, we found that all users were confused by how to apply cell borders. The icon and control seemed straightforward. However, users had a different expectation of how border settings work. If top border of the cell was selected but the lower border is unselected, will the system removed the top border of the lower cell? If This whole row was selected and the right border was applied, will it add the right border only to the last cell or every cell in the row? And will the icon on the toolbar reflect the current state of borders or it will work as an "Apply changes" button? If so, what will button look like when there are mixed settings? Our design did not take these questions into account, so we decided to go back and re-evaluate our solution.
The challenge: Borders
One thing we were curious about was that we had never heard people complaining about the table formatting tool in Microsoft Word or Google Docs are hard to use, so we decided that we should do a heuristic evaluation on these two editors to learn about how they handle cell borders. To our surprised, Microsoft Word and Google Docs approach the challenge from two very different ways.
In Google Docs, to format a border, you have to select the border first. Google Docs separated the border control options from other table properties that the user will have to click on the cell, select which border to modify, and then select what changes they want to make. This was considered an effective way to approach to problem since the user can always know which border will be changed, but it takes some time to learn how it works since the control does not align with other modern text editors, and you can only modify either one side or all sides of borders at a time.
Microsoft Word, on the other hand, provided a very complicated way to control borders. However, although the control and dialogue were considered cumbersome, they resolve the possible usability issues by introducing the preview feature. During our interviews, we found that most of the user tried to hover over the border settings to preview the outcome before applying the changes. Even though they were unsure about how the system works, they could still quickly get the desired outcome because of the robust preview feature. Unfortunately, due to the limited dev resources, implementing the preview feature might not be feasible, so we will have to come up with an alternative solution.
Finally, we came up with a solution that might resolve the challenge. We broke the border control down into two parts, remove and add/modify. For the users who would like to remove the border, they will first select the remove option and then decide what border will be removed, and they will have to do the same if they would like to add/modify borders. All the buttons on the toolbar will now become "Apply changes" button that it tells "What change will be applied" instead of "What current settings are," and all the changes will only apply to selected cells instead of the whole table.
Although we were a little concern about whether our users can comprehend the new user flow, it turned out that everyone was able to understand how it works without any additional instruction. Hence we decided that this could be the resolution of the border control. The proposal together with a detailed feature spec I created was later sent to the dev team to evaluate the cost, and it is now being implemented.
One question that I am always asking myself is "Am I satisfied with the solution," and sometimes it is a bit hard to answer this question. With limited time (less than a month) and dev resource, I believed that we had come up with the best solution at the time. However, we are still waiting to see how our users feel about the update after they start using it to create and edit content in our system. This is definitly not the optimal solution, but with more user research and evaluation in the future, I am confident that the design could not only benefit out users but the whole TinyMCE community.