Operation UI, separate advanced fields

[jorgerobles]

Following #219, alleviate operation UI hiding advanced fields (raster by example)

[jorgerobles]

@tbfleming, @openhardwarecoza not commited, operation.jsimplements

export const OPERATION_GROUPS = {   //
    //'laserPower', 'laserPowerRange', 'passes', 'cutRate', 'filterFillColor', 'filterStrokeColor'
    'Advanced': {
        collapsible: true,
        fields: ['smoothing', 'brightness', 'contrast', 'gamma', 'grayscale', 'shadesOfGray', 'invertColor', 'overScan']
    }
}

That defines if some fields need to be under a collapsible header. Future works will bound OPERATION_GROUPS to a redux state, so could be configured (like selecting what fields will be shown on large groups as 3DP)

Thoughts?

[tbfleming]

I'm mixed. I suggested this because I don't like overwhelming users with tons of options. Now that I see it some things about it make me uneasy:

• We have to decide which options are advanced and which aren't. When I try to decide I end up marking almost all of them advanced.
• If we make advanced/non-advanced decision configurable, then we'd be adding even more options for users to deal with.
• It's multi-level. I get really frustrated with Microsoft that they make me go through multiple levels of settings to change mouse speed, screen resolution, or other things I frequently change. Microsoft decides poorly what is and is not advanced.

Side issue: I don't like NAMES_WHICH_SHOUT. I only use this kind of name for macros, since macros cause total chaos when their names clash with non-macros. Fortunately Javascript doesn't have macros.

[jorgerobles]

Sorry, had used SHOUTING_VARS because I've had a mess with other var names in other modules (so many "types" and "fields") everywhere. I have to say I use them as convention only to constants (and defines in PHP and Arduino). It makes me a lot clearer for me.

• About deciding whats advanced or not is clear for me at least on Raster, maybe not on Milling. I thought to drive the whole operation panel thru templates if an "Easy Mode" setting is checked on settings... but I think there's no real Easy Mode. I have a thought spinning around UI optimization. now it's fine, but I feel it's not the best ... but I cannot figure what is wrong to get a better UI.
• About multilevel, thats controlled by collapsible, If collapsible is false then only shows the title and nothing more.
• 3DP will introduce some heavy issues on UI, as slicer settings shall be a nightmare. @raykholo and I were chatting around this and a solution is a kind of checkbox next to each field on the slicer configuration manager (like material database, we need modals for sure). That check will mark what field is or not visible on our left pane when the template is selected.

We are building a ton of features on LW. Every feature we add, the less easy is (unless we become/have an UX specialist... anyone??)

[tbfleming]

Yeah, slicer settings will be a nightmare :( . It's been over a year since I've used my 3D printers; has anyone come up a slicer UI that brings the settings under control? I used to use Slic3r mainly. Before that Skeinforge.

[jorgerobles]

I like Cura.

[cojarbi]

I use Simplify3D. Like all other slicer it has tabs to navigate to each category. Click a button, open a new screen a move around it making your selection ( for 3DP )

Regarding the above i do like the advance drop down. I hardly use or change those setting and i dont want to see them but i want them there in case. One level down is not that bad, more than that no

[ghost]

I like slic3r 's settings / configurability etc. Because it exposes almost everything. But it is hard. That said, you can also make a lot of assumptions (or upload your own? slic3r ini) and only expose a couple typical per-job settings. Slic3r profiles already contain material profiles and quality profiles in the same ini

I like cura' s print quality. I also like that curaengine is easier to distribute with if we need to pack it into lw eventually I dislike the cura community though, its become heavily Ultimaker only over the years... Git issues often get shot down. Slic3r stands behind the community more

On Mar 17, 2017 4:29 PM, "jorgerobles" notifications@github.com wrote:

I like Cura.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/221#issuecomment-287369195, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr21_Bk3ff9gs_1JALqObleTID2k8bks5rmpjXgaJpZM4MfeDb .

[ghost]

@cojarbi but not open source (;

On Mar 17, 2017 4:37 PM, "Ariel Yahni" notifications@github.com wrote:

I use Simplify3D. Like all other slicer it has tabs to navigate to each category. Click a button, open a new screen a move around it making your selection ( for 3DP )

Regarding the above i do like the advance drop down. I hardly use or change those setting and i dont want to see them but i want them there in case. One level down is not that bad, more than that no

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/221#issuecomment-287371151, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr29DMjCgTlPOOF5s2KAVVTtYzv6NJks5rmpqQgaJpZM4MfeDb .

[cojarbi]

@openhardwarecoza i know, was not implying to use it, just as an example of the UI they use, as a matter of fact all Slic3r is also the same on horizontal tasbs. i think Cura just has one and then advance settings ( like above )

[raykholo]

Re: 3D Printing... Back in the days of the RepRap Workspace and the STL Widget, we had the slicer parameters UI.
http://chilipeppr.com/reprap

https://github.com/raykholo/widget-stlViewer/blob/master/widget.js#L378 paramElements is a JSON object that holds Print, Filament, and Machine Settings (based on the 3 tabs of Slic3r) - and each parameter has a name, type (for which field to make in the HTML), properties, units, the default value, and nameforSlic3r is how we define the overwrite. If Cura operates in a similar way, a nameforCura could also be added.

As has been said, we start with a base .ini file of the parameters, and then whatever we add here is what is deemed necessary and supersedes what is in the .ini with the --name override as part of the slicing invocation exec.

https://github.com/raykholo/widget-stlViewer/blob/master/widget.js#L357 setupSlicingParamUI builds the HTML elements from the JSON descriptions.

In HTML it gets appended: https://github.com/raykholo/widget-stlViewer/blob/master/widget.html#L125 also lines 131 and 137. Those are the 3 tabs. I'm sure your UI may be differently organized.

https://github.com/raykholo/widget-stlViewer/blob/master/widget.js#L573 When we hit slice, buildSlic3rParamString was called and it built the string of --name overrides to pass to slic3r as part of the exec.

The rest of the widget was the 3D Viewer, ThreeJS for STL stuff, CP specific stuff, and the HTTP Post to send the Object3D (we traversed it and wrote an ascii stl of the entire bed layout) to our cloud slicing attempt.

TLDR: Slic3r is the way to go in my opinion, make a default .ini file, put params deemed necessary into JSON for override, generate HTML UI from that JSON object, pass parameters to slic3r when slicing is invoked.

[raykholo]

Adding snapshots:

[raykholo]

Might also want to read this thread regarding Slic3r UI update, there are similar thoughts there:

https://github.com/alexrj/Slic3r/pull/3770

[jorgerobles]

So, as seen on gif, should I commit? any other better UI approach?.

[cprezzi]

I would rather show all options but group them in blocks like "pictue preprocessing" "operation options"...

[cprezzi]

The problem with hiding elements behind a collapsed title is, that it makes it very hard for ocationally users to find a certain option again.

[jorgerobles]

@cprezzi thats what collapsible does. For now, I will commit with not collapsed groupings :)

[jorgerobles]

Closing.... @raykholo referencing this thread in #199 to not forget Slicer params