GSoC 2022: Second update – Research

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 some way or the other, builds up on their predecessors work, and continues the everlasting chain of inspiration and creation. While doing the research one needs to take into account the different types of problems they are trying to solve and specific kinds of users that they need to focus on.

List of software to test

And so I put on my spying disguise and began my journey through the multiverse of different Operating system’s file managers and web apps:

  • Other Operating Systems
    • Windows 11 File Explorer
    • macOS 12 Finder
    • ChromeOS Files
  • Other Linux distributions
    • KDE’s Dolphin
    • Deepin File Manager
    • elementaryOS Files
  • Web apps
    • Google Drive
    • Dropbox
    • Microsoft Onedrive
    • Apple iCloud
    • Nextcloud
    • GitLab file tree web UI  — templates are offered by the text editor after creating new file

Some of them, like macOS 12 Finder, Apple iCloud and CrOS don’t have the “New Document” feature at all – they rely on an application-centric model, therefore they are ignored in the rest of the post.

Enter the matrix, (KDE) Neo(n)!

Putting a stop to the movie references here – we’ve quickly identified several common features across different implementations, and to avoid repetition, we’ve summarized them in the following matrix:

Pretty pictures

If all you wanted from this post are fancy screenshots, here are the goodies. I’ve divided the screenshots not by the implementation itself, but rather by the features I’ll be referring to.

“New” menu containing a “New Folder” submenu

All of the tested implementations except for Deepin Files moved the “New Folder” entry into a “New” submenu, which could be something we might consider doing as well. If we move the “New Folder” item into a “New” menu, we should also add a [ + ] menu button to the headerbar, since all of the web apps have one.

Windows 11 File Explorer groups the “New Folder” feature together with creating other files in one single “New” menu. Among others, it also allows creating empty zip archives no-questions-asked, perhaps because they are treated as normal folders, i.e. user can double click and “enter” them in the file explorer.

elementaryOS Files “New” menu which allows creating folders

KDE Dolphin “Create New” feature which offers “New Folder” option, among others

Gitlab file tree web UI also groups “New File” with “New directory” in one specific “+” menu, as all of the other web solutions do.

Links

KDE Neon 5.25 Dolphin, Windows 11 File Explorer and Dropbox add a “New Link” entry to the “New” menu which allows you to create a link to a file. Nautilus doesn’t even show the option to create links by default, perhaps this way of creating links is more intuitive than copy->paste link. It could be interesting to consider adding it to the “New” menu, since there may be a discoverability problem with links as well. It would require a whole new dialog, so unfortunately it’s out of scope of this project.

KDE Neon 5.25 Dolphin allows creating links from the “Create New” menu.

Windows 11 File Explorer opens a link wizard after selecting the “Create Shortcut” option.

Default entries

One of the conclusions is that the new text files and new office documents are both common features users can fairly expect us to have.

Deepin Files offering default templates for office documents and plain text files

Google Drive also creates a shortcut to each editor application’s “choose template” functionality, and there are even more default templates in the “more” submenu

OneDrive showing default templates in its specific format

Dropbox allowing to choose a specific format when selecting a general default file type

Nextcloud showing many default templates

Templates directory

Deepin 20 File Manager preserves the Templates directory functionality, but hides the directory as .Templates, while KDE Neon 5.25 Dolphin ignores the Templates directory altogether and requires creating .desktop files in .local/share/templates directory pointing to the templates, wherever they are. Although there are implementations using it, the XDG Templates directory seems not to be that much of a standard after all – XDG_DIR_TEMPLATES is a standard location, but it doesn’t look like it mandates any special behaviour at all. We are free to change how the Templates integration works!

elementaryOS Files uses the XDG Templates directory to allow the user to add more “New File” entries, just like GNOME Files

Deepin Files hides the Templates (.Templates) directory, but the functionality remains.

KDE Dolphin ignores the XDG Templates directory altogether, requiring the user to create .desktop files in .local/share/templates directory pointing to the templates.

Adding more app templates

Google Drive allows the user to add more items than the default ones by guiding users through the installation of apps, which after installing add the templates to the “New” menu, which is something we could consider doing as well.

Renaming on creation

All of the implementations (except for Google Drive and Dropbox, which open the document handling app) immediately allow the user to rename files after creation, except for Nautilus. It’s outside of the scope of this project, but important to note nonetheless.

elementaryOS Files and Deeping Files allowing the user to immediately rename the created file

KDE Dolphin opening a dialog after creating a file in which user can change the filename

Immediately opening new files in the app

All of the web apps immediately open new files in their appropriate editor applications, while all of the non-web apps don’t.

Google Docs allowing the user to choose from different templates while creating a new file

Nextcloud allowing the user to choose from different templates or a blank file before opening it in a web app

Conclusion

The research highlighted many interesting things, including how unique GNOME Files is with not grouping the “New File” and “New Directory” features, how popular it is to include default templates for office and text files in other implementations, how XDG Templates “standard” is neglected, how often the other implementations allow for renaming the files on creation or how consistent web solutions are with providing a “+” button. There’s also the matter of discoverability of the “New Link” feature, but it’s out of the scope for my project. The next phase is “Designing a mockup based on aforementioned research”, which includes asking the design team for pointers – that’s what I’ll be doing now, so I can prepare a design later. I also want to tremendously thank my mentor Antonio Fernandes, who’s credited for the awesome feature matrix, and most of the conclusions from the research. See you in the next update 🙂

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 focus on the discoverability side and the default experience of the user, meaning what happens when there are no templates in the Templates directory.

Make “New Documents” feature discoverable

Finally, the subject of my project turned out to be about resolving the accessibility issue 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. They completely ignore the Templates directory, not knowing what it does and just assuming it’s one of those “just there” directories and files. Another thing I’ll take a look at is the ability to easily add templates, without the cumbersome process of creating and copying files. I’ll also reconsider the pros and cons of default templates.

Timeline

While it’s not final, because we’ve lost our crystal balls, here’s the current anticipated schedule I’ll be following:

  1. Research the underlying problem and use cases by looking at other implementations (operating systems, file managers, web apps) (2 weeks) – 12.06-26.06 (current)
  2. Design a mockup based on above research, adhering to GNOME HIG and designers review (1 week) – 26.06-03.07
  3. Code prototype iteration in a development branch that provides a meaningful empty state, makes sure the “new documents” menu item is always shown, and the user can add more templates (2 weeks) – 03.07-17.07
  4. Test and review the prototype iteration, refine the prototype based on feedback and repeat if necessary (2 weeks) – 17.07-31.07
  5. Open a Merge Request to merge the development branch to the master branch (4 days) – 31.07-04.08

Beginning of research

As I have started the first point of my timeline/schedule, I found myself in need of many virtual machines. Equipped with powerful yet simple and elegant GNOME Boxes, I managed to run 2 different operating systems on it:

  • ChromeOS Flex – knowledge gained on how to work with libvirt xml files allowed me to figure out how to get this web centric system running in Boxes. I have documented the necessary steps in this guide, but it definitely deserves a separate blog post.
  • Windows 11 thanks to this excellent guide.

Next to try are file managers from other linuxes, and web apps; already tested macOS Finder. My next GSoC update definitely won’t lack colorful pictures.

Conclusion

The project is coming along quite smoothly, with reasonable objectives and deliverables. We’ve managed to figure out how to split the project, establish a schedule for our work, and I’ve learnt how to use GNOME Boxes to test different implementations of the “New Document” feature. I found the community very helpful and welcoming, just like my mentor Antonio Fernandes who’s very understanding and patient 🙂