UI Improvements / Vertical UI Proposition

[Kunda1]

The tooltip should definitely pull the hotkey that's in the parameters.
I will open a ticket. It's not urgent by any means, but it definitely needs to be addressed.

Agreed. Can you x-post the ticket back to this thread when you're done? Thanks. Maybe yorik may know how we could change this without having to trigger translations of the strings over again?

[Petrikas]

The tooltip should definitely pull the hotkey that's in the parameters.
I will open a ticket. It's not urgent by any means, but it definitely needs to be addressed.

Agreed. Can you x-post the ticket back to this thread when you're done? Thanks. Maybe yorik may know how we could change this without having to trigger translations of the strings over again?

https://tracker.freecadweb.org/view.php?id=4664

I accidentally double-posted, as I received an error that my image could not be uploaded, after pressing "submit".

"APPLICATION ERROR #503

Invalid upload path. Directory either does not exist or not writable to webserver.
Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section."

Sorry about that.

[Kunda1]

Sorry about that.

No worries. It's been fixed.

[openBrain]

Just a note - we should avoid hard-coded hotkey hints in the UI, it's very disorienting.

Why do you say it's hardcoded ?

[openBrain]

Just CCing some folks that would be interested in this:

pinged by pinger macro

I'm not the right client for this. I mostly don't care of the UI as long as I can work with. If I could do CAD piping bash commands, I'd do it.

[Petrikas]

Just a note - we should avoid hard-coded hotkey hints in the UI, it's very disorienting.

Why do you say it's hardcoded ?

Some of the tooltips contain hotkey hints that do not correspond to the hotkeys set in parameters. I assumed they are simply typed-in (included in the tooltip text)

I'm not the right client for this. I mostly don't care of the UI as long as I can work with. If I could do CAD piping bash commands, I'd do it.

It's not about making the UI beautiful - that is very subjective. It's about making it 'tidy' and 'UI/UX-error-free'. To me, best UI is no UI, but if we want to make FreeCAD available to everyone, we have to make sure that their first steps are solid. That means getting rid of annoyances, distractions, inconsistencies, confusion and helping users build muscle memory.

It's also why I'm not suggesting some Photoshop-made UI concept pdf, but rather small fixes that we can do today, to look more inviting, to make people feel more at home, to show newcomers (and 'fence-sitters') that we are taking things seriously and we're a fully-functional CAD system.

You guys did an awesome job on FreeCAD. I've recently delivered my first Product Design project, made completely from scratch with FreeCAD. The back-end and the core of FreeCAD is damn-near ready 'for production'. The interface isn't quite there yet. But I want it to be. (That's why I started fixing it for myself, and thought I'd drop the changes as a suggestion in the forum)

[openBrain]

Some of the tooltips contain hotkey hints that do not correspond to the hotkeys set in parameters. I assumed they are simply typed-in (included in the tooltip text)

I knew that mainly for 'Python coded' workbenches, but not for the C++ ones as you shown in the screenshot.

It's not about making the UI beautiful - that is very subjective. It's about making it 'tidy' and 'UI/UX-error-free'. To me, best UI is no UI, but if we want to make FreeCAD available to everyone, we have to make sure that their first steps are solid. That means getting rid of annoyances, distractions, inconsistencies, confusion and helping users build muscle memory.

It's also why I'm not suggesting some Photoshop-made UI concept pdf, but rather small fixes that we can do today, to look more inviting, to make people feel more at home, to show newcomers (and 'fence-sitters') that we are taking things seriously and we're a fully-functional CAD system.

Don't get me wrong. I'm absolutely not opposed to ones working on the UX/UI. But I'm neither a designer nor a client of such activities.

[Kunda1]

openBrain, thought i could ping you JIC you could provide some coding insight if needed. Feel free to unsub from thread if necessary.

[openBrain]

openBrain, thought i could ping you JIC you could provide some coding insight if needed. Feel free to unsub from thread if necessary.

No problem. I of course can give clues about coding (in the extent of my own knowledge).
As a general point of view, this is IMO very difficult to achieve something real with Python patches. UI shall before everything be 100% reliable. Python hacks are very cool for slight modifications/improvements and proofs of concept, but as soon as we want something serious we have to go back to C++ -- this isn't a general consideration regarding Python vs. C++, but due to FC code architecture --.

[Petrikas]

openBrain, thought i could ping you JIC you could provide some coding insight if needed. Feel free to unsub from thread if necessary.

No problem. I of course can give clues about coding (in the extent of my own knowledge).
As a general point of view, this is IMO very difficult to achieve something real with Python patches. UI shall before everything be 100% reliable. Python hacks are very cool for slight modifications/improvements and proofs of concept, but as soon as we want something serious we have to go back to C++ -- this isn't a general consideration regarding Python vs. C++, but due to FC code architecture --.

Please don't take my monkey-code as something that should be implemented in the master branch It's something I wrote for myself, but since I decided to post this suggestion, I thought I might as well post the code snippets I used.

---

Talking about further improvements, I think there really needs to be a hard-cap of how many toolbuttons can fit in one toolbar. So far, the longest toolbar I found was in Fastener workbench, with 66(!!!) tools, in a hard line.

sc 2021-05-25 14_03_14.jpg (310.12 KiB) Viewed 4009 times

It doesn't even fit horizontally on a 1080p screen.

My proposed limit would be 20 tools in one toolbar. This would nudge the workbench devs towards making slightly more user-friendly workbenches. (In case of Fastners, there could be expandable buttons for each type.)


Here's another example, with 25 toolbuttons.

tools.jpg (81.43 KiB) Viewed 4009 times

This is the workbench I spent most time in, so here's an example how this could be split and re-ordered:

sections.jpg (177 KiB) Viewed 4009 times

It could be split into Feature-based and Body-based toolbars. (Simple, easy to understand)

OR, each of the tool in the Additive-Subtractive group could join to become a single tool. I.e. the difference between a pad and a pocket could be a single button or a tickbox in the Task Panel. (I assume requires much more work and the results might be questionable)

Limiting the toolbuttons per toolbar to ~20 guarantees that they fit both vertically and horizontally and lets the user to use their toolbar space more efficiently, so you don't end up with one really long bar and one short bar, that takes up the whole toolbar line.

This doesn't really matter, but worth a mention: better segmentation will also lead to better customisation. There are no reason to have some of the toolbars active, if the user already learned the shortcuts for them. Personally, I can't remember the last time I clicked on a Fillet or a Chamfer, but if the toolbar was split, I would have the choice to enable/disable it.

I am fully aware that too much customisation might be confusing. But this is more about consistency in UI than customisation.