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

Post a Comment

Popular posts from this blog

GSoC 2022: Overview

Image
Introduction Throughout this summer I've been working on making the New Documents feature discoverable in Nautilus, a file manager for GNOME as part of the GSoC project . This post is an overview with links of the work I did together with my mentor Antonio Fernandes. Results For the project I was supposed to resolve the discoverability problem of this feature - when there are no templates in the Templates directory, the new document menu is not shown, and many users don't know about its existence. Below is a list of steps I've taken to fulfill that quest: Planning - first we had to establish a schedule for our work Research - then we had to do some research about how others implement this feature Design - afterwards we had to design a mockup for the improved feature Code - at last a prototype was made, and after several design iterations, a final MR was submitted and merged to a feature branch (not master yet), during that phase I also presented at GUADEC Future While t
Read more

GSoC 2022: Second update - Research

Image
Introduction Two weeks have passed since I started the first phase of my “Make New Documents feature discoverable” Nautilus GSoC project. It’s called “Researching the underlying problem and use cases'', and according to the timeline that was set up in my last planning post, I’m here to share our findings and results. Why do the research Before we start revamping/fixing issues with our implementation of the “New Document” feature, it’s essential that we look into other operating systems, file managers, and web apps, to see how they approach allowing the user to create files. Do not be mistaken - the intention is not to blindly copy them, but to take inspiration from them, identify potential problems with specific solutions, and find out what users may expect from us. If there’s a clear trend in some approach, there may be a valid reason to implement it. We don’t exist in a vacuum, and we are definitely able to learn from the accomplishments or mistakes of others.. Everybody, in
Read more

GSoC 2022: Fourth update - Code

Image
Introduction I published my last blog post about the design phase of my GSoC project on 17 July. It's been a month, and it's been far from uneventful. I'm going to talk about the first prototype and my short presentation at GUADEC, as well as the review from designers and the result of it - the new mockup and the second prototype. First prototype and GUADEC Following the old mockup from my last update, I prepared the first prototype of the revamped New File menu; it wasn't really functional but served its main purpose as something that the designers at mini-GUADEC could test and review. Speaking of GUADEC, I took part in the Intern Lightning Talks where I presented the old mockup - you can watch my presentation on YouTube . Me presenting the old mockup at GUADEC Intern Lightning Talks Review at mini-GUADEC Equipped with the old mockup and the first prototype, my mentor Antonio Fernandes presented the work at mini-GUADEC satelite event to the designers, and we got fol
Read more