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

The Bargain-Finder-inator 5000: One programmer's quest for a new flat

Image
 The Bargain-Finder-inator 5000: One programmer's quest for a new flat Or how I managed to get a reasonably priced apartment offer despite estate agencies I think every one of us had to go through the hell that's searching for a new place to live. The reasons may be of all kinds, starting with moving between jobs or random life events, ending with your landlord wanting to raise your rent for fixing his couch despite your 3 years of begging for him to do so. You can guess my reasoning from that totally not suspiciously specific example, one thing's for certain - many of us, not lucky enough to be on their own yet, have to go through that not very delightful experience. One major problem when scraping those online market websites, is that you're not the only one desperately doing so. And if it was only for the fellow lost souls who are trying to make ends meet, oh no - many real estate agencies say hello there as well. So when a very good offer finally comes up, one that
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: First update - Planning

Introduction This summer I'm contributing to Nautilus as part of GSoC, focusing on improving the discoverability of the new document feature. In this post I will describe how the project was split between me and Utkarsh, briefly go over the schedule established for my work, and briefly mention my current research in GNOME Boxes . The split The initial short project idea assumed that only one student was going to work on it, so when both me and Utkarsh Gandhi were accepted, we had quite an unexpected situation. Fortunately, the fact that the project had many stretch goals allowed us to split it so that both of us can work independently. The unexpected situation has taught us to share tasks in a meaningful way, which has made us all the more able to grow at our assignments, furthermore we have learned how to work without blocking each other's progress. Most of the initial tasks that aim to revamp the UI and the code of the New Document menu go to Utkarsh, while I'm going to
Read more