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 :)
.png)
Good article.
ReplyDeleteBe careful with your work though. Some Gnome designers used to think that the "new" menu is unnecessary in Nautilus because the user can always open the program for a file they want to create and create it from there. You may encounter pushback from them with whatever you develop if they're still in charge.
Hello, Vincent.
DeleteAs Ignacy's mentor, I would have advised him if that were the case.
The fact this project is happening proves your allegations are false.
This comment has been removed by the author.
DeleteWell. It might be false now, but I vividly remember some discussions on bugzilla with design team arguing against the "New" menu.
DeleteIf indeed the tide has turned, I'm delighted. That wouldn't be surprising considering that design team has eaten couple of shoes recently. Like with horizontal virtual desktops and app icons over thumbnails in activity view.
I wish Ignacy and you all the best with this project!
It's great to see that you put so much effort in planning the design of this feature. Taking other people's solution into account can really be helpful and avoid doing mistakes that other people already solved.
ReplyDeleteHowever, I wanted to note that Nautilus is not the only file manager that separates "New folder" from "New document" – Deepin does, too. That said, I think that this separation is actually meaningful.
Although technically, creating a document and creating a folder are very similar, I'd argue that the use cases are very different. "New folder", for example, is something you'd offer in a "save as" dialogue, while you wouldn't have "new document" there at all.
I assume the following 2 things about user behaviour:
- Users use "new folder" way more frequently: There is no other way to create a folder than using the file manager
- Not all users might use "new document" at all: Some might have a application-centric workflow (as proposed by ChomeOS)
I'd argue that keeping "new folder" on the first layer outside of the "new document" submenu is a very good form of progressive disclosure, that helps things getting things out of the users way when they perform a simple task, while not making the advanced task more complicated.