Design

Our design is centered on helping users with ADHD focus on reading long articles. There are two main parts of our user interface:
 * Breaking down the large article into chunks for the reader to focus on. This happens in what we refer to as “Focus Mode”

• Providing a link sidebar that can keep track of the links to articles the user wants to read in the future.

Focus Mode:

• Minimizing Distractions: We help users focus on the text by presenting chunks of the information in a popup box (modal), while graying out the website itself behind the box. This ensures the user only focuses on the modal and is not the overwhelmed by the volume of material displayed. In addition, the link sidebar is automatically hidden so that the user can focus on the modal.

• Modal Design
• 
  • ** *Location: *The modal is centered in the middle of the window to draw the user’s attention.
  • *Text Length: *We present the user with small chunks of text at a time to improve readability so that he/she is not overwhelmed by all of the text on a single webpage. We use modals that contain a limited  amount of text at a time, usually about the length of two sentences. Chunk’s sizes are based on the number of sentences as opposed to number of words because full sentences help the user understand the material better.
  • *Modal Width: *The width of each modal is limited to help with readability as well.
  • Text Size: The size of the text is set to improve readability.
  • *Hyperlinks in Modal: *The hyperlinks in the modal are blue to present an affordance to the user that the links are clickable. When the links are clicked, they are added to the link sidebar, which is animated to pop out a little bit, providing visual feedback to the user that the link has been added.
  • *Images: *Images are supported and pllaced in chunks with their corresponding captions.

• Navigation through chunks
  Users can navigate through chunks by clicking on the arrow buttons in the modal or by pressing the arrow keys on the keyboard. The arrow buttons in the modal are placed in the top left corner to maintain consistency in location, regardless of modal size.

• Maintaining Context of Chunks
  Our original design completely blacked out the website in the background, but this was changed after feedback from User Testing. Users wanted to know which part of the webpage they were reading when cycling through chunks, and wanted feedback that they were progressing through the article. We decided to have a grey, translucent background so that users could see the progress they had made while reading through the chunks. We also considered having a progress bar in the modal, but decided against it because users could be tempted to click through the chunks to rush to the end without reading the chunks entirely. Another option was to display how many chunks the user has read out of the total number of chunks, but we did not add this feature to our design because long articles may be extremely intimidating to read if the total number of chunks was displayed.
• 

• Entering Focus Mode
  The user has multiple options for entering focus mode: clicking the focus button centered at the top of the webpage and clicking the chrome extension button in the chrome bar. When text is selected in the webpage, entering focus mode will only chunk the selected text; otherwise, the entire website is chunked. Leaving focus mode and re-entering will bring the user back to the chunk that the user last read.

Link Sidebar:

Adding Links

• Before the user goes into focus mode, links can be dragged and dropped into the sidebar on the right. The sidebar contains a line of instruction for this so that users understand the purpose of the sidebar, improving the learnability of the interface. In accordance with Fitt’s Law, links can be dragged anywhere near the sidebar to be added, which enhances efficiency.
• As a result of the heuristic evaluation, we learned that many people expected to add links by right clicking on the link and finding an option in the context menu, so it is also implemented in our final design.
• While in focus mode, clicking on links in the modal text will automatically add the link to the sidebar. This prevents the user from being distracted by the opening of a new webpage while trying to focus on the current article.

Removing Links

• Each link in the sidebar can be removed by clicking the “X” button to the right of the link. Users may mark links as completed when the user has finished reading the relevant article to keep track of progress through articles. 
• All of the links to completed articles can be removed simultaneously by clicking the “clear completed” button at the bottom of the link sidebar. 
• This has external consistency with Google Tasks, which also allows the user to clear completed items. 
• There is one major difference, which is that we do not strikethrough the link when it is marked as complete to keep the sidebar clearer and less cluttered.

Link Organization

• After links have been added to the sidebar, the user can drag the links around to organize them. 
• When the user has moved to another webpage or refreshed the current webpage, the list of links in the sidebar persists, with the same order. 
• A user with multiple tabs that have refocus enabled will maintain the same list of links through a single chrome session.

Visibility

• The link sidebar can be hidden and shown by clicking on the arrow at the left of the sidebar. Similar to adding links to the sidebar using drag and drop, the user can click anywhere in the left vertical strip of the sidebar to enhance efficiency. 

Help Button

• Clicking the help button in the link sidebar pops up a tooltip at the Focus button that is centered at the top of the webpage.

Implementation 

• *Chrome Extension: *We implemented our application as a Google Chrome extension. The alternate would have been to make a standalone app that allows users to input a link to an article they wish to read, and for the app to process it in a similar manner as Refocus does now. The major disadvantage of that approach is that it interferes with the transition from one article to another and is likely to break the user’s focus -- given our user population, this is something we strongly wanted to avoid. Instead, our extension interfaces seamlessly with whatever page the user happens to be on (if it is “Refocus”able), staying out of the way until the user needs to access the app’s functionality.
• *Javascript in this context: *Since our application modifies the DOM and processes only the content on that webpage, the bulk of our implementation is in Javascript (with jQuery). jQuery allowed us to easily integrate our application into the webpage for a very native feel. Additionally, jQuery provided for a simple way to collect the text and images of the article from the variety of div, paragraph, and other tags on the webpage. On the other hand, we had some difficulty implementing even the simplest backend (to allow for links to persist in the progress bar between page refreshes and navigation) because of our choice of architecture. Indeed, we ended up creating a background javascript page that stored the persistent data, and used a Google Extension-specific message passing protocol to move the data between the content scripts running on each page (article) and the background script.
• *Modular implementation: *Before we began to build the app, we planned to compartmentalize the code as much as possible to allow for easy distribution of tasks during implementation. For instance, the article parser and the progress bar, two of the biggest components of the app, were almost entirely decoupled.
• *Challenges with chunking: *One of the biggest challenges we ran into during implementation was the inconsistency of online articles in their DOM organization. We struggled to adapt our app for each of the vast variety of styles used by 3rd party sites (e.g. whether they put each paragraph into distinct <p> tags or not, whether or not all of the article content was in a particular div, etc). In the end, we solved this problem by making our app work very well on particular sites (by using site-specific parsers), while also creating a one-size-fits-all parser that did a decent job on a large variety of sites. While it is unfortunate that we could not have ideal performance on every site, we argue that this would likely be the approach taken by developers in an industry setting. The design allows for easy extensibility with more site-specific parsers, so that if we wanted to augment the extension to work on more sites in the future, it would be very straightforward to do so.

Evaluation

• In the User Studies part of the project, we were only able to test our paper prototype with fellow students, not anyone in our target user group. With more time and resources, we could have done more iterations to test and prototype our product to suit our end users more closely. We could also have focused on the User Experience more in this way (eg: how much does chunking help the user?) rather than the user interface design alone. Despite this shortcoming, the target users that tested our extension at the end said they were happy with the functionality and design.* We decided to build a Chrome extension early on without really assessing the alternative i.e. building a webpage with a panel for web browsing. We ran into trouble with the Chrome extension, especially issues with the extension’s CSS overriding the webpage’s CSS.
• Our extension had limited features because we wanted to keep it simple (especially given our target audience). Hence we got rid of a lot of potential features without testing, such as gamifying the process, more control over size and formatting of chunk etc. Given a chance to do it again, we would spend more exploring these aspects and prototyping them.
• A positive is that we focused a lot on initial User Interviews. We interviewed a variety of people, including an educator with a focus on special education. This way we got a lot of insight on what we users wanted to see, and it led to our central metaphor, chunking the page into smaller parts. We intend to do some more long-term testing with a few of our Users and eventually put the extension on the Chrome Web Store.

Reflection

• In the User Studies part of the project, we were only able to test our paper prototype with fellow students, not anyone in our target user group. With more time and resources, we could have done more iterations to test and prototype our product to suit our end users more closely. We could also have focused on the User Experience more in this way (eg: how much does chunking help the user?) rather than the user interface design alone. Despite this shortcoming, the target users that tested our extension at the end said they were happy with the functionality and design
• We decided to build a Chrome extension early on without really assessing the alternative i.e. building a webpage with a panel for web browsing. We ran into trouble with the Chrome extension, especially issues with the extension’s CSS overriding the webpage’s CSS.
• Our extension had limited features because we wanted to keep it simple (especially given our target audience). Hence we got rid of a lot of potential features without testing, such as gamifying the process, more control over size and formatting of chunk etc. Given a chance to do it again, we would spend more exploring these aspects and prototyping them.
• A positive is that we focused a lot on initial User Interviews. We interviewed a variety of people, including an educator with a focus on special education. This way we got a lot of insight on what we users wanted to see, and it led to our central metaphor, chunking the page into smaller parts.  

We intend to do some more long-term testing with a few of our Users and eventually put the extension on the Chrome Web Store.