search

slic3r / Slic3r

Open Source toolpath generator for 3D printers
https://slic3r.org/
GNU Affero General Public License v3.0
3.32k stars 1.29k forks source link

Managing more Slic3r options #3952

Open lordofhyphens opened 7 years ago

lordofhyphens commented 7 years ago

I've been putting some thought into ways of managing the complexity of looking over the different options in Slic3r and how to avoid overwhelming users with a ton of one-off options, while maintaining one of Slic3r's core attractions for people (the high amount of customization).

One thing that I am considering is to employ priority/complexity levels, and provide users a slider to be able to manage their desired UI complexity, at least for configuration options.

The number of categories would be some fixed depth, each covering a set range of complexity levels.

So if we had 100 different complexity levels and a slider bar, we can code the PresetEditor to create UI elements for items whose assigned complexity is <= the chosen complexity.

Priority 0, in my mind, would be the current Slic3r interface. The upper end of the range would be useful for one-off "tweak" options for those corner use cases.

We would also wish to pair it with a "reset all hidden configuration options to defaults" command in the Preset Editor to aid people in ensuring that their configs aren't plagued with weird hidden options.

@alexrj

VanessaE commented 7 years ago

I might suggest assigning a "weight" to each possible setting that is hidden or revealed by such a slider control, rather than a preset editor. The "heavier" the option, the higher the slider control has to be set to reveal that option.

lordofhyphens commented 7 years ago

That is exactly what I meant with the complexity number and levels.

Lenbok commented 7 years ago

I think it's OK to have some level of categorization, but I think you're overcomplicating it by separating some high-resolution weight from the final categorization, for no real benefit. I think that it would be hard enough to objectively assign any particular setting to three levels, let alone 100 levels. One could argue that two levels (beginner/advanced) is not enough granularity, but I doubt it makes any sense to have more than three levels. (FWIW, kisslicer has three levels: beginner, medium, advanced).

lordofhyphens commented 7 years ago

I meant that every option gets an integer value assigned to it. The slider controls the view threshold.

Lenbok commented 7 years ago

Yup, I understand that. My point was that there is no point in having more than three integer values employed (you had suggested 100!), both because it is too hard to come up with a consistent policy for determining what the integer value should be for any particular config option, and I don't think users care to select at any higher level of granularity anyway (so what's the point in having more integers than categories).

What I am saying is decide on your number of levels now, along with what your criteria would be for putting a config option at one level or another. If you can articulate five clearly defined levels, then perhaps that's the number required.

Given a relatively low number of integers/categories, it's definitely feasible to use more self-explanatory UI elements for selecting the level of detail desired (e.g. radio buttons with descriptions, dropdown combo) than a numeric (or anonymous-valued) slider. Let the usability decide what the best UI element should be.

The1Percent commented 7 years ago

I honestly feel like one of the more helpful things would be a "print profile." Where you could define, print, filament, and printer settings. It gets a bit taxing at times remembering, which profile did I use for 60% infil with that black eSun PETG, oh yah, and I need that one to start about 1st layer about +0.1mm off the bed. I know its one of the awesome features that we have all the different setting groups, but if I could save those once I get it right for something and then just reload the who set of configs it would make my day.

alranel commented 7 years ago

We used to have this, with two levels: Simple/Expert. It didn't work. Making even more levels will not work because you assume users can make a rational choice, but they actually miss the information to base that choice upon: they don't know what they are hiding. Noone can categorize themselves as "intermediate" (could you?) or, using a slider, 40% or 55%... You can't ask users to decide how difficult they want their tool on a scale which they ignore! That's a choice someone else should do. Otherwise you're delegating the UX work to the users :-)

This UX pattern is not used by any complex software I know. Think about Photoshop, Solidworks etc. The key is to make complex things easier. Provide feedback, let the user understand the effects of a change, help them fix an issue (the need for changing options comes always from problems users face when printing, not from they skill level).

The new override/shortcut interface is part of a larger plan I'm working on, so that we provide multiple default profiles (we or the printer manufacturers) which expose the most useful settings according to the chosen profile. This should discourage opening the profile editor as that's the way for making "advanced" changes.

I'm also working on improvements to the Configuration Wizard. Guiding users into the configuration of a new machine is the easiest way for having them start with a clean, correct, profile.

alranel commented 7 years ago

@The1Percent, I can't really see why would you want to change Z offset on a per-print basis. That's a machine property.

The1Percent commented 7 years ago

@alexrj Printing PETG seems to really prefer to have the first layer printed slightly higher off the bed.

alranel commented 7 years ago

@The1Percent, I'm not aware of that. Should there be general consensus on that, the proper solution is to add Z offset to the options that can be overridden in a Filament profile.

lilatomic commented 7 years ago

Two ideas: 1) Use something like modules or environments to group options, and then allow them to be loaded as needed. For example, all the custom G-code options could be grouped under the G-code module. This module could be unloaded by default if most people don't use it, which would remove the clutter and complexity for most. Those who need it could specifically enable it, which would enable the G-code options across the system. 2) Allow custom menus and toolbars, like Microsoft Office or many other programs. This would allow all the one-off items to exist in a less presentable format, but the ones which a user feels are necessary can be arranged exactly where needed.

Also, an up-to-date manual would probably go a long way to helping users navigate the features in any configuration. I might put some work into that, once I get more familiar with Slic3r.

foreachthing commented 7 years ago

For the slider-idea: you would then have to decide what setting is important (or difficult) to me - can you do that? I like the idea of the overrides, but they are not ripe yet. => All printer related options are in the settings dialog. The ones I need to vary (from print to print) are on the UI - done. That way I can decide what I want to see/tweak/change. This is how Cura kind of works and I like that. Oh, don't do MS-Office Ribbons and hide/clutter your settings ... thanks.

gege2b commented 7 years ago

looks like something way more complicated than the "simple/expert" mode that was ripped off recently I'm not sure it's worst the effort

just an idea I'm throwing as is : what about adding some color code to options ? Green ones would be the "simplest", and gradually drifting to red for the more advanced ones (using the "complexity" factor you talked about)

pros : beginners would clearly see if the setting they want to tune is an advanced one or not cons : this would looks like a xmas tree

lordofhyphens commented 7 years ago

@gege2b also cons: it would be unreadable to people with red/green colorblindness ;)

The point of this discussion (why I started it) is to look for a way to manage complexity in Slic3r, so it doesn't go the way of Skeinforge (bazillion arcane options than nobody knows how to use).

I accept that there will be feature creep; if we can manage the option creep I won't have to look quite so unfavorably at adding tunables to cover corner cases.

foreachthing commented 7 years ago

What about modular "override-profiles"? Meaning: I only have access to the settings I use most. All other settings are only set once. That way I could have a module that only changes the layer thickness and print speed while all other settings remain untouched (or default). Another module would contain support information. This could be like building a house of bricks. Take the "brick" layer-thickness-speed-fast and the "brick" support-50deg - Print - Done.

[0.2-layer-print-speed-slow-settings] + [support-50deg] + [PLA-white-setting] = good print. [0.15-layer-print-speed-fast-settings] + [25%-cube-infill] + [support-60deg] + [PLA-white-setting] = perfect print. Or maybe, just make one "brick" per printer/part ... [um2-big-parts] = well-enought-print

Advantage: I don't have tons of duplicate settings, i.e. if I need to change my start G-Code, I only would have to do it once and not for every saved profile. Or, put the start g-code in a module as well and name it according to your printer, if you have more than one. This would reduce the complexity, I think, to a point where the user can choose his/her settings according to their level.

onekk commented 7 years ago

Not used to 3D printing, bu used to manage complexity, in the CNC word the problem is similar, and is generally resolved using styles of profile, generally on material basis or tool basis, so when i manage to find a proper configuration for a job i save this setting to a style and reuse it for the next similar job eventually fine tuning the settings, but not having to set maybe 100 options.

The problem nowadays is that many people are used to videogame and not to "computer science" and so the discussion is generally on "what option i have to use" and not "what this option do and what this parameter mean".

My two cents, for now.

Maxwellfire commented 7 years ago

Personally, when using programs for the first time I almost immediately will turn them to their most advanced mode if possible. While I won't touch a majority of the settings at first, I want to see what complexity exists. This is very useful for finding settings later. For example if I think "my bridges look awfully thin. I wish there was a way to adjust that". If all of the settings are visible, then I will likely remember that there was some option or another that sounded close and you will go look for it. If things are hidden I don't know what I'm missing and don't use features that might help.

As such, I agree with gege2b's idea of colors (or equivalent labeling) much more so than a complexity slider. Colors would allow you to see how advanced and sensitive an option is without hiding it from the user.

On a final slightly tangential point, I think that the categorization (like the tabs that slic3r currently uses) and complete documentation of features goes an extremely long way toward usability. The long and descriptive tooltips that slic3r uses in many places really helped me understand what settings did. Those alone remove a lot of the "wall of buttons" feel. Personally I would rather see categorization and clear accessible documentation expanded instead of hiding options.

mron commented 7 years ago

I would like to see a user based system. I try to manage printers in a makerspace. We have several fairly sophisticated users who want to save the setting for successful prints. It gets very messy quickly when everyone saves their own print settings, there own filament settings, and even custom gcode. I don't know if a git type version control with branching and versioning would be appropriate. The UI is only part of the issue. Being able to go to a known state for all the settings would help me greatly. I can't depend on calling up a print setting and know for sure some other user hasn't made a change somewhere and saved it. Maybe even tag a gcode file with a reference to the state version that was used to create it.

Thanks for asking about this.

Poikilos commented 6 years ago

There was some discussion about recategorizing settings. Here are related feature requests regarding that:

vovcacik commented 6 years ago

Hi, I just had a hard time to find Retraction settings (#4226) in slic3r 1.3.0-dev so I thought I would add my 2 cents:

You can argue this was all my fault and I wasn't looking thoroughly; and you would be right! But for my defense:

Based on this, I would suggest Command pallette feature, or Go to feature. Basically it is a search box for program's commands and settings. It is used in lot of IDEs like Intellij IDEA (aka Search everywhere) or Sublime Text (aka Command pallette). It does not have to be that powerful, if it takes me to the right place it will be enough (aka Go to).

lordofhyphens commented 6 years ago

FWIW I have been fixing the manual, but it has not been pushed out yet. -.-;

On Dec 17, 2017 5:05 AM, "Vlastimil Ovčáčík" notifications@github.com wrote:

Hi, I just hard a hard time to find Retraction settings (#4226 https://github.com/alexrj/Slic3r/issues/4226) in slic3r 1.3.0-dev so I thought I would add my 2 cents:

  • @lordofhyphens https://github.com/lordofhyphens is right about that you need to manage the complexity somehow
  • @alexrj https://github.com/alexrj in his comment https://github.com/alexrj/Slic3r/issues/3952#issuecomment-301339142 argues that user can't know what level he needs and he is right. I didn't know what level (i.e. simple or expert) I need to display Retraction settings. So I was trying to enable Expert mode but even that option was missing from Preferences, which only add to my confusion. Now I know the dev build is always running in expert mode. If you implement more levels of details and I won't be able to find some configuration I need, I will go with expert/100% again.
  • when I knew I wont find the retraction config by my own first thing I did is to read the manual. But it didn't help because
    • a) it mentions that I need to run in Expert mode, that I wasn't even sure how to enable, let alone what mode the slic3r is running in and the mode combo box was missing from Preferences
    • b) the manual http://manual.slic3r.org/expert-mode/fighting-ooze does not state where exactly is the settings. If there was explicit path like Printer settings tab > Extruder 1 page > Retraction settings section it would be perfect, but unfortunately it is missing the middle step.
  • @expertmm https://github.com/expertmm is considering recategorization in his comment https://github.com/alexrj/Slic3r/issues/3952#issuecomment-349423876. This will be hard to get right. I was pretty sure the Retraction settings have to be in Print settings, after all it seems 95% of all settings is there. Yet it is in Printer settings. I think you can find good arguments for both locations.

You can argue this was all my fault and I wasn't looking thoroughly; and you would be right! But for my defense:

  • as a developer I am used to work with complicated interfaces (think Photoshop, IDEs etc.)
  • manual was my first stop to get help
  • I am pretty sure some cognitive bias was in play that just reinforced my confusion and believe that the slic3r is not running in expert mode and hence the Retraction settings is not even displaying (despite that I did went thru all the settings, I probably even visited Extruder 1 but I simply didn't see the Retraction setting there (and yes, it was there). Cognitive bias in play.
  • I was familiar with 3D printing jargon; I knew what I am looking for and how it is called.

Based on this, I would suggest Command pallette feature, or Go to feature. Basically it is a search box for program's commands and settings. It is used in lot of IDEs like Intellij IDEA (aka Search everywhere) or Sublime Text (aka Command pallette). It does not have to be that powerful, if it takes me to the right place it will be enough (aka Go to ).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/3952#issuecomment-352247758, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB8CjRNtVmlhknchqEL3Tx67kjWYN5cks5tBPVjgaJpZM4NaJmJ .