Update index.md

[sliptonic]

UI/UX use of the status bar should be standardized to make the UI more consistent.

[Roy-043]

Issue that has probably sparked this PR: https://github.com/FreeCAD/FreeCAD/issues/10812

There is a difference between consistent and standardized. In the case of FreeCAD we obviously cannot aim for a standardized GUI as each WB is different. So why then aim for a standardized status bar?

_2. The status bar should only show tools that are consistent and usable across all workbenches. Individual workbenches should not add tools to the status bar._ I see no good reason for this restriction. A WB may want to use it for specific purposes that fit very well within the concept of a status bar.

Maybe the rule can be: If a workbench adds widgets to the status bar they should appear in a certain, to be determined, location and they should be optional.

The current Draft status bar widgets are optional.

[sliptonic]

Actually, I was unaware of that PR. Thanks for pointing it out.

I think what I'm trying to point to is that we would be served well by thinking about how the overall FreeCAD application behaves as one realm and how the individual workbenches behave within that system as a second realm. Consistency between workbenches would be great but they are going to be different because they serve very different needs.

On the other hand, the same user will move between workbenches so consistency at that level is even more important. Currently, there is very little of that kind of consistency. Toolbars can move around. task panels can be repositioned. comboview behaves differently depending on user settings that are complex and interact with each other, themepacks change colors, fonts, and other attributes. All these options are nice but also erode the predictability of the user experience and users are overwhelmingly complaining about it.

I'm speaking from a position of knowledge here. I've had more than 40 1:1 conversations with users over the last 6 months and it comes up in every single conversation. Users are frustrated.

So let's start talking about what we can stabilize at the application level. Let's put some guidelines in place before we make the situation even worse by polluting the status bar with even more noise.

[Roy-043]

I think you are confusing the issue. Nobody is against consistency and we all want to see the position of toolbars and other GUI elements to be more stable.

We accept that a WB injects menus in the menu bar and adds its own toolbars. I fail to see why the status bar should be off limits. Have the people you have talked with actually mentioned the status bar?

before we make the situation even worse by polluting the status bar with even more noise.

I really dislike reading such sentences. They turn constructive dialogs into debates. In most debates people have preconceived ideas about what the outcome should be, they only want to win.

[sliptonic]

I fail to see why the status bar should be off limits. Have the people you have talked with actually mentioned the status bar?

It shouldn't be off limits to developers. It should be restricted to application-level controls.
People consistently say that the "application" doesn't feel consistent. They only rarely talk about inconsistency within a workbench. They don't say things like, "Part Design dialog X doesn't work like Part Design dialog Y". They say things like "Part Design does X. But FEM does Y"

By way of analogy, I think about how Android works. Applications can't add controls to the notification area or the settings. When you pull down from the top, the contents and behavior of the control areas is always the same regardless of which app you are in.

I think we need those islands of stability at the application level.

before we make the situation even worse by polluting the status bar with even more noise.

I really dislike reading such sentences. They turn constructive dialogs into debates. In most debates people have preconceived ideas about what the outcome should be, they only want to win.

There's nothing wrong with a debate as long as it doesn't become an argument. I don't have preconceived ideas about the outcome and I'm willing to have my opinion changed but I do have a strong opinion (backed up by logic, experience, and user comment) on this point. I think a synchronous (zoom/jitsi) call would be much more productive and less argumentative though. Want to chat?

[yorikvanhavre]

It shouldn't be off limits to developers. It should be restricted to application-level controls.

I don't really understand what that would mean... If you remove the workbenches, FreeCAD has literally almost nothing except "open" and "save". What good would it do? What would be there then? Why do we need a status bar at all then?

Besides, why this restriction at all? What good dos it bring to FreeCAD users? Is the status bar changing from WB to WB something really too hard to understand for anybody?

By way of analogy, I think about how Android works. Applications can't add controls to the notification area or the settings. When you pull down from the top, the contents and behavior of the control areas is always the same regardless of which app you are in.

There is a reason for that, the android notification area contains a lot of stuff already and needs to be accessible at all times. Indeed we should not stuff the status bar with just anything. We need some rules there. But I also don't think we should PREVENT workbenches from using it.

[sliptonic]

I don't really understand what that would mean... If you remove the workbenches, FreeCAD has literally almost nothing except "open" and "save". What good would it do? What would be there then? Why do we need a status bar at all then?

Not true. There's lots of stuff and we're actually on the right track with some of it. Things I think definitely belong in the status bar:

1. Mouse model control. (It could be smaller but having it here is easy and makes it easy to support users.
2. Unit selector. Users actually need to change this more often than we expected. When you change the unit schema, it changes across all workbenches so it makes sense to control it here.
3. Grid display toggle. This SHOULD be on the status bar. It SHOULD NOT disappear just because you left draft wb. It should always be visible.
4. Snapping controls and selection filters. Again, these should be consistently toggled regardless of which WB you are in.

Besides, why this restriction at all? What good dos it bring to FreeCAD users? Is the status bar changing from WB to WB something really too hard to understand for anybody?

I've said a couple of times that users are asking for more "application level consistency" and I think the status bar is one place we can provide it. Now let me turn your question around the other way. What good does it bring to users to allow workbench controls in this area? Toolbars can be positioned on the top, left, right, and above the status bar. What is so special about the status bar that WBs need to add controls specifically to it?

[yorikvanhavre]

But then you are advocating for Draft stuff to stay active even outside Draft, which a lot of users don't want. And really, the draft grid and snap tools have little sense outside Draft.

Now let me turn your question around the other way. What good does it bring to users to allow workbench controls in this area? Toolbars can be positioned on the top, left, right, and above the status bar. What is so special about the status bar that WBs need to add controls specifically to it?

Ah there I agree with you. The status bar is an annoying place... We should do as much as possible in dock widgets and toolbars and as little as possible in the status bar.

That said, didn't @realthunder find a way to make widget drag-n-droppable to/from the status bar?

[sliptonic]

But then you are advocating for Draft stuff to stay active even outside Draft, which a lot of users don't want. And really, the draft grid and snap tools have little sense outside Draft.

It's a difference between short-term and long-term goals. The grid shouldn't be 'Draft stuff'.
Long term, there should be only one grid and snap system and the controls for it should be predictably placed. Short term, we have to live with multiple grids so we do what we have to do to make it behave correctly across all wbs.

As of right now, if the Draft grid is visible and you're in Draft wb, you have four ways to toggle it off. If you're not in Draft WB, you have zero ways. It's ridiculous. You have to switch to Draft to turn off the damn grid. One single way that is always visible everywhere would be more than 4X better than four solutions that are only available in one WB.

[onekk]

As there are many incarnations, but as example a wordprocessor usually show some informations, like "language used, keyboard used, line an col number where the cursor is placed" and similar things, maybe even if the work processor has modes even a "mode indicator".

In FreeCAD probably "3d view" position, a selection indicator (how many things I have selected), and probably if there is any "what selection filter" I'm using, and similar things, but many usera have asked even for "solid informations" and measurement things, as found in others cad like as example for a "linear edge" the coordinates of the start and ending point. this could make sense, but as real estate is limited, this pose some problems of choices.

How about in adding a "workbench status area" in a Predictable place where the WB should put his informations?

It has obviously been consistent in all WB, so as example Sketcher WB will put here relevant informations, but if I switch WB the new WB will put here his informations, but if I switch back, FreeCAD should remember "last show things" for every WB,

About user helps, probably a "default user theme" should be "put together" and some checks has to be done in Wiki Pages that every "tutorial" will use these settings, and the user should be advised to switch to this "default user theme" to be able to follow the tutorial. but this is OT here.

Regards

Carlo D.

[Roy-043]

Having a permanent grid widget in the status bar may not be such a good idea. What if the MDI area shows a spreadsheet? And if we switch to a grid per 3D view, and mutliple views are visible in the MDI area, which grid would be toggled?

[sliptonic]

Having a permanent grid widget in the status bar may not be such a good idea. What if the MDI area shows a spreadsheet? And if we switch to a grid per 3D view, and mutliple views are visible in the MDI area, which grid would be toggled?

Good questions but all can be addressed. Right now, with multiple views open, the grid button on the status bar in Draft toggles the active 3D window grid. If the active window isn't a 3D window (macro editor or spreadsheet), it toggles the first 3D window. Not ideal but hella better than having to switch workbenches to turn off the grid.

We don't have to go all the way to perfect in one step. Don't make perfect the enemy of good (or better).

[Roy-043]

What I was trying to convey in my previous comment is that having a static status bar may not make sense. I have just used the proposed grid button as an example.

[yorikvanhavre]

What I was trying to convey in my previous comment is that having a static status bar may not make sense. I have just used the proposed grid button as an example.

I agree... Fundamentally a place that shows statuses is dynamic. And it should be. Status displays should always change based on the context.

Now of course I support the ideas of 1) unifying the UI more, and 2) Having cool systems found in specific workbenches (such as the draft grid :innocent: ) become FreeCAD-wide. Also 3) Defining better what should go or not go in the status bar.

But making it something more fixed and static is IMHO a wrong direction.

[sliptonic]

But making it something more fixed and static is IMHO a wrong direction.

I'm going to close this PR. We can argue until the cows come home about abstract concepts but what matters is first setting a vision for how the application should work and then trying to adapt the UI to conform as much as possible.

Let's see what happens with the design review team