Switch easily between Batch- & GUI-mode: *.ffs_batch, *.ffs_gui, *.ffs

[micha--]

@admin: please correct the topic-header to:
Switch easily between Batch- & GUI-mode: *.ffs_batch, *.ffs_gui, *.ffs

I was confused about *.ffs_batch and *.ffs_gui, if i first used FFS, because both do the same thing. The only difference: with or without GUI. Now i suggest (for 3 goals):
1. to unify the structure of *.ffs_batch & *.ffs_gui (and retaining the functionality of both)
2. to simplify the GUI for Handling with Configurations
3. to enable the GUI for switching between Batch- & GUI-mode.


1. Merge *.ffs_batch and *.ffs_gui in new unified *.ffs

The different 2. lines in *.ffs_batch:

    <?xml version="1.0" encoding="UTF-8"?>
    <FreeFileSync XmlFormat="4" XmlType="BATCH">
        <MainConfig>
            ...


and in *.ffs_gui:

    <?xml version="1.0" encoding="UTF-8"?>
    <FreeFileSync XmlFormat="4" XmlType="GUI">
        <MainConfig>
            ...


will be merged alternating to *.ffs:

    <?xml version="1.0" encoding="UTF-8"?>
    <FreeFileSync XmlFormat="4" XmlType="BATCH">  --- or: ---  <FreeFileSync XmlFormat="4" XmlType="GUI"> 
        <MainConfig>
            ...


The different last lines in *.ffs_batch:

            ...
        </MainConfig>
        <BatchConfig>
            <HandleError>Popup</HandleError>
            <ShowProgress>true</ShowProgress>
            <LogfileFolder Limit="-1"/>
        </BatchConfig>
    </FreeFileSync>


and in *.ffs_gui:

            ...
        </MainConfig>
        <GuiConfig>
            <HandleError>Popup</HandleError>
            <MiddleGridView>Action</MiddleGridView>
        </GuiConfig>
    </FreeFileSync>


will be merged as sequence to *.ffs:

            ...
        </MainConfig>
        <BatchConfig>
            <HandleError>Popup</HandleError>
            <ShowProgress>true</ShowProgress>
            <LogfileFolder Limit="-1"/>
        </BatchConfig>
        <GuiConfig>
            <HandleError>Popup</HandleError>
            <MiddleGridView>Action</MiddleGridView>
        </GuiConfig>
    </FreeFileSync>


If the extension of a *.ffs is renamed to *.ffs_batch and this is run in FFS ==> FFS sets the coresponding entry in the in *.ffs_batch file to <... XmlType="BATCH">
If the extension of a *.ffs is renamed to *.ffs_gui and this is run in FFS ==> FFS sets the coresponding entry in the in *.ffs_gui file to <... XmlType="GUI">

The GUI can change BATCH- or GUI-Mode from an *.ffs file (change the entry <... XmlType="...">).
The GUI can't change the entry <... XmlType="..."> from an *.ffs_batch nor an *.ffs_gui file.



2. The Configuration-Dialog in the GUI ... (and 2 Radio-Button for the 3. goal)

... has 5 Buttons: [New], [Open], [Save], [Save as GUI-Configuration as...], [Save as Batch-Configuration as...]
and 1 Text-Box with the lines <last_session>, <config-1>, <config-2>, ... and so on ...
The handling of the Text-Box is great: easy and intuitiv :)

I think the function of the 5 Buttons can be integrated in the Text-Box. Without the 5 Buttons the configuration-Dialog looks simpler and i hope you found my suggestion for handling the Buttons-functionality in the Text-Box more intuitiv like it is now. The 5 Buttons:

[New]: The Text-Box became a new entry: <new>, <last_session>, <config-1>, ...

[Open]: The Text-Box became a new entry at top: <open_new_configuration_file>, <new>, <last_session>, <config-1>, ...
If someone highlights it accidentally, the Escape-Key closes the opening Open-Dialog, immediately and the highlighted Cursor jumps to his old position.
The HOME- and PageUp-Keys does not highlight the first entry <open_new_configuration_file>.

[Save], [Save as GUI-Configuration as...], [Save as Batch-Configuration as...]: No Button, no new entry in the Text-Box, but a new entry in the Contextmenu (right mouse-clik): "Save/Save as...".

"Save/Save as...": opens a Dialog with 4 Buttons (one below the other) and the text right of them (for each one), but first 3 Info-lines:

> --- Dialog-Begin ---
The actual configuration file is:
<path>\
<filename>

> [Save]: overwrite the actual configuration

> Ceate a new configuration file ...
[Save as...]: ... which can be used for GUI or for Batch
[Save as GUI-Configuration as...]: ... which can be used for GUI, only
[Save as Batch-Configuration as...]: ... which can be used for Batch, only
--- Dialog-End ---

Right of the Text-Box are 2 Radio-Buttons with the text:

> start next time
(x) as GUI
( ) as Batch

This changes the entry <... XmlType="..."> in the *.ffs file, simple.
In the case of a *.ffs_batch file or a *.ffs_gui file the 2 Radio-Buttons are disabled and a Tooltip text (if the mouse is over the 2 Radio-Buttons) can explain: e.g. ... rename the file test.ffs_gui in test.ffs to enable these Radio-Buttons ...


More 3 new entrys in the Contextmenu (right mouse-clik) of the Text-Box:
"Enable GUI or Batch mode"
"Enable GUI mode, only"
"Enable Batch mode, only"
<-- only two of them are enabled, suitable the case *.ffs_batch or *.ffs_gui or *.ffs.

The Contextmenu contains one entry "Delete selected configuration DEL" (in DE: "Lösche ausgewählte Konfiguration DEL"). But there will be no file deleted, hence i suggest to rename this entry to: "Erase selected configuration from this list DEL" (in DE: "Entferne ausgewählte Konfiguration aus dieser Liste DEL"). And this Contextmenu entry should not appear for the 3 lines <open_new_configuration_file>, <new>, <last_session>.



3. Enable the Dialog of Batch-mode, to open GUI

The Dialog "Scanning..." has 2 Buttons [Pause] and [Stop]. It becames a 3. Button [Open GUI], which opens the GUI :) and continues scanning in the GUI. But after completed scanning no synchronize starts. The user must push the Button [synchronize] in the GUI, if he want it.

If the Dialog "Scanning..." (of Batch-mode) changes to "Synchronising..." the 3. Button [Open GUI] disappears.

The Dialog "Scanning..." stays for at least 7 seconds (if the Scanning is finished earlier), so the user has a chance to press the new 3. button.

[Zenju]

>1.

Your observation is correct, both GUI and Batch configurations have almost the same structure. But I'm not sure if there is much functional benefit when both are merged into a single format.
And there is one major drawback: Having two file types with different extensions allows to have different file icons. This helps the user to visually distinguish what will happen if he runs (double-clicks) a certain config file.

>2.

Having list-box entries act as buttons is unconventional and thous may confuse users, especially since it breaks the hierarchy between actions and config items. Also it's lacking the visual cues of the button's icons.

> "Delete selected configurations" [...] But there will be no file deleted

You're right, nothing will be deleted. While I don't see a difference between erase and delete, this should indeed be changed to make it clear that it won't delete the configuration, but merely the entry in the list. I'll change this, maybe: "Remove item from list".

> 3.

I'm not convinced an option to switch from Batch to GUI during runtime is needed in the normal case: I can imagine this is needed when the user accidentally started the batch run, but instead wanted to run the GUI mode instead. This type of error is probably rare and can be easily resolved by stopping the Batch run und loading the config into FFS GUI (or right-click on the .ffs_batch file and select "Edit with FreeFileSync").
It's a different story when warnings are shown: In this case there is likely something wrong and the user should investigate before proceeding further: Therefore FFS has option "Switch to GUI" present in the warning popup dialog.

[micha--]

Thank you for reading my thoughts and for discussion :)


---------------

> \1. ... GUI and Batch configurations have almost the same structure ...

Yes, both configure the same thing :) with a little difference in appearing as GUI or as Batch-Dialog.

If i write a *job.ffs_* (for me it is more easier to write a config. file, than to click in a GUI (i like your GUI, but sometimes i have the preference to write/edit :)), i begin with *job.ffs_gui* and test it in the GUI. If i install it afterwards on someone's PC, i decide to write it as *job.ffs_gui* or as *job.ffs_batch*. My functional benefit, when both are merged into a single format, is:
- i have not much to edit, by switching from *job.ffs_gui* to *job.ffs_batch* (and back again).
- and i have only one configuration file, if i need GUI and Batch (otherwise i have "the redundant problem" of two config. files).

> ... two file types ... have different file icons ... helps the user to visually distinguish what will happen ...

OK, Yes:
(4) It would help me, if we had "1 single config.file format" and 2 extensions (*.ffs_gui and *.ffs_batch) for it. And the visual cues of the button's icons, remains.

---------------

> \2. Having list-box entries act as buttons is unconventional ...

OK, i understand.

I would focus on simplifying this part of the GUI and not to much on conventionality. Fewer buttons mean less to do for the eyes. The list-box is very intuitiv: it shows the choosen config. in folder-pairs and as mode in the Synchr.-Button, immediately. I suggest (5) Remove the [new] button and insert the entry <new> at top of the list-box, this fits perfect in the intuitive behavior of the list-box. I think the hierarchy between actions and config items for [new] & <new>, is not selective: like <last session> or another config.line, <new> gives new config. settings (in this case with default values).

If you like the idea "less buttons": a second suggestion:
(6) Replace the 3 Buttons [Save], [Save as...], [Save as...] by 1 Buttons [Save...], which invokes a dialog with 3 Buttons [Save], [Save GUI-config. as...], [Save Batch-config. as...]. The dialog explains the meaning of this 3 Buttons; like i have described above (under (2.) ... '"Save/Save as...": opens a Dialog with ...'). With it you can hide "the complexity of the 3 Buttons [Save], [Save as...], [Save as...]" behind a new dialog. And the user has in his most use cases a little bit simplier UI.

I hope this may not confuse users, but helps them to quickly find their way around.

(7) The contextmenu "Delete selected configurations" can be used on <last session>, and make it disapear from the list. What a shock, but the entry comes back, after restart of FFS.

> ... nothing will be deleted ... I'll change this, maybe: "Remove item from list".

Yes, that sounds good.


(8) <last session> could also (better?) be named as <last configuration>
Edit: Did you use "session" instead of "configuration", because a configuration will only be used after running?

---------------

> \3. I'm not convinced ... switch from Batch to GUI during runtime ...

I suspect you're thinking about user safety: If someone has installed a *job.ffs_batch* and the user is not familiar with FFS-GUI (or not familiar with computers), he will not be confused, by a 3rd button [Switch to GUI], which can throw him in the FFS GUI, in which he is then completely helpless. OK, good idea i found! This function / use case should be preserved by *.ffs_batch. (and for that use case, you provide sufficient:

>... stopping the Batch run and loading the config into FFS GUI (or right-click on the .ffs_batch file and select "Edit with FreeFileSync"); when warnings are shown: ... FFS has option "Switch to GUI" present in the warning popup dialog.)

)

Users, which are familiar with FFS, like to watch the medal of the one and the other side. They don't need an artificial separation between GUI- and Batch-mode. For this users you can replace *.ffs_gui by *.ffs, with the on top described "functionality of easy switching beetween GUI- and Batch-mode".

EDIT (21.02.2015 09:33):

I suggest 2 extenisons, with 1 structure and 2 Icons:
- *.ffs_batch --> run only in Batch-mode (without a 3rd Button)
- *.ffs --> can run in Batch-mode (with a 3rd Button [Switch to GUI]) and in GUI-mode (with 2 Radio-Buttons: Start next time () as GUI () as Batch)

[blues12]

Remove from list - I like that too. Much clearer than Delete.
But the 3 Save buttons are safer than a combined dropdown, imo. I wouldn't want to accidentally overwrite one of my configs by releasing the mouse button on the wrong entry. I know it sounds stupid but it does happen, on touchpads of notebooks while traveling, or when the mouse hits obstacles in a crowded location.

It's one of the things I really like about FFS, those big buttons that you can't miss when you're on the road with shaky equipment or touchscreens.

[micha--]

> ... 3 Save buttons ... a combined dropdown

No, i suggest a seperate dialog for the Save-Buttons. Two big Buttons remain: [Open] & [Save...]. [Save...] opens a seperate dialog, with "big" Buttons, and text if necessary for explanation. <new> becomes an entry in the list-box, but if it accidentally invoked, the last configuration, comes back from <last session> or from the opened configuration file.
(Perhaps you didn't read my answer before your post? I had have update-problems with the sourceforge-side and maybe you have seen my post unready.)

[Zenju]

> It would help me, if we had "1 single config.file format" and 2 extensions (*.ffs_gui and *.ffs_batch) for it. And the visual cues of the button's icons, remains.

Certainly doable, both ffs_gui and ffs_batch could get the same structure and could be distinguised solely by their file extension. For the batch file creation dialog, this would simplify the code. The deeper question that helps to answers this is: Are ffs_gui and ffs_batch inherently one entity or two? This is important considering future design changes: Is it to be expected that the two config types and corresponding scenarios will further diverge (=> two formats) or will evolve in sync (=> one format)?

> (8) <last session> could also (better?) be named as <last configuration>
> Edit: Did you use "session" instead of "configuration", because a configuration will only be used after running?

"session" is used because this is the configuration from the last time that FFS ran.

> Users, which are familiar with FFS, like to watch the medal of the one and the other side. They don't need an artificial separation between GUI- and Batch-mode.

Agreed, but adding a "switch to GUI" buttons only during comparison seems to add no interesting functionality. Maybe there are other aspects that can be done. Generally merging both scenarios, gui and batch, into one is a win-win: There are less differences for the user to learn, and also less divergent code to maintain.

> But the 3 Save buttons are safer than a combined dropdown, imo. I wouldn't want to accidentally overwrite one of my configs by releasing the mouse button on the wrong entry. I

I believe the save buttons are used relatively frequently, so it seems okay to trade off visual screen estate in favor of ease of use as it is now.

[micha--]

> Certainly ... ffs_gui and ffs_batch ... distinguised solely by their file extension. ... one entity or two?

Yes "constructive vision"! ... Today i think, Batch-mode is a specialisation of GUI-mode: It is an automatisation of GUI-mode with user safety. Or in other words: GUI-mode gives much configuration possibilities and Batch-mode selects one of these and holds it. Hence i expect that most of the config. items of GUI-mode necessary in Batch-mode and Batch-mode need only a few other config. items. But of course I do not know if they will evolve in sync in the future. ... you have to decide ...


> "session" is used because this is the configuration from the last time that FFS ran.

Yes, i understand now :)
If you like: a tool tip text over the list-box, can make it clear for every one:
<last session> is the configuration from the last time that FFS ran.

>>Users, which are familiar with FFS, like to watch the medal of the one and the other side. They don't need an artificial separation between GUI- and Batch-mode.

> Agreed, ... Maybe ... other aspects that can be done.
... merging both scenarios ... less differences for the user to learn, and also less divergent code to maintain.

Yes :)

> I believe the save buttons ... use as it is now.

OK.

(5) [new] button --> entry <new> at top of the list-box: would result in a small simplification of the GUI, without too much change in the user guide.

(7) The contextmenu "Delete selected configurations" should not be allowed to apply to the entry <last session>.


Thank you for the constructive discussion :) and keep my ideas in your head or in the archive. I let myself be surprised what you can implement :)

And Thank You for this Top Programm, and support :) :) :)