Close tab action

[rdeltour]

Tab-based UIs on macOS usually have a "Close Tab" action in addition to "Close Window". See how it's described in Apple's guidelines.

On macOS I would expect the file menu to have:

• Close Tab - Cmd+W (possibly greyed out when there's a single tab)
• Close Window - Cmd+W (when there's a single tab) or Shift+Cmd+W (when there's multiple tabs open)

It is related to general tab/name/window relationship (see also #83). If a job's lifecycle is tied to its tab, then the "Cancel job" action is the same as "Close tab", right? "Cancel job" does kinda sound odd to me when the job is not running btw.

[marisademeglio]

I have purposely chosen "job" instead of "tab" because it seems a little more meaningful and also the idea of a tabbed interface was being questioned at earlier stages so I didn't want to tie everything to the word "tab". Although I know with tabbed interfaces it common to see "tab" spelled out. As the saying goes, though, I don't really have a strong opinion here.

I think "cancel job" makes sense when the job has not been submitted. While the job is running, you should not be able to do anything to stop it (I don't think). And when the job is done, it used to say "delete job", but we got feedback to change that (https://github.com/daisy/pipeline-ui/issues/81) and I forget what it says now.

A quick check of firefox and chrome shows "Close Tab - cmd+W" and "Close Window - shift+cmd+W" are both always active even when there's just one tab.

[marisademeglio]

We should find out what the equivalent convention is on Windows too.

[NPavie]

On Windows, if I look at browsers like edge and firefox, tabs are closed when using Ctrl+w, and the window is closed with ctrl+shift+w.

[bertfrees]

I have purposely chosen "job" instead of "tab" because it seems a little more meaningful

When there is a meaningful name for a tab like in this case, I think it indeed makes sense to use that. E.g. Acrobat Reader has "Close File". And indeed also good point about not tying everything to tabs.

I think "cancel job" makes sense when the job has not been submitted. While the job is running, you should not be able to do anything to stop it (I don't think). And when the job is done, it used to say "delete job", but we got feedback to change that (#81) and I forget what it says now.

It would be fine to have "Close Job"/"Close Tab" for all cases. But if the close action has a certain meaning depending on the state of the job, it also makes sense to make that explicit in the name I think.

• "Cancel Job" when not submitted yet.
• "Close Job" or "Hide Job" when running. "Cancel Job" is indeed not something we can really do at the moment. We could however have an action that fakes it by letting the job finish on the server and then deleting it. It will keep taking up resources but for the user it will seem like it has been cancelled. Not sure if this is a good idea though because it is misleading.
• "Close Job" when finished. (We want to reserve "Delete Job" for when we've added persistence to the picture and the job was previously saved. The other reason for avoiding "delete" for now is that it may cause confusion about what happens with the results in the results folder.)

[rdeltour]

• "Cancel Job" when not submitted yet.

Personally I'm not a fan of "Cancel Job" there. To me, "cancel" better applies to something which has started or had some kind of work done or planned. It sounds odd for new job tabs (no script selected yet) or even when a script was selected but not other config was made.

"Close Job" works reasonably well in all cases. With possibly some tweaks or warnings depending on what it implies on the job's data, when we add persistence.

[bertfrees]

It sounds odd for new job tabs (no script selected yet) or even when a script was selected but not other config was made.

Yes, I can see where you're coming from and I don't have a problem with changing it to "Close Job".

[marisademeglio]

Ok this is sort of a duplicate of https://github.com/daisy/pipeline-ui/issues/81 regarding using "Close job", so that part is fixed.

It might also be a good future idea to use Close window vs close tab (with two different shortcuts), as discussed here, so I'm leaving this issue open but with no milestone.