[Draft] Concise Sketcher Toolbars #11717
Conversation
|
As a daily Sketcher user, I will compile and test this PR but one thing I can say beforehand, Sketcher_CreateLine deprecated is definitely a step too far. |
|
What does line bring to the table that poly doesn't? |
Why ? |
There are 2 other ways to exit a sketch neither of which requires a button on the toolbar. The escape key, and the task panel. |
|
@obelisk79 you’re right! I think this button should be labelled “exit sketch” and have the right icon. On my system (Kubuntu) with the default theme, using the AppImage version, there is a cross. BTW, shouldn’t this PR be a draft? |
Maybe, I'm still relatively new to github and contributing to open source. |
If at the very least Polyline worked with the same consistent key presses it would be a start and I wouldn't mind if there was a drop down with both under one icon (if space is the primary reason here) so it remembered the last used. But how many 2D apps don't have a Line button, I'm not aware of any, it's absolutely de-rigor? |
Some have a line button that is actually a polyline button (well, just line segments at least). Alibre and Solidworks do this. In 2D CAD, QCAD does. In graphics design, Inkscape as well. I don’t have numbers but it seems pretty common. It may be common enough not to be confusing. Sure, forum conservatives will be against that but they’ll get over it. |
|
Did some testing:
|
|
Polyline as FC Sketcher has is a multi segment line tool. No AutoCAD user would recognize it as a Polyline. A Polyline has width, fill, and the segments, represent a contiguous line. |
There can be, actually: if the axis line type is implemented (see #7334). Though this is out of the scope of this PR. |
I disagree with this. It is the simplest geometry, but the most used theoretically is polyline. In this instance, I think this is just an issue of familiarity. In my sketcher toolbar meta-analysis, create point was first only in Catia and FreeCAD. |
There was a problem hiding this comment.
IMO this doesn't improve clarity
There was a problem hiding this comment.
do you have any suggestions how this could be improved? I modeled this after other similar software, although slightly different.
There was a problem hiding this comment.
Personally I find the current icon to be very good already, but if we need to make it different from the dedicated tools I kinda like how the one from onshape looks:
very similar to your idea, but the point shouldn't be floating in empty space attached to a confusing dashed line that doesn't seem to represent anything from sketcher.
There was a problem hiding this comment.
I would like that this be proposed on a separate PR so it can get merged quickly. IMO it helps in understanding this tool as the simple cross is too ambiguous
|
This PR is available for testing via Snap: you can find the instructions for installing it in this PR |
|
From discord I guess the proposition is : Here are some thoughts :
|
|
Is it possible to overhaul the constraint icons in general with this update? They all have a different line width / thickness and orientation (tangent in itself has different lines and compare the thick perpendicular with the thin align tool). Besides these I like the PR |
With the tools you are bringing, that makes sense. A transforms toolbar would likely be more fitting.
Carbon Copy imports geometry rather than copies it. The construction toggle does bring a layer of consideration though.
Grouping polygon would be bad in my opinion. It is used more frequently than you assume. I don't see the confusion, however I don't see a problem with rectangle, circle, arc, polygon, slot. I put the slots afterwards because they are composite geometric shapes. Important but different.
Admittedly, I don't think any of the in-use icons effectively convey what coincident does. I made a poor interpretation of the symbology used in other CAD. I modified it to look like this instead.
I agree.
I don't think this needs to move beyond its own toolbar. Many people never use the grid, this way they can hide the buttons.
Doing that would be a major deviation from the rest of FreeCAD and poor for consistency. Sketching is a task, we exit tasks in nearly every other instance by hitting escape or buttons in the task panel.
I don't care much about this either way, I think it is rather semantic to argue one way or the other. |
|
Removing the Close button would introduce inconsistency. I think most say they don't even know there is an icon for exiting the sketch. Many turn off esc to exit sketch because it is too easy to hit esc to exit a tool and unwittingly end up exiting the sketch. |
I don't think this is such a good idea, deactivating a constraint is pretty useful to fix flipped sketches and similar situations so I don't think it's a good idea to make it hard to discover. |
The argument is that toggle to reference can be used in the same way. In most cases, this is true. As I've pointed out elsewhere, there is no reference coincident, For, that deactivate is the only option. Deactivate should definitely not go away, Whether it needs to have a prominent presence, I'm not sure, it is not something that a user would likely decide to use without instruction on why and when. |
It's also available in the constraint list contextual menu (right click), and from the toolbar menu where it's much easier to discover anyway. Grouping reference and deactivated is therefore a good idea in my opinion. |
|
While some of the decisions can be good, specially in light of the new DSHs, I think this PR tries to accomplish too much at a single time, while still Paddle's tools are being merged. I had deferred toolbar modification for a reason until all were merged. About design UX practices, I think most decisions are value judgements and they do not reflect the diversity of views and uses of all users of the community. In fact, the thread were all this started tells exactly that story, which one user here summarised quite well:
Which is tantamount to saying: let's merge this and whoever does not like it, get over it. With all due respect, we could also ditch this PR and have proponents of it "get over it". It is not really nice in either direction and whoever promotes that should feel ashamed. Instead of looking at other PRs, I am going to give this a look at risk it drives an irreversible wedge. |
It was not was I was thinking when I wrote that sentence. I believe that the “conservatives” will think that this wouldn’t be that bad, and that they could even end up liking the result. We have the same goal: making FreeCAD better and allowing users to fully customize the program. We have a different viewpoint, if only because you are a programmer and I am a professional CAD user, and there is no other CAD community where this mix of different backgrounds can exist. We basically disagree on the defaults. You mentioned profiles on the forum: it’s a very good idea. I believe that grouping tools is good because you can achieve 80 % of the work with a few select clever tools, and the more specialized ones are thus better out of the way—but they should be easily available for the remaining 20 %. When several commands do basically the same thing but the two work in specific cases only, I don’t see why they should be separate (the case of coincident and point on object). When there are commands that does only a subset of what an other do and the “big” one doesn’t require more than a right click to emulate the other, I don’t see why either there shouldn’t be grouping. I will never advocate for removing all constraints commands from the toolbar if #11413 is implemented because it will negatively impact discoverability. This is just my point of view. We are here to discuss what we think about the toolbars. Nobody is willing to become a UI/UX dictator. |
|
@abdullahtahiriyo I don't want you to waste your time on my PR. I made this PR to allow for real world testing of different toolbar setups because the current paradigm of show the user everything so they can 'find' it is unmaintainable as FreeCAD continues to grow and become more complex. Not to drive a wedge in the community. Conversely as FreeCAD's community and user-base grows in size there will always be users unhappy with changes that are made, so yes at a certain point someone will have to make a decision to accept that there will be unhappy users (even your power-users forum friends whom you respect) for the overall good of the project. Because there are so many inconsistencies which need to be addressed, and limited resources to do so I targeted toolbars as an easy first step which eventually would have extended to other workbenches. Sketcher was just the starting point. I'm closing this PR as I am growing continually frustrated in attempting to bring interface improvements and cohesion to the project based on more than just opinions. I also don't want to drive a core developer (abdullah) away because I am passionate about such things. FreeCAD has a problem with community toxicity and it is highly discouraging. It is like attempting to reason with a stone wall. This software has no interface design or user experience plan, and no coherent vision for one. If people don't want to understand that beyond the technical aspects of what the software can do and how the code should be structured, then apply the 'bike-shedding' label all you want. It was my (perhaps incorrect) understanding that there was a desire to bring an element of professional design review and improvements to FreeCAD. I've invested most of my personal free time over the last six months working on FreeCAD design, including learning new software, basics of coding in C++ with zero prior experience, studying industry standard practices and principles for UI/UX design all of which was apparently wasted in favor of a couple of sketcher 'forum experts'. |
|
Very sad. IMO the UX is the most important thing driving new users in and let them enjoy the software, continually growing the user base and therefore also people who can contribute to FreeCAD. |
obelisk79
changed the title
This is where the problem is probably - unfortunately it simply does not work that way. We (as people, in general) do not like changes - it is as simple as it is. This is especially true if change is forced to us by some external forces. It is true even if eventually the change is better for us. Professionally I work for the university as developer in our in-house software house. I deal mostly with frontend which also involves caring about UX/UI, accessibility and stuff like that. I'm no UX/UI expert in any way, but after dealing with such stuff for some time you develop a bit of understanding and learn thing or two. In my career there we did some major UI overhauls for our internal systems and it always works the same way. At first when we poll users the results have clearly negative sentiment - very similar to what we can read on the forums now. After about half a year we often do a repoll - of course in that time we fix some issues based on comments that we've got. The results are always a lot better and many people notice that the changes that we've made are in fact good and they simplify their workflows, increase readability etc. I am not giving that example to increase my credibility or something like that, but to illustrate that it does not work in a way that good changes will always be appreciated immediately. The funny thing is, that the best UI is the one which you don't notice at all, because it simply works so you don't have to think about it. There is even famous quote about that:
So for the good UI you won't ever have the moment of enlightenment because you simply won't think about it. UX/UI is also more related to psychology than engineering, we can't calculate the best possible way or anything like that. There are some good practices (often called "Laws") that can help us, some defined processes for dealing with UX (most of which are not available to us, as we don't have required tools like AB testing, telemetry etc). So it is hard to say anything without doing experiments and watching how users behave.
I think that your feedback in this particular PR is very good, it is based on arguments, it explains why you don't agree with certain decisions etc. We can work with such opinions to improve things. For example, we indeed should not remove the commands but simply hide them from UI - it might not even be a conscious decision in case of this PR. Simply it might be a result of not fully understanding how the system works and that it is possible to only hide the commands. Even if we differ on opinions we can probably work to solution that will satisfy everyone. In general I feel that discussions on GitHub are ok. Remember that this PR was not meant to be merged in that state, simply provided to create a test build that can be tested by the users. On the forum on the other hand we have plenty messages like:
In general we have endless discussions that do not result in anything useful and it is often hard for me to tell what the problem is actually. |
I was approached by members of the FPA to head up a design working group to help develop a design guide for UI/UX, and begin looking for relatively easy to implement impmrovements prior to the 1.0 release. My primary communication platform has been, and remains Discord. Last I checked, there was no formal group existing on the forum for holistic review and collaboration for improving and homgenizing the UI/UX across the entirety of FreeCAD. Because Sketcher happened to be the first place
While it may be controversial, it does bring a level of consistency which FreeCAD needs. Toolbar should not be the place in which functionality is duplicated from other parts of the GUI. A cursory overview of the principles and takeaways of the Design Guide may prove enlightening in this regard.
Removing it entirely from the toolbar was exactly my intent, perhaps 'deprecated' was a poor choice of words. However, there was unanimous agreement among the other members of the design team that the extra right click to escape polyline was trivial and acceptable. This behavior also mirrors comparable software almost universally.
I did not remove the functional definitions for any of the tools removed from the toolbar. I will revisit to determine what I changed which caused the problem. I'm sure with my limited experience and skills in coding that it was a simple mistake.
I had initially set things up this way. I think the use of the drop downs also becomes unmanagable with so many, so for the purpose of testing I was a bit more aggressive with proposed changes. I had also suggested that the polygon (hexagon) tool capture mousewheel events while this specific tool was actively drawing geometry instead of just relying on keyboard/combobox. I realize this conflicts with zooming, however while the tool is actively drawing a shape, an exception should be afforded to allow a more natural interaction.
This is valid, there should be two types of drop downs, one where the default remains static, and one where the most recent tool stays on the surface. I would expect that this need has been addressed in other software whith perhaps a solution which could be leveraged in FreeCAD.
The toolbar wasn't just changes, it was a reorganization, which agreed, did include a couple of arbitrary changes. The goal was to promote polyline as the primary tool for sketching freeform geometry, assuming that the overwhelming majority of users read, and therefore process, information in a left to right manner.
I largely agree that these require additional consideration. I have already started adapting the contents of this PR to address feedback and with consideration of many of the comments.
This is a specific change which is trivial to revert. There was zero dissent regarding it among the design team.
Initially we had not considered that this tool actually observes the status of the construction toggle status. I find that functionality to be quite odd. I believe I may understand what it was intended to provide, but it just seems quite strange. Shape binders, external geom reference, and normal copy/paste of a sketch in the tree view all provide very similar functionality. I view this as duplication of functionality despite there perhaps being nuanced and potentially unnecessary differences. This would be a conversation beyond the scope of toolbars.
I had considered that, however none in the design team had shared the view. In this, I actually rather agree. It is best practice to use geometric constraints first. I also didn't worry too much about it as it should be expected that the auto constraints of polyline would apply most requried relations. I think this is a chicken vs the egg debate however I will reverse this change.
It really does seem once the command is removed from the toolbar definition that keyboard shortcuts cease to work. Again, I'll revisit this.
this has been a topic of conversation in discord as a result of this pr. Since the combined tool is currently optional, I merely wanted to give it a unique visual identity so it was differentiated from the more discreet options it combines.
This merged tool is the standard in other CAD and they all use the terminology 'coincident'. I would note that FreeCAD is the outlier in this convention.
In the forum discussion which took place last year, the argument was made about degrees of freedom each constraint affected. However, when approaching this from a more naturalistic view, these are all forms of simple attachment. I think tangency is more complex and shouldn't be considered for a 'smart' application with these functions.
While you are not completely wrong in this. Once a button is added to the toolbar it becomes a tool to generate constraints. We can pursue ways to more quickly and efficiently apply constraints, or we can transit back and forth between the sketch and the toolbar to manage each one discreetely. Minimizing time processing a vast selection tools to get the same end result is generally considered a good thing. It is an offloading of complexity in decision-making from the user to the tool making logical inference based on easy to understand rules.
This may be another place where the 'tool settings' framework developed by paddle could be applied instead. I am not sure the grouping is particularly odd either. Group two state changing functions together with the assumption that one is more used than the other. With an absence of telemetry, some assumptions have to be made regarding user interaction until they have a chance to use proposed changes. Possibly both buttons can be offloaded to the task panel. However, the current implementation of right-click menu toggle in the constraints list is awkward to use and not nearly as discoverable as grouped functions on the toolbar. I consider that to be a poor alternative.
I think there's a great argument to be made here in favor of something such as a ribbon toolbar as they effectively handle large groups of tools much more efficiently, however that would be a much larger fundamental change to FreeCAD and certainly goes beyond a near-term goal to make improvements before 1.0 is released. |
|
@abdullahtahiriyo I think the U/J is fixed in the rotate PR. |
This is fix to issue mentioned in the FreeCAD#11717, on discord and forum that for smart dimension tool the chosen tool should not be remembered. This will ensure that the "smart" tool is always visible on the toolbar and other tools are accessible in case that such explicit choice is needed.
Addressed in #11745 which hopefully will get merged without much problem. |
|
Well, I must say I welcome the current constructive attitude and the will to code to fix issues. It rarely gets better than that. I do not judge people. I note issues with code and functionality. I attempt to be objective and make reasoned statements. I have full understanding and sympathy for people who are starting with coding or are recycling from other languages or from 20 years ago. None of us was born coding. We all have made coding mistakes. I continue to do them. In my experience, most of the rest also do. While I will never condone toxicity (in any form), I think this UI redesign effort (including the parts already "in") has suffered from a lot of poor communication (and everybody should be ready to admit, even if only to oneself, its share of blame). I will address "forcing change" vs "driving change" later. There is a huge difference between both and the (negative) reaction you see comes, in a very important part, from applying the first instead of applying the second. The final outcome codewise may be different applying the second (or may not), generally is better. The community aspect will be better for sure. At the same time, it would have been great that the FPA or you, had told me, as the maintainer of the sketcher, that this workbench had been selected for a design revamp beforehand. I am not FPA, but I am close to them and support them within my possibilities. That said, while you may regard the CDDG as a cheeky comment, that is the way it has worked for a long time at sketcher level. While perfection does not exist, I do not think we did that bad. I am rather proud of this approach and for me it is extremely important. Nothing about the FreeCAD without the FreeCAD community. To this, I have nothing against people discussion and synchronising in Discord, or elsewhere. But it needs to be discussed in the forum (with a lot of humility, open ears to listen and not just dismissing different opinions). Everything is open for discussion, but it is an exercise where arguments count and value judgements and arbitrary decisions are treated as such. The opinion of everybody is important. No argument/value judgement/arbitrary decision will have more strength because of entitlement or position. That also applies to me. I am no better than you. If a specific change faces strong opposition, the status quo ante has preference. This is not bad, but good, because forces the change driver to excel and compromise. I do not see compromise as failure. Failure is either functional failure or alienating another part of the community. I happen to have met change quite often in my life. I have often heard about people as inertial objects opposing change. I have found nobody opposing a salary increase for themselves. What is difficult about change is engaging people. The most important part of it is that people gets convinced (or at a minimum neutral) about the need for change and the improvements change will bring. People are seen as naturally opposing change because of how change is brought upon them and the intrinsic actual value of the specific change. If people understand the value of change, they tend to embrace change (or at least are neutrally skeptic about it), but they do not oppose it. You drive change when you arrive to that state. Otherwise you force change. No, it is not easy to drive change and it is not digital binary either. The humble goal is to make change be the farthest away from "forcing change". Last bit, I want this "us" vs "them" to stop (from both sides, no finger pointing, we reset and start anew). There is but a single "us" here. I will try to remind that to anybody. I will come back in a couple of days. I will read whatever you have written here and will take a look to your ideas and PRs. |
|
I would just interject here, that there never was an intent to "force change". There was, as you say, a misunderstanding of how an experimental PR was to be label. |
This is fix to issue mentioned in the #11717, on discord and forum that for smart dimension tool the chosen tool should not be remembered. This will ensure that the "smart" tool is always visible on the toolbar and other tools are accessible in case that such explicit choice is needed.
@adrianinsaval perhaps you can help me. I was experimenting with the deactivate tool this evening, and I can understand its uses. However, once you deactivate a dimension, how do you reactivate it since you can no longer select it in the 3d view? |
|
For the sake of furthering this conversation I'm just going to refer to these 'concise toolbars' under the assumption that we eventually get some kind of toolbar profile system implemented in FreeCAD. In the grand scheme of FreeCAD's user experience, there is an effort to implement a simple first run settings page which could allow for easy selection of concise vs verbose toolbar profiles. Continuing the conversation, I have tweaked and normalized the toolbar constraint icons: |
|
Revisiting the toolbutton organization I have evolved the proposal to look like the following: Note that the geometry toolbar is now dedicated to the creation of geometry, and the same ideology is applied to the constraints toolbar. Other functions have been carefully placed in a 'sketcher tools' toolbar with carbon copy, fillet, trim and external geometry placed at the left end for presumed default placement to the right of the geometry toolbar. In accordance with the Design Guide, this allows for all sketcher toolbuttons (assuming bspline tools is hidden by default) to fit in a single row across a 1080p display @24px scale with no klipping of toolbuttons. This saves on critical vertical screen space, while leaving all functionality still accessible with one exception. The deactivate dimensional constraint tool is not present here. This is only a tentative change, however it appears the tool is only effective at deactivating a constraint, and a user must use the constraints list in the sketch task panel in order to reactivate. This is considered bad UX (having to enable/disable a feature using two different modalities), therefore, unless there is an interaction I was unable to discover, my recommendation is to remove this from the toolbar. |
obelisk79
force-pushed
the
concise_toolbars
branch
from
5914cfa
to
66f172a
Compare
I think this makes more sense than grouping it under toggel construction
Since you're reworking the icons this might be a good oportunity to say that the block constraint icon doesn't make much sense to me. I don't have a better idea though, the lock icon from the lock constraint IMO communicates the meaning better but that one is used already. |
|
About the rendering order toolbutton, IIRC this functionality is mostly used to choose which object type has selection priority, would it maybe make sense to extend while in sketcher the available filters in the newish Part_SelectFilter command instead? |
|
Ok. I need to cover the basis first (sorry for dragging a little bit, but this is the first WB where this is being applied). If I understood it all correctly, the wider objective is to remove inconsistencies across FreeCAD, so that FreeCAD has a consistent UI/UX across all WBs. Q1) Do we have a document identifying the (major) inconsistencies of FreeCAD in terms of UI/UX? To address this, a FreeCAD Design Guide. Q2) Could I be pointed to it, so that I understand better the principles that are being applied to remove the inconsistencies. In some reviews I have seen over the Internet, one of the most persistent criticism has been notifications to the user (poorly written or difficult to understand messages and unnecessary messages). I have introduced a Framework (together with the notification area) trying to address this. Trying to reduce the amount of model pop-ups to a minimum (all pop-ups where the user can just say "ok"). However, there is a daunting task of identifying which messages are relevant, which ones need to be redrafted, which ones are only relevant for developers and should not be presented in the notifications area. Additionally, I think the Sketcher is the only WB were there has been an effort to reduce the pop-ups. Q3) Is consistent messaging something you want to address? |
There is one bug in the deactivate tool (or at least for me it is a bug, I have to track down changes to that section of code to see if it was intentional) that the value of the constraint is not shown (In the original version of the tool this was shown). This was important because one could see the value to which the dimensional constraint will "come back" after activation. However, I seem to be able to select constraints from the 3D view and reactivate them: Peek.2023-12-20.20-49.webmEdit: I forgot the version (that is today's main branch): |
The problem with the lock today, is that there is a "lock" constraining tool which has a lock as icon. So I wonder if that would be misleading. I have no fixed ideas either. I agree the block icon does not convey much meaning though. |
|
Could we entertain the idea of removing the lock constraint? I would think it's been superseded by the automatic dimensions tool |
It's a pretty long standing bug then. I don't remember a time when this didn't happen, it would be great if deactivated constraints were as easy to select as activated ones. If I'm being honest I haven't used the tool in a long time due to this annoyance. |
The goal is to develop, evaluate and apply a set of design standards to FreeCAD which would improve general consistency, efficiency and presentation across the software. A rather significant task. .
Linked in my previous response. .
Yes, this will be yet another significant task. Right now, I have tried to focus the DWG on toolbars. Next will come a review of task panels and potentially review of menu structures. The rationale was to find smaller actionable items which align with the parts of the design guide which the design guide currently addresses. |
|
@abdullahtahiriyo thanks for looking into the deactivate tool. A couple of questions: |
|
can we add right click menu actions to constraints in the 3d view? |
This is an experimental test of new condensed and reorganized toolbars for the sketcher workbench and is being submitted so test builds can be created and distributed to acquire broad user feedback.
This new arrangement is based on UX guidelines and principles as outlined in the FreeCAD Design Guide, and is a culmination of weeks of collaboration and discussion among the Design Working Group on Discord.
The following toolbar changes have been made:
Sketcher Edit Mode:
-Leave Sketch button removed. Sketches exit edit mode via Escape key.
Sketcher Geometries:
Sketcher Constraints:
Sketcher Edit Tools and Sketcher Visual:
Additional change