GSoC 2022: Third update - Design

Introduction

It’s been a while since my last update, in which I’ve shared my research about the underlying problem and use cases of the “New Document” feature, regarding its discoverability and ease of use, as part of my Nautilus GSoC Project. Since then I’ve been focusing on the following phase of the project: “Design a mockup based on aforementioned research”, and I’m here today to share the results with you.

Use cases

Figuring out hypothetical user profiles and their use cases could prove really helpful in designing and refining prototypes, so together with my mentor Antonio Fernandes we’ve come up with the following examples:

User profile #1 - Programmer

A programmer or system administrator with a repertoire of many pre-made code snippets/basic scripts for a variety of needs. 

Use case: has to create source/script files at specific locations with the premade content.

User profile #2 - Computer science student

An aspiring programmer, who attends classes where they learn about the  basics of programming or operating systems. 

Use case: writes simple code in text editors, and needs to create many empty text files with a specific extension, i.e. ".c", in specific directories representing classes, i.e. fundamentals-of-programming/lesson-1

User profile #3 - Teacher

A teacher at school with a collection of many different materials for different classes and groups of students.

Use case: has to manage worksheets, documents and presentations in order of subjects, classes or groups of students; and accomplish that by creating directories with a topic name, and creating empty documents in that directory which they immediately want to edit.

Discussing the templates layout

While we were pondering over how to best tackle the discoverability of the “New Documents” feature in the design chat room, one interesting idea strongly stood out - changing the implementation of templates so that they have a layered structure (in the same spirit as systemd unit files), and so not only users could be able to create them, but also distributions, apps, and even administrators:

  • /usr/share/xdg/templates - distro/app packaging, when applications install template files on the system, this is the location where they are placed by default
  • /etc/xdg/templates - site customization, templates found in this directory take precedence over any of the other locations on the filesystem, this is where administrators create new templates, but also where they can create ones that override those provided by applications
  • $HOME/.Templates, or $HOME/.local/share/xdg/templates, or $HOME/.local/ - basically, nautilus should ignore XDG_TEMPLATES_DIR (Templates), and mark it as deprecated

One would of course need to figure out how to handle sandboxed applications in that case, so the overall concept is definitely a long term goal.

Mockup

After considering amount of discussion and pointers gained at the gnome-design chat room and the tremendously helpful input from Michael Bertaux in the whiteboard issue, we’ve currently developed the following mockup:



Do note that it’s by no means final - it could be iterated on many times after I prepare a code prototype or perform the usability testing, etc. I’ve actually presented two ideas there, one building up on the other - the top half part of the mockup is the short term plan, that I aim to implement during the project, and the bottom half shows the long term plan, that could be a follow up in the future. There are many things happening even considering the short term idea, so I’ll try to go over some of the most important ones:

Combining “New Folder” and “New Document” features in one single “New” menu

The research showed that almost all of the implementations moved the “New Folder” entry into a “New” submenu, which makes sense, considering there are often more features in that menu, like “New Link” (or even “New Zip” in one case), which would otherwise clutter the main context menu. So I followed that suggestion in my mockup, and in the image of the web apps, added a “+” button on the header bar, to make sure that the number of mouse clicks needed to access the “New Folder” feature stays the same, for it to become even more discoverable.

Default templates for most common types of files

Another conclusion we’ve drawn from the research is that the user may expect to be able to create new files without configuring anything prior themself. With that in mind, we would show special, default, empty file types in the menu if the user has appropriate applications installed - a text editor, and office suite.

Custom templates dialog

In order to fix the discoverability problem of the custom templates feature, we’ve come up with a dialog with a helpful empty state, in which users can easily import new templates. Such templates can also be searched, and we’re planning to extend the mockup to include the “edit” mode that will allow for removing or editing them as well. Each template would have an icon based on its MIME file type, and users would be able to instantly rename them after or when they  create them (same for the common empty file types).

Long term vision

Considering future expansion, the design proposal includes the app templates, which allows for more than just the text editor and office suite to provide empty templates for each file type. There’s also the matter of custom non-empty app templates, but we’re currently wondering whether that’s something to be handled only on the applications side.

Adjusting the timeline

Since most of the design pointers exchange has been asynchronous, the design process took a little longer than we expected - that’s why we’ve updated the timeline of the project:

  1. Research the underlying problem and use cases (3 weeks) - 12.06-03.07
  2. Design a mockup based on aforementioned research (½ week) - 03.07-07.07
  3. Code prototype iteration in a development branch (2 weeks) - 07.07-19.07
  4. Test and review the prototype iteration (1½ week) - 20.07-31.07
  5. Open a Merge Request to merge the development branch to the master branch (4 days) - 31.07-04.08

I’ve neglected the blog a little though among all of the tasks, as I’m already in the “code prototype” phase, but better late than never :'D

Conclusion

Thanks to the research and help we got both in the design chat room as well as the Whiteboard issue, we’ve managed to prepare a solid mockup, part of which I’ll implement in the next (current) stage of the project. We’ve also prepared some user profiles that will be helpful in the future review, discussed changing the layout of templates overall, and adjusted the schedule. Now it’s finally time to write some code, see you in the next update :)


Comments

Popular posts from this blog

GSoC 2022: First update - Planning

GSoC 2022: Introduction

GSoC 2022: Second update - Research