organize config files in obvious place

[filefolder]

currently the .cfg files are in seed_vault/service/ which I admit I often have trouble remembering/finding.

would it be better to create a "config" folder in the root directory to store these? config_template.cfg can stay where it is.

[bmotevalli]

Those files are supposed to be used internally by the app, hence, it makes sense to locate it close to the place where it is going to be consumed by the scripts. For users, they can use Export/Import functionality to get the config file. Or at most, we can add a Download Config Template button somewhere (e.g. in settings), to get the template with default values.

[filefolder]

I see. I'm not actually seeing where the import or export config buttons are?

Philosophically I see the GUI as primarily a front end to populate the config file so with every click and change I wonder what's going on with the settings. I tend to assume that once people know what they want they will mostly just use the CLI version to make minor edits with relevant dates, but maybe that's "advanced user" thinking.

As a tangent, in the current version of master all of the config settings are shown on page 2 of continuous downloads,

not sure if intentional but I find this VERY helpful. Would this or something similar would be a good tab in the "settings" menu?

[bmotevalli]

@filefolder we have import / export functionality in the Side Menu, in the Event / Station steps. We probably should ask Yunlong to duplicate that into the waveform step as well.

Meanwhile, we definitely can add a tab to display the settings. If you recall, Neda added that a month ago, but it didn't get much of positive feedback on where it was located. That's why we turned it into import/export feature and pushed it to the side menu. But, I guess now that we have populated the settings page, that would be a good place to display the current config.

@NTaherifar

Regarding users and how it would be used, I guess probably we would have (wish to have) a spectrum of users. I am not sure how much everyone is familiar with coding, but I guess Megan mainly wanted to use it for education purposes, which the UI could be quite helpful. Also, there are a couple things that you can do via UI, which does not seem directly achievable via the config.cfg. For example, in config.cfg, if you define bounding boxes, it just queries all stations + events in the boxes and gets all waveforms for their combination. Not quite sure, if users want to get all that always. While, in the UI, you can have the chance to first search Events / Stations, select a short list, then move ahead. This might seem more useful for users that are more interested in the Event based workflows. They may first want to search for events, then they may want to see which stations are near to those events. Meanwhile, this sounds to be less critical for those that are interested into data coming out of specific stations. As the stations are pre-known, they probably just want to adjust other config parameters and update their data. In this second case, it seems adjusting the .cfg file and re-run makes things much easier, rather than going through the UI flow. Also, for more advanced users, definitely, cli commands also aids for automation purposes and setting up cron-jobs. Anyway, an interesting topic to discuss in the next meeting as you would know better what sort of spectrum of users could we expect and what would be their intensions. Knowing our user personas is specially useful for documentation purposes, which we should start to think about.

BTW, I guess one more interesting feature could be to add a simple page of only one step, where, we just provide an editable version of the config with a run button and perhaps a console log. So, users that know exactly what they want and going through the selection steps is cumbersome, can simply adjust their config and run it. I guess I mentioned this feature in one of the meeting but forgot to capture it in a issue.