An exercise in UI/UX design

[sliptonic]

We're starting to build a Developers Handbook to provide a consistent vision and direction for where we want the application to go in the future. The handbook is a long way from done (it'll never be 'done') but it already has some good stuff.

One area that needs a lot of work is the stylebook. The goal is to describe general principles for how we design and use various visual elements. We get lots of complaints from users about FreeCAD's steep learning curve and much of this comes from inconsistent UI/UX practices. So the stylebook should eventually help make things more uniform.

I'd like to try an exercise:

I've written a draft of the page on task panels. This is just a first pass off the top of my head.

Now let's have a discussion about one task panel.

For our test case, I'm looking at a panel that I hate more than my dog hates the vacuum cleaner: Shapestring

2023-04-18_12-21.png (22.87 KiB) Viewed 1914 times

Here are the things that I see wrong with this off the top of my head:

• The point of the dialog is to create a string. But the string input is buried halfway down the widgets. It should be the first input. (5.1)
• Font file should be second (5.1)
• Height should be third.(5.1)
• Creating a shapestring isn't resource intensive, why doesn't this show the preview in realtime? (2.1)
• If it can't show a preview, why isn't there an 'apply' button to show the preview? (2.2)
• A font is absolutely necessary but users probably don't know where the font files are located. Can't we show a list of installed fonts? (??)
• The string input has 'default' as the text. This isn't a placeholder, it's a default value. Defaults should be a best guess at what the user needs. It's very rare that the user actually wants to put the text 'default' into their document. This should be a placeholder. (4.3)
• The 'OK' button should be disabled until a string is entered and a font selected (??)
• The XYZ location coordinates are weird. It starts by showing the current mouse position. But only until you click. Then it shows the coordinates of the last place you clicked. (??)
• What the heck is 'reset point'? All it does is sets the xyz back to zero and make the coordinates reflect mouse pointer location again. (??)

What else did I miss?
Are these guidelines reasonable? Would they help improve the design?
Tell me what additional guidelines are needed, especially for the ones I marked (??).

[MisterMaker]

Lots of good points, I would understand someone finished the function got it working then thought. I am going to polish it later one, then stuff happened.
From a theme design style I don't like how lots of theme's have text with a different background color it clutters the menu. Also we have an empty border with a border, which is double up.
Since there is a rest point, I wonder why isn't there at least an apply button that would just apply the function and then edit it. That is also how I ended up using it.

A point is btw not parametric, and it would be way better to use a sketch entity as a base.
I cleaned it up a bit in EPD.

[chennes]

For font selection it should be using QFontDialog, no?

[jimb]

What else did I miss?

Alignment of labels and the associated values looks random to me.

A font is absolutely necessary but users probably don't know where the font files are located. Can't we show a list of installed fonts? (??)

This might be a bit beyond what you are asking about, but the big issue I see is the actual path to the font file. Embedding a system dependent path in the the FCStd file doesn't seem like a good idea to me. Is there anything that can be done to make the font selection be system independent and portable? Some probably bad ideas:

1. embed selected font file in FCStd file (possible licensing issues)
2. bundle some fonts with FreeCAD and encourage people to use those by defaulting to that list but still allow user to specify any font with an appropriate warning.
3. both a and b

[Roy_043]

double clicking should show THE SAME task panel to edit the object. (I’m looking at YOU, Draft workbench! You too, Arch)

Not sure who made this comment. I have worked on the context menus of Draft and Arch objects. If there are any remaining problems I would really like to address them. So please create a proper issue on GitHub. Thanks.

[jbraun]

For font selection it should be using QFontDialog, no?

Looks inkscape-ish.
inkscape knows where the fonts are, /usr/share/fonts/truetype/malayalam/font isn't something users enjoy searching for.
Also yes to previews please.

[MisterMaker]

Would be nice and educational if we could look at the code.

[wmayer]

For font selection it should be using QFontDialog, no?

The QFontDialog as it is won't work because the shape string function requires the path to a .ttf file which a QFont/QFontInfo doesn't deliver. What may work is to get the list of directories of possible font files and search there recursively for .ttf files. Register them and then make sure that only True Type Fonts are displayed in the dialog or a combo box.

See also: https://stackoverflow.com/questions/190 ... font-in-qt

[sliptonic]

double clicking should show THE SAME task panel to edit the object. (I’m looking at YOU, Draft workbench! You too, Arch)

Not sure who made this comment. I have worked on the context menus of Draft and Arch objects. If there are any remaining problems I would really like to address them. So please create a proper issue on GitHub. Thanks.

Sorry. The snark was entirely my fault. I meant to return and rewrite this section a little more professionally but it slipped by.

What I'm referring to still exists in Draft. All of tools like Line, Polyline, Polygon, Bezier, Rectangle, etc exhibit the same UI behavior. When you initiate them, you are in a task panel for creating something. Same thing with ShapeString. After completing the task, an object exists in the tree. While the ShapeString panel sucks for the reasons described above, when you double-click on the tree node, at least it comes back and you are on familiar ground to edit the thing.

But when you double click on any of the other objects, you're in a blank panel with a single 'close' button. The behavior is inconsistent and jarring.

That's why I wrote the stylebook rule the way I did. If the user is given a nice task panel for creating something, the same task panel should be presented for editing the thing when the tree node is double clicked.

We also need to add a rule about the use of the Esc key. I don't know what the rule should be. What should pressing the Esc key do? Within Draft, it usually means to end the task as if you pressed 'ok'. Within ShapeString, it means exit the task as though you pressed 'Cancel'

[Roy_043]

But when you double click on any of the other objects, you're in a blank panel with a single 'close' button. The behavior is inconsistent and jarring.

This is the task panel that belongs to the Draft_Edit command. For the mentioned objects reopening the original task panel is not necessarily logical. Imagine a Draft_Wire with dozens of points for example. To understand the Draft_Edit command the user does have to read the manual.