-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Turn the plater overrides into shortcuts #3912
Conversation
… options in plater update the selected preset automatically instead of overriding it
…e the + button for adding them on the fly, as it doesn't provide any advantage over actually opening the profile. Oh the other hand, automatically list dirty options in the plater
Thank you for the report @gege2b. I applied one further change which makes a lot of sense in my opionion. You might be disappointed by the lack of the green "+" button, but since we now have shortcuts and not overrides you can just open the profile and change options there. Dirty options will be shown among the plater shortcuts automatically! Well, try it. :) |
after some tests, this looks pretty good and straightforward ! making dirty options shorcuts is smart because, in fine, shortcuts would make dirty options |
Automated builds for this PR are here (PR3912/gui3-shortcuts): |
Nononononono -- I specifically want plater overrides that do NOT alter the profiles!! The whole point of having the per-print overrides is for one-off (or frequently changed) options that don't muck with the saved profiles. If I want to change the profile, I'll go into the profile settings! |
@Lenbok, just discard the changes then, no? |
Is slic3r going to nag about quitting with unsaved changes? The plater overrides should be though of as being more like configuring commonly used per-object overrides - i.e they are completely transient changes. By definition if the user went to the effort to make them a plater override they expect to be changing them frequently, so it makes no sense to sync back to the profile and offer/nag to save them every time the user makes use of them. They're right there by the previews of the objects, so the user expects them to be associated with the current print. Profiles should be things that you set up nicely and then pretty much shouldn't have to modify after that. If you're constantly having to tweak your profiles you're doing it wrong. My most hated feature of kisslicer is how it automatically saves your profile changes when you make any per-print changes. Boom, your old profile is polluted and gone. The plater overrides as commonly used per-print settings are awesome as it means you don't have to create separate profiles for things that are commonly changed (e.g. with/without support, infill levels). |
The current behaviour is consistent with the per-object overrides -- and you wouldn't expect them to be propagated back to the profile settings either. |
slic3r is already asking when you quit with unsaved change (I can't remember since when, but it's been a long time) Overrides (or shortcuts) are propagated, but not saved to the profile, so you just have to discard changes when slic3r is asking |
@gege2b I know that it asks you and that's my point - I don't want to be nagged about saving settings to a profile when I've specifically added those to the plater so they can be set on a per-print basis when the current objects demand it. I'm coming at this from the UX perspective of someone just wanting to do printing rather than profile configuring and this would be adding UX burden. I see the plater overrides as an improvement of the existing per-object overrides (i.e. it gives the ability to "favourite" the commonly used ones, and of course adding settings that previously could not be done via object overrides, such as brim). For a user with profiles well set up (either because their printer came with profiles already, or because they have tuned their printer to their satisfaction), you are adding UX burden potentially every time they go to do a print! This PR seems to be viewing the overrides instead as some kind of profile tuning streamlining? I particularly think that think a "profile tuning" use case is better addressed by #3835. Perhaps you can you explain the motivation here? (and I hope it's more than just "because we can", because as I noted above, this would make the behaviour inconsistent with how the current plater per-object settings work). |
@Lenbok, I read your comments very carefully, and I do appreciate them. Of course you got points there. I collected a good amount of feedback on these GUI changes. As often happens in UX I get conflicting feedback and requests, so the final solution will be a compromise. There's also a conflict between needs of basic and advanced users, and I really want to hold out a hand I see your point about the save/dismiss dialog being annoying or confusing for new users. Still, I don't think the best solution is to revert to the "override" behavior. Let's step back to the semantics and purpose of the plater shortcuts:
(A note regarding the last point: currently in master we have that green + button for adding plater overrides on the fly. The mere existence of that button turned the plater overrides into a way for fine-tuning profiles. I noticed that in screenshots posted here: users added tens of options there. Then of course requests like #3834 arise :-) basically leading to duplication of the entire profile editor functionality into the plater. In this PR I'm proposing to remove that green + button which probably saves one click but adds a lot of confusion for most users.) A direct consequence of point 1 is that shortcut settings are usually self-explanatory (enable support material, brim, bottom solid layers...) and they are meaningful only for each single print. So I think the best solution is to have shortcuts modify and save the profiles directly, without marking them as modified, thus without any prompt. I think this slight change will make this PR satisfy all the issues raised so far, including yours. Even if it's not the solution you proposed :) |
Whenever dealing with UX I learned one lesson: advanced users will push for fewer clicks because they already know what they want, but basic users will benefit from more contextual information (hierarchy being a part of it) in order to understand what they can do and what they want. So in the end it's often better to have one more click if it reduces confusion. :) |
I implemented this. It looks handy. I invite you to test it. There are automated builds for this pull request in http://dl.slic3r.org/dev (look for files named |
@alexrj Good discussion! Maybe I am mis-interpreting, but it sounds like you are conflating the concept of settings that need to be decided on a per-print basis (because that is what is needed by the particular object, or desires of the user for this particular print), with that of settings that are beginner-friendly ("safe"). They are two completely orthogonal concepts, and I don't think that the beginner/advanced distinction is what should be determining or guiding what settings are employed as plater overrides. It seems like you are heading towards using plater overrides as a beginner/expert distinction! I think for your UX analysis you need to consider what are the use cases that you want the plater overrides to solve. I think that the main Slic3r use cases to consider are:
(are there others?) It is not clear how your point 1 and 2 above relate to the user's intent or which of the use cases they are supposed to support. I think from point 3 that you do not intend plater overrides to be used for profile tuning (although maybe you are wanting to have separate use cases for "beginner" profile tuning and "advanced/fine" profile tuning). I can understand that for Profile Tuning you may want to guide Alice so that as a beginner she has guidance as to what are common or important settings, from those where advanced knowledge is required to know when changing a value is appropriate, but I don't think that plater overrides are an appropriate mechanism to achieve that. In terms of the Just Printing use case, I think the profiles should contain selected defaults, and am not convinced the settings should be saved because of the last thing that I printed. It's like when you have templates defined in office suites -- the app doesn't automatically update settings in the template just because you've made a document from the template and changed the font size. In fact, it would be nice to have a way to quickly reset the plater per-print overrides back to their profile-defined defaults without having to quit/restart slic3r, and your new proposal to automatically and transparently save them makes quit/restart not even an option any more! |
BTW - the idea of completely separating Just Printing vs Profile Tuning and not altering profiles is also related to #3961, so perhaps whatever you have in mind there for protecting profiles from editing is relevant here? |
Your "Profile tuning" scenario requires clicking on the cog button to open the profile editor. That dialog is well organized for in-depth tuning, and can be further improved. This is identical to what we used to do in 1.2.9, except just for the tabs being now dialogs (which allows for real-time preview). The "Just printing" scenario is now much easier, as you select the preset and get a bunch of options in the plater that you want to inspect/change every time you launch a print. I suggest you try the latest build for this PR (or you build it yourself from git) and try to use it normally. I've been doing the same and I'm quite happy now. (The idea I have about protected profiles is not much related to this. It's about a better distribution mechanism for manufacturers, but I'll elaborate more on that when I have implemented a proof-of-concept.) |
@alexrj Thanks for the comments, and I think we are converging. I fully agree regarding "profile tuning" being done via the cog, and that is a well accepted UI paradigm. For "Just Printing" I agree it does seem the key point is regarding how to choose default values for the overrides. My initial thought when you suggested the automatic saving of the overrides was along those lines "who cares about those particular settings anyway". However, I would disagree that there are no meaningful default values though -- I can suggest three useful possibilities right away:
I would define a default infill percentage to be my most commonly used percentage. I would define the default "interior brim width" as zero, as it's virtually never needed - in fact I wouldn't have that as a persistent plater override - I would turn on interior brim width as a one-off override when the print requires rather than having to go into profile editing mode and I certainly wouldn't want that change to be made persistently (I note that you've removed the green "+" button in this branch, so now this isn't possible either -- I'm sorry but this branch just seems like one step backward after another). This illustrates how per-print overrides needn't always be commonly used settings. (edit: removed problem with the pre-built binary of this PR - already covered by a separately filed issue) |
Hi there, great discussion ! my another two cents : I fully agree on both the profile tuning and just printing scenarii, they totally make sense The only problem would be if someone use shortcuts to change important settings such as widths or any setting closely related to printer mechanics (because, why not?). Maybe warn the user that shortcuts shouldn't be used to change important settings is a good idea to try to make this feature a bit more user-proof (and #3952 can be useful for that) I tried right now this branch and have two more questions/concerns 1 - Shortcuts didn't appear anymore when there is a dirty option in profile settings. Is it a wanted behaviour ? 2 - I can't manage to close the new preset tabs. Once opened, I just can't close it (either by hitting Esc or by any other mean). |
I'm afraid I must agree with the others here - having profiles be managed and saved separately from plater overrides is demonstrably a good thing. If it were up to me, Slic3r should keep the current mechanism, and this PR ought to become simply a button to save the current overrides into the current Print/Filament/Printer profiles, and maybe a second button that'll save the overrides to all profiles. |
@gege2b, it was a regression! I fixed it now, and dirty options are automatically displayed as shortcuts. From my perspective of software designer I see a usual pattern going on here, which is common in UX discussions whenever disruptive changes are proposed. Most comments are biased by habits and by the mental scheme users built so far. If you re-read this conversation you'll notice that nobody reported the results of actual testing, with highlights of actual issues found during usage. Testing means that the personal workflow and habits shall be wiped and user shall approach the application as if it was a new one (i.e. adapting theirselves to the design, and not trying to adapt the design to themselves!). I got useful feedback about the override feature only after merging it into master, thus forcing people to test it in everyday use. It's nice seeing that so many people think the tabbed interface is perfect. However you probably don't remember what happened when I introduced that change many years ago: everybody were saying it was terrible and having settings "hidden in another tab" was very uncomfortable. After collecting much feedback and fighting the habits, I forced the change. Being forced to adapt their workflow, people just liked the new interface and nobody ever asked to go back anymore. Criticism was based on habits and existing mental scheme rather than actual issues found during usage. To be fair, I find myself thinking that way all the time when facing a change, and I try not to do it but it's hard. Let's start from one important point: the current state of this branch is totally equivalent to the interface used in the last public release. We only added a cog button and close buttons for the profile tabs. But everything is now at the same place as before, with the same behavior. If you don't want to use the plater shortcuts, your experience will be TOTALLY IDENTICAL to what people have been using until today. No way it's a step backwards, it's just identical. The shortcut feature is an addition that you might want to use or not. Second point. Nobody ever felt the need for plater overrides or shortcuts. Not a single feature request in many years. I had this idea out of the blue, and I've been experimenting with it. The changes I pushed to the master branch were appreciated but actual usage brought up several reports by confused users (you're not taking them into account in your comments, the current status of master raises troubles), and bad usage patterns (like using the green [+] button for doing the whole configuration instead of clicking the cog). I suggest you a way for breaking the current mental scheme: the distinction between printer/filament/print settings is good but it's not carved into stone. I introduced it several years ago when it was totally normal to think in terms of a single global profile. By observing Slic3r users and myself in these years, especially during workshops, I realized Print settings currently include two distinct categories of options:
So we actually have four categories: printer, filament, style/quality, print job settings. Suppose I have a "high quality" print preset. It's dummy duplicating it into "high quality w/ support w/brim", "high quality w/out support w/brim" etc. Those print job options should be factored out and put into a new category of presets (a fourth tab) or, more easily, just hard-coded in the main screen near the "Print..." button. Some people asked a shortcut in the plater for enabling/disabling support material since it's makes more sense there than saved into a profile, as there's no correct value to be set in a profile, since it depends on objects. This branch is a sophisticated way for factoring out those options without overengineering it as a fourth tab. I've been testing in everyday printing, and I've been observing other users testing it and it seems very good. |
I will look at the code itself tonight.
Frankly I think we should just merge this and adaptive slicing. I suspect
we will get better user feedback on actual usage.
|
it reminds me the "doctor cycle" with the Doctor who TV show
to go back to the subject, I find this branch randomly, that's why I begin to test it because this feature is interesting. I agree that merging it in master would speed up the feedback, |
Some issues from testing ;-), with slic3r expectations wiped clear:
Nonetheless, maybe in spite of the above usability issues it's probably better to just tweak and merge this rather than going round in circles. I can get the "don't mess with my sensible stable/known defaults" behaviour by wrapping slicer in a script that reverts any changes to my presets before starting it up. I may as well do it for kisslicer while I'm at it (I usually rarely use it since it has the same preclusion for instantly changing settings). |
|
Thank you @Lenbok, answering your points:
|
@alexrj Of course I know the answers to those points, but they are usability issues that are not clear to a new user, and your comments don't actually address them, rather they just state what the implementation does, or your intention. And of course, some these equally apply whether the per-print settings are as "overrides" or "shortcuts". Also to be clear, I'm not discussing this just for the sake of being argumentative -- it's because I care about Slic3r and it's usability :-). (1) I think there is no such thing as "options which are not safe to change on a per print basis", only "how likely is it the user wants to change this setting on a per-print basis". Can you clearly define what you mean and how an end-user is supposed to discover "safe"? Kisslicer even has a speed/quality slider setting for adjusting per-print, so obviously opinions differ. Anyway, that's not addressing the issue of the user irrecoverably losing their frame of reference between prints when some of these options have many values (as with my example with font selection / font size in a word processor). (3 and 5) The association of any given configuration parameter with "print setting" vs "printer setting" vs "filament setting" is as you said only a rough association (and certainly not mutually exclusive). Brim for example is only slightly associated with "print setting" but highly associated with the filament according to the adhesion and tendency to warp, or even with the printer according to the bed material used. You suggested that having separate "print job profiles" might over-complicate things, but it's clear that tying them to "print setting" presets also has clear disadvantages. The user just told the UI that he/she wanted support enabled, and slic3r seemingly randomly ignored them (it actually entirely ignored them, and it was just chance whether the new setting was the same). I think hard-linking the "print job" settings to "print setting" causes a lot of confusion, and maybe it would actually be better to factor out "print job" settings. Maybe these should just be in a general "plater settings usability" issue? |
I have read through this thread. I can only add my experiences and expectations.
For me the logical defaults are what I spent time working out for the profiles as 'works best on my system'. I agree that 'Generate support material' may not have a logical default although I seldom use it and would prefer that it default to 'off' rather than what I finished with on yesterday's print. More frustrating for me is that I use the 'auto' speed settings and control everything from 'Max print speed' and occasionally 'Max volumetric speed'. These do take time to work out for a physical printer configuration and are great as a maximum limit that I can work down from to control speed vs. quality. I take the point that this is an important setting and should not be exposed as a shortcut, but in fact I do access it for almost every print so it is a pain to click around and find it every time. For my UX design principles though I feel the main issue is that there should at least be an 'autosave' toggle in preferences to control writing the shortcutted settings out? The experience throughout the rest of the UI is to be told that a profile is dirty and needs to be saved, so writing data without any warning is very surprising. If the toggle is not set then IMO the behavior should be to just dump the shortcutted settings, but I can see that this is contentious as well. I guess this comment duplicates #4200 then. |
My only wish is, that all the control-shortcut settings where saved somewhere else and stay the same for all profiles (if I import settings from gcode, my shortcuts would remain the same). MHO: For the settings, whether brim (or any other setting for that matter) is a filament or printing setting - I don't care! As long as I can make a shortcut for that particular setting! And I think that the brim is a part-setting - the smaller the part the more brim I need. How I use Slic3r: I have just three base profiles (I also only have one printer): one for each nozzle size and one for each filament I use. The rest of the settings I adjust for each print individually; over the shortcuts! So whether this is "safe" or not - how can you decide that for me ...?! |
Just a GUI paradigm to add to this for consideration: Indeed the shortcuts are to things that change so frequently they may have no logical default. So I would prefer that the default be what is saved in the profile (and I explicitly change and save in the relevant tab), while the shortcut setting can be silently discarded. |
Thus make them affect the selected profile.
I'm also considering hiding the green "+" button in the plater as it would make much less sense.