"Open with ..." context menu vs HIG

[donjan]

Context

Whenever I use Windows or OSX, I occasionally have to open a file with the non-default application. Then I’m immediately reminded of how user-friendly the “Open with …” nested context menu used to be in Gnome. Every few months, this accumulates enough irritation for me to google around for a fix.
I consistently come across comments, blog posts and threads such as

Return nautilus to classic context-menu, open options without click

In an update of some weeks ago, my nautilus context menu changed. Now, in the context-menu, the “New Document” and “Scripts” sections do not show when the cursor is positioned on them. You have to click on them or press Enter. In past versions this was not needed. When the cursor was in “New Document” automatically all the options were shown. I would like to return to the previous context-menu behavior.

(this is just the latest example and already closed)

So here’s a real world data point from a user, in direct feeback form: the new “Open with” menu is user-hostile, the old one was perfect.

Proposal

Abolish the “no nested menus” guideline in the HIG. Encouraging nested menus should be the new standard.

Discussion

Is a random highly opinionated discourse post going to change the fundamental direction of the HIG?
Maybe. I can’t know unless I try.

The reason for this assumption is anecdotal: out of the few people I asked about the “Open with” dialog, 100% prefer the old way (still the standard on Windows and OSX) compared to the mental context switch and clumsiness caused by the new window popup.
Maybe enough people inside Gnome feel the same way, and real improvement can be made.

[antoniof (António Fernandes)]

Hi, donjan

Thanks for the feedback!

I’m sure there is room for improvement in Open With. Version 43 brought a new toggle which make it simple to set a new default app for files of the same type. And, with the deprecation of GtkApplicationChooser, we are likely going to see more improvements in the next versions.

[donjan]

Hi António

Thanks for your attention.
If a user story would be informative, here’s an example of my interaction wth PDF files:

90% of the time, I want to open PDFs in Evince. Left click and it’s ready.

A few times a month I want to edit a PDF in GIMP, either to fine-tune color curves of scanned documents, censor sensitive information reliably or insert images.

Sometimes I want to re-save a PDF in LibreOffice Draw because that offers great/smart compression with up to 90% space savings while retaining legibility.
People have positively remarked on my 150KB instead of 1.5MB email attachments.

And then I occasionally want to use PDFArranger to add pages or merge documents.

Even though these are lower frequency usage patterns, there’s no need to make them feel clumsy.
It’s fine for the first time opening a file type in a new application to feel a bit more elaborate.
But after that I’d like some kind of quicklist that can be used with at most two clicks.

The previous implementation had exactly this kind of quicklist, and in just two clicks: right-click, a bit of mouse movement, left-click.
Three clicks is already a UX regression and worse than “standard” behaviour across OSs.
Four clicks is what it takes with Gnome today (right click, left click, double-click), involves a whole new window being placed somewhere and is arguably below expectations / annoying enough for people to complain regularly. As I do right now.

Similar user stories can be provided for any image format, any markup format (html, adoc, md, …), etc.
The current UX causes friction every single day.

I won’t go into solution suggestions. The implementation is up to the devs.
But let me note that OSX (shows all apps registered to handle the MIME type) or
Windows (shows recommended apps, on most versions) should be considered the baseline and possibly improved upon.

[BarryBanana (Barry)]

You could try this thing, I did and didn’t like it, but it’s worth a go.

Junction | Flathub

You could add custom entries to the context menu with python.

How to write Nautilus extensions with nautilus-python

[donjan]

I’ve written a few extensions with nautilus-python and I’m using it daily, e.g. to display the current git branch in the open directory.
That use case can be considered specialised enough to warrant the extra effort on select machines.

But I’m not going to create nautilus-python code for each (set of) MIME type(s) and manually write all the candidate applications into a text file I have to maintain and sync across computers.

When switching between my computers, coaching friends/family, troubleshooting on a coworker’s machine or just generally using a new system/VM, good default UX matters.
The file manager should do this for me, and has been doing so for years (decades?) before the regression.
W.r.t. this feature, Nautilus today is inferior to Windows Explorer or OSX Finder, and even (just checked) Dolphin and Thunar.
The latter of which may have the best quicklist implementation: flat in the context menu and probably compatible with Gnome HIG.

Thanks for suggesting Junction. Gave it a 30 second spin, it’s not what I’m looking for.

[BarryBanana (Barry)]

all good, I agree with everything you’ve said, the “open with…” situation is daft.

apologies for muddying the waters!

[antoniof (António Fernandes)]

In general, more frequent actions should take fewer clicks to perform. Indeed, opening with the default application takes fewer clicks because it’s more frequent than opening with another application.

Nevertheless, opening with another application is an important workflow for the Files app. The last time I’ve met in person with our designers, we’ve talked about it and experimented with new designs. There are many factors that designers have to take into the metaphorical equation for the maintenance of a coherent design language within and across apps.