bulkloader - browse and edit - customization

[dustymc]

ref: #5331

The browse-and-edit form is beginning to become functional under the new bulkloader structure, and it is obvious that this form is going to be very resource-demanding in its default state. I'm running 32G of RAM and it's about all my machine wants, but it is functional for me.

The form can be customized (also currently functional), and I doubt any user needs the full thousand+ columns.

https://arctos-test.tacc.utexas.edu/Bulkloader/browseBulk.cfm?action=customize is a direct link to the customize page.

It would be good to get some early feedback - is the form usable to others?

If not, or not entirely, how can we mitigate? I suspect documentation (who knows that can be customized?) and perhaps a direct link to the customize form (it could even be default??) are involved, but very up for anything that supports the decisions we've already made.

Also please note that most bulkloader functionality IS NOT working at this time in test. Only things mentioned here (load/view the table, customize the form) or in the status section of #5331 are ready for testing/feedback.

[Jegelewicz]

My very first thought is that I don't want to drag 7 different things up to get a single attribute. Possible to drag a group of things?

[Jegelewicz]

Will there still be the option to hide all empty columns? If so, will that come before or after this kind of customization? OR should it be part of this form?

[dustymc]

drag a group of things?

For now: No, and I think that's "the weeds," and especially after taking this long to get to this point I think I don't want to get lost in those weeds.

For mañana: Let's find out, #6401

option to hide all empty columns?

Yes:

and it works for me, but makes my spinnybits spin....

[AJLinn]

For my uses it seems pretty much the same - not sure I'd customize but it's nice to know it's there. I was able to hide the empty columns, which is essential for our records to be viewable/manageable. All good for my purposes.

[acdoll]

Can you add the same group option you have in the Bulkload Builder, or is that the same set of weeds? (or different weeds, but same swamp)

[dustymc]

@acdoll thanks, I'm working on some reusable weeds, and could use some feedback before I start sprinkling them around.

https://arctos-test.tacc.utexas.edu/Bulkloader/enter.cfm (which could also use some testing - it's not "done" but the shape is getting pretty solid), click customize, should get to something like....

It won't look quite like that elsewhere, but the pattern of

1. do stuff with big swaths of things
2. do stuff with groups of things
3. do stuff with individual items

should carry over.

[acdoll]

@dustymc I really like how this is working. The group show/carry/hide is really useful. Being able to enter default values is going to be really useful, also. I assume DefaultValue for controlled fields (like part_attribute_type) will be linked to their code tables; right now I can type in anything. If it's in the code table list, it will display, but does not set up the _value field properly.

The top attribute is the typed in default value, the bottom one is selected from the dropdown on this screen. You can tell that the bottom one set up the part_attribute_value for the dropdown whereas the top one is just a string field.

Being able to Pull the values from a completed form will make that really easy to get set up.

The only other change I'd make would be to add the ability to re-order the major groups (parts, identifications, identifiers, etc.). Then we can order them to match our datasheets and speed data entry.

Just noticed: these spatial fields are set to hide, but their headers still are displayed:

[dustymc]

Thanks!

This has most of the functionality of the old screen, but it is MUCH simpler (and much more modular) than the old screen. I'm (vaguely, and certainly open to suggestions) hoping that, in conjunction with the time we've spent on the structure and the promises of stability, will mean that this can exist beside some more specialized screens and within our resources. I'm not sure where that might go (maintaining 3 or 4 or even a dozen extra UIs might be sustainable, 300 probably isn't - at least without extra help, which this is designed to accommodate), how long to put it off (to avoid replicating bugs), etc., etc., but I keep hearing that things are complex and that's a problem so this is the start of a plan to do something about that.

right now I can type in anything

Yep - which should be pretty low-impact (it'll just get nuked when the form controls build themselves) - I haven't got that completely wired in yet, and your two examples should behave the same (empty controlled value field) when I do. Coming from a seed record with your defaults should work properly (ignore your incompatible data) now.

re-order

I think it's not out of the question (this form uses responsive layout so that's "just" CSS - in theory...), but I think that might be about where we start thinking about custom forms.

headers still are displayed

Yep. I could do a bit more to clean that sort of thing up, but it would add some complexity (and remove any clues that you've hidden the thing you're missing). I think I'd like to see where the custom forms go first, but I'm up for whatever.

Please open a dedicated issue if any of that seems too wild! More "early beta" testing is very welcome, and maybe this is even far enough along for its own mainstream Issue? And I'm struggling with how (and when) to approach the possibility of multiple screens, but I'm open to the idea of releasing this with at least one of those if anyone wants to think about specifics.