Make the command menu and help more discoverable; also command menu items

[courtagenjim]

It looks like on (MacOS) that the commands menu/command line is displayed via: Command-Shift-P; and (external) Help is opened in a browser window via: F1. Neither of these 'entry' points for new or infrequent users are visible in the application's UI window or in its main menu (again, on MacOS). Thus, their discoverability is effectively zero.

Requests:

1. Make the commands menu discoverable by adding an explicit main menu item for it (with the keyboard shortcut also noted on the menu item).

2. Make the external help discoverable by adding an explicit main menu item for it (again with the keyboard shortcut noted on the menu).

Considerations (similar ideas, but lower priority)

3. Consider adding a static text 'Tip' to the status bar at the bottom of the application's window, saying something like: "Tip -- press: Cmd+Shift+P to open the command menu".

4. Consider adding some/all of the command menu items (Copy, Move, About, etc.) to the application's main menu.

[mherrmann]

1. and 2. are great suggestions! I'm not sure how often 3. would actually be used.

Regarding 4.: Firstly, a menu is currently only available on Mac (there is no choice: all apps on macOS have one by default). As I explained in a blog post, I am reluctant to have a menu for the other OSs. So adding Copy/Move etc. to a menu would only have an effect on Mac. As I also explain in the post, I find menus a horrible way of organising features. So my personal preference, which may be overruled if a huge number of people cry out that they must absolutely have a menu, is to not do 4.

You're right though that the existing "entry points" are bad for new/infrequent users. For new users, what I'd like to have is a tutorial (#91) inside fman the first time you start it. Basically, I'd like the tutorial to say: "You only have to remember one shortcut to use fman: Cmd+Shift+P. Everything else is in there.".

What do you think?

[courtagenjim]

I think a tutorial is a great idea. I also think that opening it, by default, on first use is fine, as long as it is easy to dismiss.
However, having that primarily (arguably, solely) only helps new users. I think the infrequent user use cases are also important. Consider a (perhaps not very command line comfortable) user who only uses fman once a quarter (or maybe once a year!) to do some bulk 'clean-up' of their drive(s). Or, they (very sporadically) re-organize their ever-growing photo collection. Or music libraries . . .
So that's why I recommend making the (fundamental) commands menu more discoverable. Given your statement that "a menu is currently only available on Mac", then I'm not sure how you would plan to make the Ctrl+Shift+P sequence discoverable on Linux and Windows. For that reason, I'd strengthen my # 3. suggestion: if there's no menu, then there should be some other (easily discoverable way, like the status bar tip text) for a user to figure out how to 'get started'. Making the 'F1' help more discoverable would also be a good idea; but if its discoverable via the command menu, then its not really needed.

[mherrmann]

Glad you like the idea of a tutorial :)

And you're right of course that the tutorial doesn't (really) help infrequent users.

I would make Ctrl+Shift+P discoverable on Linux and Windows first in the tutorial and then (as it already is) on the Shortcuts page.

You're right that it's not ideal for infrequent users. But I also must say that it's not that far-fetched for an infrequent user to - when he can't remember the shortcuts - go to fman.io and navigate to the Docs. For now, I'd still stick with 1. and 2. only.

[mherrmann]

Did you change the description? I don't think it said main menu before, did it?

[macosxguru]

The charm of fman.io is the command palette (⌘⇧ + P). Why would you want to replicate the commands in menu items?

The key differentiator between fman and every other product in this space is the command palette. Wouldn't it make sense to make that the center of interaction between the user and the application?

Why dilute it by becoming yet another two-pane Commander clone?

macosxguru

[macosxguru]

I like Michael's suggestion of a tutorial:

You're right though that the existing "entry points" are bad for new/infrequent users. For new users, what I'd like to have is a tutorial (#91) inside fman the first time you start it. Basically, I'd like the tutorial to say: "You only have to remember one shortcut to use fman: Cmd+Shift+P. Everything else is in there.".

I love this.

macosxguru

[macosxguru]

I don't understand this:

I think the infrequent user use cases are also important. Consider a (perhaps not very command line comfortable) user who only uses fman once a quarter (or maybe once a year!) to do some bulk 'clean-up' of their drive(s). Or, they (very sporadically) re-organize their ever-growing photo collection. Or music libraries . . .

This is a tool designed for keyboard friendly users. I guess that implies command line friendly people too. But do you really want to redesign a product based on the "once-a-year users" needs? I am certain that doesn't make sense. You are better off improving the product for the heavy user segment of your user base.

macosxguru

[courtagenjim]

This is a tool designed for keyboard friendly users. I guess that implies command line friendly people too. But do you really want to redesign a product based on the "once-a-year users" needs? I am certain that doesn't make sense. You are better off improving the product for the heavy user segment of your user base.

Respectfully, I believe that you are putting your own interpretation and/or conclusions on what I said. And also making some very bold assumptions about a tool that could potentially have a surprising broad user base.

Specifically: it is acceptable (but less than ideal) if the commands are not shown in the main (i.e., top of MacOS screen) menu. But only as long as they are discoverable in some other fashion. In my experience, the tutorial is not sufficient; hence my suggestion to add a static text tip which would help a user to get to the (pop-up) command line/drop-down list menu (where they should always be able get that info, hopefully).

More generally: I'm NOT trying to re-design this product! However, in my opinion, the current Apple/MacOS finder implementation is so brain-damaged that there a lot of people who would be interested in a replacement/supplement for it. I think that fman, potentially, could be a candidate for that tool. And I'd be happy to see fman take on that challenge . . .

That said, In my experience, it is perfectly possible to design an application that is highly responsive to the usage patterns of keyboard-centric users; even users who are command-line fluent; while ALSO having a way or mode of usage that supports users who are not so command-line fluent, or less keyboard-centric in general. So, I don't necessarily agree with the conclusion that: "You are better off improving the product for the heavy user segment . . .". Ultimately we're talking about Engineering design and resource trade-offs here, and product goals. It is perfectly fine for fman to only be designed for power-users of the command-line persuasion. But I think there's a broader market potentially to be served (possibly at the risk of not serving the extreme power users so well, given limited time and resources). But that's not up to me, that's a choice for the fman team to decide.

[courtagenjim]

@mherrmann -- No, I don't believe that I changed the description. Just to be clear:

• When I say: 'main menu', I mean the menu which shows up at the top of an OSX/MacOS screen (physical monitor); for your application it just has two top menu items: 'Apple' icon, and "fman". (If you did have a similar menu on Windows, then presumably it would be at the top of the fman window frame, and not at the top of the physical monitor screen.)
• When I say: 'command menu' I mean the pop-up menu (with a command line area) which is shown when a user presses Cmd+Shift+P. I hope that's clear (now).

[macosxguru]

Ultimately we're talking about Engineering design and resource trade-offs here, and product goals. It is perfectly fine for fman to only be designed for power-users of the command-line persuasion. But I think there's a broader market potentially to be served (possibly at the risk of not serving the extreme power users so well, given limited time and resources). But that's not up to me, that's a choice for the fman team to decide.

We are not agreeing on much at this point. But would your arguments change if you considered that fman is the effort of one solitary engineer? There is no team. Just Michael.

Anyway, thanks for the discussion. It was intellectually stimulating.

macosxguru

[mherrmann]

Thank you for the clarification about "main window" Jim. I must have misread the first time I looked at the issue. It's clear to me now.

You raise a very interesting question: Is fman merely a tool for power users, or is it for a much broader user base, as a replacement for Finder?

The brief answer is fman is a tool for power users. It may be tempting to target a larger user base. But fman's power precisely comes from being so focused. If I try to please everybody, I'll end up with a product that's not really appealing to either of the two groups. There are other tools which position themselves as "Finder alternatives", and they end up very bloated.

Of course that doesn't mean that I won't implement anything that makes fman more approachable. I definitely do want to do that. But not by compromising fman's core values. Instead, I'd like to do it by "converting" general users into power users. In that way, I do think fman can be a Finder replacement for general users.

I unequivocally agree with everything @macosxguru said. He's also right about limited resources: I'm a one man show (with a tremendous amount of help from users) and have to very carefully decide what to do - and what not to do. Hope you understand.