JohnOCFII
commented
4 years ago I would guess some of these are due to the cross-platform / least common denominator reasons. But others are certainly great items to add to UI cleanup lists.
Open JS3910 opened 4 years ago
JohnOCFII
commented
4 years ago I would guess some of these are due to the cross-platform / least common denominator reasons. But others are certainly great items to add to UI cleanup lists.
deepthought-64
commented
4 years ago Even though I am a non-apple user I find that you make some very good points. You got my vote! :+1:
Area5142
commented
4 years ago I agree that an UI clean-up would make the PS application much easier to use and unlock some now important "hidden" features. Coming from a Windows application developer background I see a conflict in the different platform guidelines - all sane and well proven. Following all guidelines would mean that menu-items and tools have to "move around" depending on the target platform. Selecting and sticking with one UI guide will properly be best even if it is a "little off" on other platforms.
As PS is growing in functionality it is more important with a consistent and predictable UI that unlocks the full power of PS.
Even as an experienced user of PS I often searched the menus/toolbars/shortcuts to find the feature I need. Some have shortcuts (toggle perspective), some can only be accessed by mouse (variable layer) and some only works in a special context. In the upcoming alpha I can convert between metric and imperial all over the place, even if I only needs it when importing a model or wants to select a working mode (in preferences).
JS3910
commented
4 years ago I don't use too many FOSS GUI apps, but all the ones I've checked on my computer so far so in fact make these platform specific adjustments, and since there's only two major platforms with guidelines and conventions (is there any Linux distro/desktop environment with design guidelines? All my Linux stuff is CLI 😆) then it should not be a tremendous effort.
I think it's much more important to maintain platform consistency for users rather than having completely identical interfaces on different platforms. When I'm on my Mac I look for preferences in the app menu, and on Windows I don't - that's knowledge you should expect your users to have.
I'm always a fan of breaking conventions, but then it has to be for a end user usability improvement and it's HARD. There's a lot of research, smart people and years of experience with trial and error behind these guidelines after all.
On Fri, 9 Oct 2020 at 14:01, Joakim Hjort notifications@github.com wrote:
I agree that an UI clean-up would make the PS application much easier to use and unlock some now important "hidden" features. Coming from a Windows application developer background I see a conflict in the different platform guidelines - all sane and well proven. Following all guidelines would mean that menu-items and tools have to "move around" depending on the target platform. Selecting and sticking with one UI guide will properly be best even if it is a "little off" on other platforms.
As PS is growing in functionality it is more important with a consistent and predictable UI that unlocks the full power of PS.
Even as an experienced user of PS I often searched the menus/toolbars/shortcuts to find the feature I need. Some have shortcuts (toggle perspective), some can only be accessed by mouse (variable layer) and some only works in a special context. In the upcoming alpha I can convert between metric and imperial all over the place, even if I only needs it when importing a model or wants to select a working mode (in preferences).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/4828#issuecomment-706140077, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPLTX2UYAKO44TZOLGPIYDSJ33RLANCNFSM4SCU3UWA .
bubnikv
commented
4 years ago In the upcoming alpha I can convert between metric and imperial all over the place, even if I only needs it when importing a model or wants to select a working mode (in preferences).
The late conversion is there for somebody who either loaded a model with unknown scaling, or simply for the time the user forgets that the model has different units.
You can never make everybody happy.
Area5142
commented
4 years ago (Comments only applies to alpha 2.3.0 version)
The late conversion is there for somebody who either loaded a model with unknown scaling, or simply for the time the user forgets that the model has different units.
You can never make everybody happy.
Can't remember the last time I came across a model scaled in imperial (in) units and had to convert it to metric before print, but it happens and there is a need for converting from imperial to metric and maybe also the other way around. I think using menu space in the right-click context menu for metric/imperial conversion is overkill - A sub-menu under Edit could be a solution:
Edit -> Scale -> Scale to print volumen
Convert from Imperial unit
Convert to Imperial unitThis would clean up the context menu to only containing the must often used actions to the current object. The Edit menu is properly not the right place, following UI guidelines there should be an Object top level menu with all operations that can be performed on the current selected object on the Plater.
The UI Imperial/metric:
checkbox in the right panel takes a lot of space and could be moved to Configuration->Preference configuration menu under General (Select units). Then it would follow what I find in other CAD systems - Selecting Units (in/mm), like I would select other application wide preferences. As it is now I can only change unit system when an object is selected - with no objects selected the system is locked, even between application restarts...
If it has to be a local value conversion on the input fields, the unit label "mm" could be changed to a dropdown listbox with the choices "mm" and "in". Or the numeric input could accept post-fix units like "mm"/"in" as some CAD program does.
bubnikv
commented
4 years ago Considering that the build plate may have a mixture of Imperial and Metric objects, I would love to see this conversion somewhere on the model context. Currently this feature is biting me often enough that I ignore the conversion and scale 2540% when necessary.
From the upcoming PrusaSlicer 2.3.0-alpha1 change log. You would not believe how much time it takes to put it together, as well as how much in house discussions went into these features.
We newly provide support for imperial units for our US customers. PrursaSlicer uses metric system internally, namely all internal dimensions (model sizes, model positions, print & printer profiles and G-code) is measured in millimeters. To make the life to our US customers easier, we now support imperial units in the following way:
The models are still imported / exported in millimeters by default, as most of the models available are in millimeters. However, we newly support the following:
bubnikv
commented
4 years ago checkbox in the right panel takes a lot of space and could be moved to Configuration->Preference configuration menu under General (Select units). Then it would follow what I find in other CAD systems - Selecting Units (in/mm), like I would select other application wide preferences.
We have discussed this option internally. We believe the US customers will enjoy having the checkbox at the object panel, but optionally the EU customers may want to hide the checkbox. That's what the alpha is for, to collect the user feedback.
As it is now I can only change unit system when an object is selected - with no objects selected the system is locked, even between application restarts...
If it has to be a local value conversion on the input fields, the unit label "mm" could be changed to a dropdown listbox with the choices "mm" and "in". Or the numeric input could accept post-fix units like "mm"/"in" as some CAD program does.
The current implementation is to some extent a least effort approach, similar to what IdeaMaker provides and much richer than what Cura provides. Surely we can always do better, but we need to roll out.
bubnikv
commented
4 years ago @JS3910 Thanks, you seem to put a lot of effort into your post.
Alert dialog button commands should be verbs This is almost all dialogs all over the place - like, "delete all" has the alert text "All items will be removed, continue?" with the responses "Cancel", "No" and "Yes". What's the difference between cancel and no? Responses should be "Cancel" and "Delete All" in this case for example.
On Windows, "Cancel" is a panic button: Don't do anything, get me out of here. Some of the limitations are given by the wxWidgets UI framework, though we can certainly try to bend our application around the wxWidgets limitations and/or implement some pieces of the UI code in a platform dependent way, which we are actually already doing in many places.
Anyway, pull requests, or just screenshots with proposed changes are welcome. Often the most effort goes into deciding how the UI should work. Very often the UI is a trial and error enterprise and please note than none of the PrusaSlicer developers is a native English speaker. It is trivial to do the change if we know what to do and we are open to some extent to implement some aspects of the UI in a platform dependent way if we know what to do.
Inconsistent right click context menu
If that is the way, we should fix it.
First person language
We will take your advice. Again, none of the PrusaSlicer developers is a native English speaker, some of us handle English better, some worse. Our content team is doing a review of the English texts when passing the dictionaries for translation, but the process is not perfect. Screenshots or better pull requests are welcome to fix the wordings.
The link to the application preferences window is in the wrong menu Display the Preferences menu item above other app-specific menu items. In general, a Preferences menu item should be the first app-specific menu item. About link should be in app menu and not help
OSX specific. We can fix them trivially if we know what to do. None of the PrusaSlicer developers are users of Macs, we are actually very lucky that our only tester Filip is. I personally am often extremely confused when having to use a Mac UI and I have to rely on Filip's judgement of what is the correct behavior. As a Windows user I actually find the OSX user interface extremely confusing, configurable to the extremes and I find every action accessible in multiple totally different ways.
Every toolbar button should have a corresponding menu item
I am not quite sure about that in case our toolbars are always visible.
Simple/advanced/expert should not be in the main window
We have some reasons to keep the buttons there. The parameter input fields are color coded the same way the simple/advanced/expert buttons are, so the buttons act as a hint to the color coding. The simple/advanced/expert buttons act as a quick way to unfold the advanced/expert parameters.
Provide menu items, not toolbar items, for accessing your app’s preferences. Toolbars are intended for frequently used items only.
??
View has a show/hide tab bar option (and "show all tabs) that don't actually show or hide the tab bar, but instead an additional bar that replicates the window title bar. In PS it makes no sense to hide the tab bar anyways so this option shouldn't exist.
That is another OSX specific thing that we have on our list to suppress, which was enabled by default by wxWidgets.
The tab bar has four buttons for navigating between windows, the 3d view and the three settings categories. This is inconsistent with the menu and hotkey setup which has five, separating out the plater and preview views.
We can separate the two groups, no problem at all. How about the hot keys? What do you propose?
In the menu the 3D/preview options don't work unless you're already in preview as well.
They should be grayed out then. Aren't they?
It would be more consistent and logical to not have the orphaned 2-button toolbar in the lower left corner and instead up top provide five tabs - Plater, Preview, Print settings, Filament settings, Printer settings. The view menu and hotkeys should also be consistent with this ordering.
The tabs are there historically and it is possible to suppress them in the upcoming PrusaSlicer 2.3.0-alpha1. I am not sure about putting the Print/Filament/Printer to the top toolbar, it is already quite large. About the orphaned bottom toolbar, I think that is a matter of taste. I heard only one other person advising to move it to the top toolbar.
Inconsistent menu item capitalization
Again, pull request would be welcome.
Proposed, consistent menu structure following the design guidelines
Thanks, we will review your proposals of menu reordering, likely for PrusaSlicer 2.4.
bubnikv
commented
4 years ago View has a show/hide tab bar option (and "show all tabs) that don't actually show or hide the tab bar, but instead an additional bar that replicates the window title bar. In PS it makes no sense to hide the tab bar anyways so this option shouldn't exist.
That is another OSX specific thing that we have on our list to suppress, which was enabled by default by wxWidgets.
That's one thing not supported by our wxWidgets, but supported by the wxWidgets master. A backport of this feature was required, recompilation of dependencies on developer machines and the build server. Quite a lot of work for such a little feature. https://github.com/prusa3d/wxWidgets/commit/f370ebf91d1bb107cc365974e12afb4202b3290d
Area5142
commented
4 years ago checkbox in the right panel takes a lot of space and could be moved to Configuration->Preference configuration menu under General (Select units). Then it would follow what I find in other CAD systems - Selecting Units (in/mm), like I would select other application wide preferences.
We have discussed this option internally. We believe the US customers will enjoy having the checkbox at the object panel, but optionally the EU customers may want to hide the checkbox. That's what the alpha is for, to collect the user feedback.
I agree that it is a needed feature to be able to select working measuring system - my feedback is merely regarding the implementation and placement of UI.
As an example in FreeCAD this setting is placed in Preferences and has the same scope as the PS alpha currently has. In Autodesk Inventor this setting can be done at Application or Document level. It was just my feedback that the right place for selecting system wide measuring system is in preference.
I would suggest that the current measuring system also be saved in project files (3mf) as an indication of the measuring system used to create the project. This could be useful at a later time to inform the user of the original measuring system.
The current implementation is to some extent a least effort approach, similar to what IdeaMaker provides and much richer than what Cura provides. Surely we can always do better, but we need to roll out.
I understand the need for roll out... PS alpha has a lot of new great features and the system is stable enough that the alpha is my primary slicer version right now ;-)
My experience, as a software architect, is that the longer fundamental UI changes is postponed the harder (if not impossible) it will be to implement them at a later time. Some of the suggestions and feedback in this thread is fundamental an fall in that category.
BTW I am not native English speaking either... and you are doing a great job with PS!
Version
2.2.0+ release version.
Operating system type + version
Mac OS 10.15.6
Behavior
Ok, so this turned into a much bigger post than I originally intended, but I got warmed up so I'll just leave it as input and suggestions and you can do as you will with it 😆. I probably forgot a bunch of stuff I had opinions on as well!
Obviously, the human interface design guidelines are guidelines and not mandatory, but there are some things that should be followed to maintain platform consistency and reduce user confusion. Some of these are just universally good design and not mac-specific as well.
https://developer.apple.com/design/human-interface-guidelines/macos
Alert dialog button commands should be verbs
This is almost all dialogs all over the place - like, "delete all" has the alert text "All items will be removed, continue?" with the responses "Cancel", "No" and "Yes". What's the difference between cancel and no? Responses should be "Cancel" and "Delete All" in this case for example.
Inconsistent right click context menu
For some reason, there are many more options in the right click menu if you click on an object in the 3D view compared to clicking on it in the object list on the right hand side of the screen. They're both referring to the same thing so there doesn't seem to be a good reason for this.
First person language
The computer is not a person. For some reason when you try to change gyroid infill to 100% the alert dialog asks if "I" should change it.
The link to the application preferences window is in the wrong menu
As stated in the Apple design guidelines, the proper place for application-wide configuration is at the top the App Menu (the one that gets the name of the currently selected app). In PS they are currently in a menu called "Configuration" where these things (preferences, mode, language and preset configuration) are mixed with things that are not configuration at all (check for software update and printer firmware flashing). Also configuration-related option "show configuration folder" is randomly in the "Help" menu.
About link should be in app menu and not help
Yes, I realize they say both "preferences" and "about" should be first 🤔. All other apps I'm testing, including first party Apple ones have "about" as the first option and "preferences" as the second.
Every toolbar button should have a corresponding menu item
Currently the following toolbar buttons have no menu item associated with them: Top toolbar
Left toolbar
Simple/advanced/expert should not be in the main window
I'm sure this confusing option is only ever used to set it to "expert" when you find that important print settings are missing, and it's definitely not something you interact with on a regular basis, therefore it should be in the configuration section of the app menu and nowhere else.
View, Window menu and tab bar confusion
"Print host upload queue" does not navigate to another window, but instead opens a tool similar to the firmware uploader (which is in configuration).
The tab bar has four buttons for navigating between windows, the 3d view and the three settings categories. This is inconsistent with the menu and hotkey setup which has five, separating out the plater and preview views. In the menu the 3D/preview options don't work unless you're already in preview as well.
It would be more consistent and logical to not have the orphaned 2-button toolbar in the lower left corner and instead up top provide five tabs - Plater, Preview, Print settings, Filament settings, Printer settings. The view menu and hotkeys should also be consistent with this ordering.
File and edit menu items mixed around
"Reload from disk" is a file operation but is in the edit menu. "Reslice now" is a document state operation but is in the file menu. Clearly these two positions should be swapped. Repair STL also feels more like a "tool" link than a file operation.
Inconsistent menu item capitalization
Proposed, consistent menu structure following the design guidelines
I tried to catch all the hidden or semi-hidden features as well to make them discoverable.