Developing Slate

Slate is a flexible file-based productivity app for people with deadlines.

We (that’s Aviel Resnick, Zack Robinson, and Jaehyuk Lim) reimagined the typical frustration-filled experience of managing files on your local computer by building an intuitive and adaptable drag-and-drop interface.

Introduction

Motivation

The way we organize files on our computers hasn’t changed since 1965, but the tasks we need our computers to accomplish have expanded massively. If you’re reading this, odds are that you do all or substantially all of your work on a computer. Furthermore, you likely need to open and organize files of a wide variety of types for incredibly varied reasons. The exact files you need might depend on your occupation: perhaps you need to access your lesson plans, or your receipts, or essays, or class readings, or PowerPoint presentations, or source code files or textbook PDFs or pay stubs or interview recordings or raw data files or a million other things. Or all of the above, or something completely different.

You can attempt to organize files into endless hierarchies of nested folders by class, subject, category, or other criteria, but this is often incredibly time-consuming. An organization system that is difficult to use will invariably be shoved aside in favor of a single folder named “misc.” At least, that’s been our experience as students.

Additionally, students, teachers, and professors (along with many professionals) often find themselves needing a file for some defined period of time, or associated with a particular day or week — whether now or in the future. A student might have a reading they need to complete before a particular class session; a teacher might have a quiz that they’re working on that they plan to give at that same class. An executive might have a pile of reimbursement receipts associated with a business trip on a certain date. Existing filesystems have no support for this sort of information: they can store when a file was created or modified, but don’t support any sort of information about when a file is expected to be needed.

Some existing apps provide views that move beyond the traditional filesystem hierarchy approach. We took a lot of cues from Trello, which has drag-and-drop “cards” that can represent tasks, pieces of information, or goals. But Trello is a cloud collaboration system at heart, and doesn’t have any sort of first-class support for files on your local computer. Despite the proliferation of cloud services, much of our digital life still stays on our local drives (whether by choice or by technical limitation).

Solution

Slate provides a drag-and-drop, time-focused interface for managing your files. You can import files into the application one-by-one or entire folders at a time. Then, you can organize files into columns separated by whatever system works best for you. Finally, you can organize by date (whether in the past or in the future). Once you’ve got everything visible in front of you, simply click the “Open” button on any file to open it up in the app you already use.

We’ve started using the prototype app ourselves to organize some of our files for both CIS 4120/5120 and other classes, which has helped greatly with iteration — we are our own harshest critics! Additionally, we solicited feedback on our final prototype from several peers with similarly busy schedules. One commented “Wait, this is actually really useful!” Another described it as “intuitive, aesthetically pleasing — definitely something I could use in my workflow.”

Process

Ideation and Initial Interviews

Note: this stage was accomplished individually by Avi as part of Assignment 2.

The original target audience was school teachers, and so we wanted to create a digital tool that would help teachers manage their classrooms or communicate knowledge to their students more effectively. Avi interviewed three teachers to understand their needs. Interview questions included:

• How do you incorporate technology (apps or websites) into your teaching methods and classroom activities?
• Can you provide specific examples of how technology has impacted your teaching?
• What digital content or resources do you rely on for lesson planning and teaching? (e.g., educational websites, apps, online textbooks)
• How do you discover and evaluate new digital resources for your teaching?
• What features or qualities do you find most valuable in the digital resources you use?
• How do you communicate with students, parents, and colleagues using technology?
• Are there any tools or platforms you prefer for communicating and collaborating with other teachers or staff members?
• How do you use technology for student assessment and data management?
• What tools or software do you use to track student progress and manage grading?
• Are there any specific features or functionalities you wish were available to make data management and assessment easier?
• What are the biggest challenges you face when using technology in the classroom?
• Are there any frustrations or pain points you encounter regularly in your tech-related tasks as a teacher?
• What aspects or features of tools that you already use do you find valuable? Frustrating?
• Imagine an ideal user interface that could help you in your teaching. What features or functionalities would it have?
• How do you envision this user interface enhancing your daily teaching tasks?
• Are there any specific areas or aspects of teaching where you believe technology could make a significant difference?
• Is there anything else you would like to share regarding your experiences with technology in teaching?

Our interview participants were:

• Anna: Middle school mathematics; over 20 years of experience.
• Yisroel: Middle school science and social studies; 5 years of teaching experience.
• Melissa: Kindergarten and first grade at a Montessori school; over 20 years of teaching experience.

These interviews gave us a wide view of the problems teachers experienced with technology, and some ideas for potential solutions. In particular, multiple interviewees mentioned difficulty in managing assignments, worksheets, and returned work from students. Yisroel noted that “Saving projects (tons of submissions) is not well organized, so some way to organize student submissions would be useful.” Melissa demonstrated her physical organization system consisting of accordion binders for each class that were physically organized by date, and noted that for her worksheets, “I have many folders inside of folders, and it is not easy to find what I am looking for. The accordions work better because I can see all of the units and search exactly where I need to.”

Based on this information, Avi created the following narrative scenario:

Melissa teaches all subjects for kindergarten and first grades at her school, which leaves her with an enormous amount of teaching materials organized in Google Drive. Whenever she needs to find a worksheet to print out, she needs to go from folder to subfolder, which is ineffective and time-consuming. She decides to switch to [NAME], which organizes her materials according to subject and unit on a timeline, which lets her immediately find all the materials that she needs for the week. She can color-code files based on type (in-class, homework, project, assessment, etc.) and quickly pick out the files that she is looking for. This saves her hours of searching for files, streamlining lesson planning and preparation.

We also considered draft narrative scenarios for automating Montessori-style non-numerical grading and improving math typesetting.

Based on the narrative scenario, Avi made a simple sketch of an interface. Aside from the orientation (horizontal instead of vertical), this prototype sketch is strikingly similar to the final design for Slate, with categories on one axis and time on the other.

An initial lo-fi sketch for what would become Slate.

Lo-Fi Prototyping

At this point, Zack and Jaehyuk joined the team.

Based on the initial conversations with teachers, we created three low-fidelity prototypes to get a rough idea of the solutions that would work best for our target market. At this point, we were still expecting the app to be used only by teachers; later, we would realize that what worked for organizing by class would also work for organizing by many other things. We took these prototypes back to two of the initial interviewees for their feedback.

Prototype 2 was a card-based interface.

Prototype 3 was modeled after the original folder design

Interaction videos for Prototype 1, Prototype 2, and Prototype 3 are available.

Prototype 2 was the first prototype to incorporate the “card” feature and a file importer. Both evaluators preferred this layout, as they found it intuitive to use, particularly the drag-and-drop aspect. The primary points of concern were in visibility: our evaluators thought that the two classes visible on the screen were not enough and emphasized the importance of viewing all classes at once. They did feel that the amount of screen real estate taken by the import feature was unnecessary, especially considering that it would only be used occasionally. (We downsized it and moved it to a sidebar as a result.) The teachers we interviewed also expressed significant concerns about a mobile application as expressed in Prototype 1, since their use of a mobile device in class for any reason might be perceived as unprofessional and would set a bad example. This caused us to refocus towards a desktop-form-factor application.

Based on the feedback from our second round of interviews, we created a final low-fidelity prototype, similar to Prototype 2 with an adjustable import bar and collapsible columns. You can watch a video of the prototype here.

Our final lo-fi prototype

Hi-Fi Prototyping

The style choices of our app ended up evolving significantly in the prototyping and development stage, as we began to realize that our app wasn’t just suitable for teachers but also for students such as ourselves and anyone with a lot of time-based work.

Our initial mood board was inspired by classic classroom aesthetics, evoking themes of familiarity, organization, and planning.

Our mood board.

Our initial style guide featured a chalkboard aesthetic.

We used this style guide, along with the lo-fi prototype, to develop our first draft of an interface mockup using Figma. Upon opening the app, users would see columns containing their cards, along with a top bar with an import button, trash can, “add” button, and settings.

Mirroring the behavior of physical cards, we mocked up an action to collapse cards into a stack on a per-week basis. We also added a “folded edge” detail at the top right corner. Both of these details were unimplemented in the final version for technical reasons.

The import screen showed a list of cards that could be added based on a particular location in the filesystem.

In class, we conducted a heuristic usability test to evaluate the suitability of our design.

We found that clear visibility and affordances were present for most actions, although we might want some additional signifiers:

• To show drag-and-drop ability (e.g. arrows)
• Depth and/or shading to show scrollability

The match between the system and the real world seemed positive, and the flexibility of the interface gives users a lot of opportunity to shape it to their needs.

We also received some additional suggestions for features to increase user control and flexibility:

• Additional zoom levels beyond simply week/unit view, for very busy classes
• A toggle between conceptual organization (the current prototype, i.e. with files organized by class first, then time) and temporal organization (a more calendar-like view of the exact upcoming files a teacher might need)
• A feature to quickly access commonly-used documents such as a syllabus for a particular class, or the ability to assign documents to a specific time
• Google Docs/Canvas/Dropbox import feature for files, and some ability to preview non-text files such as audio or video

There were some issues with our visual design, though; the chalkboard aesthetic was cute, but very problematic when it came to ensuring good contrast ratios. The abundance of plus signs within the page was also distracting and probably unnecessary, and the font size might be too large for the desktop environment.

Based on this feedback, we redid the color scheme and styling:

Our new style guide.

Updated interface.

A draft for a potential calendar view.

And added options for Google Drive and Dropbox imports.

The calendar view and cloud file imports ended up confined to the Figma design. They would have been nice to have in the actual working output, but ended up being left out due to technical constraints.

After reworking our design based on class feedback, we created more recent releases for further user evaluation.

First, we asked another elementary school teacher.

They gave us a lot of feedback about shifting between the calendar view and column view, which we unfortunately weren’t able to put into practice in our interactive prototype — for example, the ability to set durations for files. They also personally disliked italics, which was informative as this was not the last time we would rework the styling of the app.

We also met with Anna again over Zoom.

They suggested incorporating a print shortcut for both PDF and DOCX files, emphasizing that this is the most common operation for classroom files. (Turns out this is weirdly difficult.) Also, they did not identify the “new class” creation button quickly, and we ended up reworking our UI later to make the “new column” button more obvious.

Overall, they were impressed by the design aesthetics and enthusiastic about its potential.

We also got feedback from Prof. Metaxa on the design and functionality of our revised hi-fidelity prototype. The professor suggested that the background of the app was too severe and recommended opting for a lighter tone, and tweaking the font size used for cards. Some of their other recommendations were:

• One-click zooming into stacks of cards
• A feature to accommodate different levels of class within the app (such as via double-width columns)
• Avoiding redundancy, for instance, for multiple sections of the same class.

Interactive Prototyping

Before we started building our interactive prototype, we decided to pivot the application somewhat from a specifically teacher-focused app (until that point named TimeFinder) to a more generic file-based organization system, Slate. Opening up the target audience made it a lot easier to find test subjects, and also made it into something we ourselves might want to use.

At this point, we were ready to start programming. Based on the need to interact directly with the user’s filesystem, we realized quickly that we would need to build a desktop application. So, to make cross-platform use easy and to take advantage of technologies our team was already familiar with, we chose to make an Electron app. This also made it extremely easy for our users to try out: we could send them a file instead of attempting to serve them the app content over the internet.

We met with our TA, bringing along an early draft of our interactive prototype. Our TA pointed out that integrating backend features like Google API and enhancing the calendar view could present some challenges (and in fact they did).

Then, we went to some new users in a variety of positions to see what they thought of Slate.

Tester A, who works as a supply chain project manager in the aerospace industry, explored version 0.1.6. They were particularly impressed with the color-coding system, finding it highly effective for identifying and categorizing similar types of files. However, Tester A pointed out the absence of a week-view, a feature they believe would be incredibly beneficial for planning and reviewing tasks on a weekly basis.

They had some useful feedback and feature suggestions for us:

• They wanted a week-by-week view in addition to a potential calendar view.
• The app didn’t support renaming files directly, which could potentially hinder the efficiency of file management.
• The process for uploading files also seemed unclear to them. It was not evident whether a date should be selected before uploading a file or if the file could be uploaded first and then organized by date. The app supports either workflow, but we might consider adding additional tutorials or other signifiers if taking this to production.
• Like many other evaluators, Tester A was a big fan of a potential customizable background and color feature.
• Tester A was very confused by a button labeled “reset cards.” This was a button used during development to reset the entire state of the application, which we later hid behind a special key combination.

Tester B, a Computer Science student at Penn, tested version 0.2. They had some other feedback:

• A feature to create a “new note” within the application. (This was planned in the hi-fi prototype but not yet implemented at the time of testing. Still, it was a good vote for prioritizing the note display.)
• The ability to drag entire columns around within the interface.

Tester B evaluating our user interface.

Overall the feedback from Tester B was positive, saying that it “looks pretty good” and that they can see how this app can be useful for Computer Science students who have to organize and keep track of a diverse array of files from multiple classes and projects.

Experimental Evaluation and Analysis

At this point, we had a somewhat trivial user interface disagreement among two team members. Namely: should we have users open a file using a button marked “open:”

Or through double-clicking the card?

We thought this question was a good one to answer through a quantitative experiment such as a time-to-complete task.

We devised a study plan where we would ask users to:

• Import about 3 files most relevant to them this week from a directory or directories.
• Organize these files into up to 3 columns/classes.
• Open three files.

We then switched to the other interface variant (“button” or “double-click”) and ask the participant to repeat their actions. We alternated which interface variant is used first, to hopefully control for “learning” effects.

Before the start of the experiment, we briefly demonstrated drag-and-drop functionality of the interface, since this is a very obvious interaction once demonstrated but isn’t immediately obvious from the bare interface.

We measured the following dependent variables:

Time: Time to complete steps 2–4, measured using a stopwatch.

Questionnaire: After each run-through, we will ask participants to fill out a questionnaire rating the following factors on a 1–7 scale (1: Extremely Easy; 7: Extremely Hard):

• How easily could you figure out the purpose of the app?
• How easy was it to navigate through files within the app?
• Rate the ease of organizing files into columns or classes.
• Intuitiveness of Opening Files

Conducting our quantitative study!

Aside from the quantitative and survey data we collected, we also observed each user’s attempt to work with our software. Our first two test subjects didn’t understand the drag-and-drop behavior of the interface (and so we started demonstrating the drag-and-drop functions before starting the test). While some users instantly and intuitively understood the double-click function, most were very confused by it, and found the button method faster and more obvious. Almost all testers volunteered that they thought the button method was better (both testers saw both variants). In other areas: One of our subjects thought that the trash can was very invisible and didn’t notice it at first. Prof. Metaxa wondered if the “Slate” mark at the top was completely necessary; it could probably be allocated to more button space. Finally, one of our subjects initially attempted to import files by dragging files from the system file explorer onto the app instead of using the import button. This was something that we could look into implementing, and might if this was a real app, but was too technically complex for the time we had.

We conducted a statistical analysis on the time-of-completion task, and unfortunately found no significant difference (p = 0.320). That said, while the statistical analysis showed no significant difference in task completion time between the button and double click variants, the subjective ratings provided valuable user feedback indicating the button variant provided an easier and more intuitive user experience for some participants. Specifically, the button variant received lower (i.e. better) ratings from some users on ease of navigation and intuitiveness of opening files. Even though the button may not improve efficiency based on task time, the qualitative feedback on usability and the fact that some subset of users find this variant more user-friendly means it can still improve subjective user experience. So, we ended up going with the button system.

System

Slate is centered around a drag-and-droppable, file-first interface. Files (and notes) are represented as cards, which are organized according to user created columns and ordered with respect to user-determined dates based on when the files are needed. We sought to make set-up as simple as possible, while giving users the flexibility to organize their files and notes according to their needs.

Column Creation

Users can create and rename columns according to their category needs, for example, students can create a category for each of their classes. The “New Column” button is located on the right side of the top navigation bar, which we dedicated to the creation section (new column, new card).

Based on user-testing, organizing according to date is the most flexible and useful metric that users want to use to sort files.

File Import

To generate Slate cards corresponding to files, users can navigate to our import menu via the “New Card” button, which accelerates the process of card creation for single files or entire directories. Slate integrates directly with existing filesystems, and generates cards for all files in a specified folder, which are initially housed in the import column. Then, users can drag-and-drop cards (which each contain the file name, title, and file extension) out of the import column, and into any existing column. Cards are color-coordinated according to their file-type.

Card Organization

Within each column, users can create any number of “dates” and group cards according to when the files are needed. For example, students can store files on the days that they are due, thereby keeping track of what files are more immediately important.

Opening Files

Files can be easily opened from the corresponding card by clicking on the “open” icon, next to the file type. Slate supports the full suite of OS-supported file types, and opens using the default app for each type of file.

Custom Notes

Slate also allows for the creation of note-cards, which users can drag-and-drop just like file cards. Notes can be created via the “New Card” menu, and with full markdown support they are a flexible way to combine to-do lists and other written productivity messages in close proximity with files.

Final Evaluation

As Slate became more of a mature application, we found that we were able to use it ourselves to organize our own digital lives. There’s certainly several features that it still needs — notably, a calendar view, more robust date support, and miscellaneous backend improvements — but we’ve found that it’s a remarkably effective solution even in a limited state.

We also solicited feedback from several other students at Penn and elsewhere on the final version. Many of them were big fans.

It’s intuitive, aesthetically pleasing — definitely something I could use in my workflow.
— Tiffany Toh, EE/BME student

Wait, this is actually really useful!
— Katelyn DePaula, CMPE student

During our poster presentation, Steven from our class also offered valuable feedback about our final output. After trying all the features of the app and validating the ease with which he could navigate through and organize the files in your directory, Steven asked for the release link for the latest version of Slate, suggesting that he may use it for personal use or for further development. We were delighted by the possibility of other developers in the open-source community building on our design and implementing further features.

Finally, after our final presentation, Tester A, the aerospace product manager, tried our latest release (version 0.4). They were pleased to see the added note card and folder import feature and noted that this app has become suitable for practical use in their work.

Conclusion

Overall, Slate evolved into a very practical productivity tool that reinvents the typical productivity app. In today’s digital world, most productive tasks involve interacting with a file, and default file storage solutions are not optimized to save users time. Slate combines the flexibility and user-friendliness of productivity tools like Trello, with a new way to organize and interact with files, saving our users time with every click. Our user-feedback confirmed the issues that our team found with alternative solutions, and affirmed our design choices when interacting with the final product.

Of course, there are a number of features that we would have loved to develop, and hope to implement in the future. For example, we designed mockups of a calendar view, which reorganizes existing cards from columns according to a weekly and monthly overview of files. We also suggest adding customization features including custom backgrounds, and choosing custom card colors (beyond the current extension-based coloring.

Designing and implementing Slate has been a truly educational and rewarding experience, and we want to thank Prof. Metaxa and the course teaching staff for all of their support throughout the class. Additionally, we want to thank all of the users who provided the feedback that turned Slate into what it is today.

Links

The GitHub repository for all of Slate’s code (licensed under GPLv3) is at RobinsonZ/slate. You can download the fully built application for macOS and Windows from the releases page. (Note that the macOS binaries are unsigned, so you’ll have to right-click on them and select “Open” before it’ll let you use the app.)

Our poster is here and our presentation slides are here.

Our video demonstration: