Skip to content
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

Merged
merged 18 commits into from
May 29, 2017
Merged

Turn the plater overrides into shortcuts #3912

merged 18 commits into from
May 29, 2017

Conversation

alranel
Copy link
Member

@alranel alranel commented Apr 27, 2017

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.

alranel added 6 commits April 15, 2017 11:10
… 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
@alranel alranel requested a review from lordofhyphens April 29, 2017 19:23
@alranel
Copy link
Member Author

alranel commented Apr 29, 2017

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. :)

@gege2b
Copy link
Contributor

gege2b commented Apr 30, 2017

after some tests, this looks pretty good and straightforward !

making dirty options shorcuts is smart because, in fine, shortcuts would make dirty options

@alranel
Copy link
Member Author

alranel commented May 1, 2017

Automated builds for this PR are here (PR3912/gui3-shortcuts):
http://dl.slic3r.org/dev/linux/branches/
http://dl.slic3r.org/dev/win/branches/

@Lenbok
Copy link
Contributor

Lenbok commented May 5, 2017

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!

@alranel
Copy link
Member Author

alranel commented May 5, 2017

@Lenbok, just discard the changes then, no?

@Lenbok
Copy link
Contributor

Lenbok commented May 5, 2017

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).

@Lenbok
Copy link
Contributor

Lenbok commented May 5, 2017

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.

@gege2b
Copy link
Contributor

gege2b commented May 5, 2017

slic3r is already asking when you quit with unsaved change (I can't remember since when, but it's been a long time)
He even lists the modified settings

Overrides (or shortcuts) are propagated, but not saved to the profile, so you just have to discard changes when slic3r is asking

@Lenbok
Copy link
Contributor

Lenbok commented May 5, 2017

@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).

@alranel
Copy link
Member Author

alranel commented May 20, 2017

@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
to basic users by creating a clear hierarchy of things they can touch safely and things they need to understand before touching.

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:

  1. They are a way to expose and communicate the settings that can be safely changed on a per-print basis. The preset editor doesn't provide visual hints for conveying this information as all settings have the same importance and it wouldn't be just a matter of rearranging its layout, as such settings vary according to the type of print (mechanical part, high-res curved model, draft quality, spiral vase etc.)
  2. They are a way to change the most important settings quickly, without opening the preset editor.
  3. They are NOT a way to fine-tune the profiles (i.e. configuring those options that usually last "forever" once tuned correctly, such as extrusion widths, speeds etc.) Opening the preset editor is the best way to to fine-tuning.

(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.
This works nicely even with profiles provided by manufacturers: for example, the value of "Brim" or "Enable support material" is not strictly part of the pre-configured print profile, and ideally shouldn't even be listed in that section of the program. It should be a free-standing toggle in the plater. So, having it in the print profile and providing an automatically-saving shortcut will just provide a "remember last setting" feature, without creating problems on the profile itself.

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 :)

@alranel
Copy link
Member Author

alranel commented May 20, 2017

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. :)

@alranel
Copy link
Member Author

alranel commented May 20, 2017

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 branches/slic3r-gui3-shortcuts*). Wait until the dot near the commit above turns green before downloading.

@Lenbok
Copy link
Contributor

Lenbok commented May 21, 2017

@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:

  • Profile tuning: Alice has bought/build her printer and wants to configure slicer to generate nice prints. She needs to set up a profile that works well. She will probably be making several prints of the same object and will dial things in to a point where she is happy. During the process she may copy/delete/refine profiles. Possibly she tweaks some of the more advanced settings, but these will probably be after getting the basic settings adjusted.

  • Just printing: Alice has created some reliable profiles that she is happy with, and now she wants to print the latest fidget spinner off thingiverse. This model has some overhangs so she wants to turn on support. She's also printing in ABS and wants to enable brim. Maybe one of the parts needs higher infill than the other, so she uses an object override to adjust that one. After that she's going to print something different, so the current settings for infill density, support and brim are quite irrelevant (she would rather print the next object based on the defaults specified in her profile).

(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!

@Lenbok
Copy link
Contributor

Lenbok commented May 21, 2017

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?

@alranel
Copy link
Member Author

alranel commented May 21, 2017

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.
It looks like the keypoint of our discussion is whether it is good to remember last values for those options or we should give user the ability to revert to default values. I think that given the nature of those options, there are no meaningful default value. In my opinion there's no default for "Enable support material", it's a choice that user does explicitely every time they launch a print. I noticed myself going always to check whether it was enabled or not for every single 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.)

@Lenbok
Copy link
Contributor

Lenbok commented May 21, 2017

@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)

@gege2b
Copy link
Contributor

gege2b commented May 22, 2017

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?).
Automatically saving those settings could ruin a good profile in case the modified values aren't set back to the original ones

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 ?
@Lenbok you mentionned the green "+" having disapeared, that was because shortcuts was automatically added on the fly based on dirty options. And I admit I liked this behaviour so I hope it's just a bug :P

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).
Because of that (I think), background processing didn't fire anymore, even if I move an object on the plater

@VanessaE
Copy link
Collaborator

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.

@alranel
Copy link
Member Author

alranel commented May 26, 2017

@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:

  • settings about quality and print behavior, which are invariant after the initial tuning and are common to any print
  • settings which only have meaning for each print job, and that users always check before launching a print (support material on/off, brim, infill)

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.
Still, this needs to be tested more than discussed (discussion is welcome, don't get me wrong) and unfortunately nobody tests branches until they are merged into master. I'm considering forcing things a bit and merging it into master. I'm totally, totally open to reverting this change if feedback includes actual usage issues ("I can't do this" / "I don't understand how to do this" / "I don't understand why I see this" / "Doing this is complicated" etc.)

@lordofhyphens
Copy link
Member

lordofhyphens commented May 26, 2017 via email

@Lenbok
Copy link
Contributor

Lenbok commented May 26, 2017

Actually @alexrj I requested per print plater overrides in #2164, and others have asked for similar in #2964 etc.

@gege2b
Copy link
Contributor

gege2b commented May 28, 2017

it reminds me the "doctor cycle" with the Doctor who TV show
while(1) {

  • "OMG I LOVE this actor !"
  • "Hey ! Why did they change the actor, I HATE the new one !"
  • "Well, the new actor is not so bad, after all"
    }

to go back to the subject, I find this branch randomly, that's why I begin to test it because this feature is interesting.
Does the settings be in tabs or in dialog doesn't really matter (for me), but as mentioned before, print settings tab has no close button (they're present in filament and printers tabs)
that's an actual testing with no mental bias inside ;)

I agree that merging it in master would speed up the feedback,
For me, the actual behaviour (in this branch's PoV) is the way to go, even if some fine tuning would still be needed

@Lenbok
Copy link
Contributor

Lenbok commented May 28, 2017

Some issues from testing ;-), with slic3r expectations wiped clear:

  • After making use of a shortcut, there is no way to work out what the previous value was. (I have a shortcut set for the two most important speed settings (perimeter and infill speed), with the rest defined as percentages of those. Once I do a print at an adjusted higher or lower speed, I have lost my frame of reference with respect to the sensible default settings. Same for infill pattern, most of the time I just leave it one of the rectilinear options (I don't remember the names but I know the one I like when I see it), but sometimes try something different with transparent filament for effect. It would be like if I open my word processor, do a poster for my kids in Comic Sans, and then in the next document a day later I have to remember what my default font used to be along with a bunch of other settings -- it's making me look at every other toolbar button to check just in case it's on a new setting.

  • The automatic adding of dirty options on the fly is confusing. I modify interior brim via profile settings and it adds it to the plater overrides. If I click save, the plater still says the profile is modified (and the setting remains as a plater override). If I then change values back in the plater override, should they be instantly saved or not? Some of this just seems like bugs.

  • When I add a shortcut to the plater (e.g. infill), it disappears when I select a different print preset. Why is that? Why do I have to define my shortcuts in every profile I have, when the settings that I like to change are the same every time? If these settings really are different in some categorical way as suggested above, why should they be tied to particular print presets.

  • When I double click on an object and set a value for the object infill pattern, the setting is not persisted back to the plater level shortcut or to the profile. Why not?

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).

@Lenbok
Copy link
Contributor

Lenbok commented May 28, 2017

  • When I check to enable support for my print, and then choose which profile I want to use, the checkbox sometimes gets disabled and sometimes does not. Why is this?

@alranel alranel merged commit 4ab4831 into master May 29, 2017
@alranel alranel deleted the gui3-shortcuts branch May 29, 2017 16:53
@alranel
Copy link
Member Author

alranel commented May 29, 2017

Thank you @Lenbok, answering your points:

  1. Shortcuts should not be used for options which are not safe to change on a per-print basis (perimeter and infill speed are part of fine tuning and I recommend you access them in the usual way, i.e. by opening the profile editor).
  2. Those were bugs, now fixed. Thank you for reporting them.
  3. Per-profile shortcuts are the key point of this whole change. If you have a spiral vase print profile, you don't care about infill or support material and you only care about Bottom solid layers. If you have a mechanical print profile you'll likely care about infill density, brim and support material.
  4. When you double click on objects, you set overrides for that single object. Each object can have different overrides, so it would make no sense to propagate overrides back to the general plater shortcuts (they wouldn't be overrides anymore).
  5. It depends on what the last value for it was when you last used that selected profile.

@Lenbok
Copy link
Contributor

Lenbok commented May 29, 2017

@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?

@rob-miller
Copy link

rob-miller commented Mar 26, 2018

I have read through this thread. I can only add my experiences and expectations.

  • When I found shortcuts in the development branch, I assumed they were a way to bring out my own preferred per-print options to the front page and make them easy to access.
  • I was surprised that the original profiles had been modified by these changes without any warning.

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.

@foreachthing
Copy link
Member

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).
And if I want to save those settings from the shortcuts back to the profile; this should be my decision.

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 ...?!

@rob-miller
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants