Case Study: Musescore (FLOSS cross-platform sheetmusic/scorewriter) UI/UX

[yorik]

As I understood (correct me if i'm wrong), using QML doesn't really unlock new features of Qt. It's just a more convenient way to code interfaces than coding them in C++/Python, and it allows some interaction to be coded directly in the interface file (as opposed to a coupled C++/Python file).

So for simple projects it's cool: most of your interface is "self-contained" in qml files. In the case of FreeCAD, though, most interface controls do pretty heavy stuff. So there, I guess using QML would be almost exactly the same as what we currently do with .ui files...

That said, this musescore interface is indeed gorgeous. I think there is a mix of a nice thinking with nice theming... I'm actually more intrigued by the theme they use we could try to find that and adapt for FreeCAD maybe? Even if it's qmlized somehow, it's probably just still the same old css as we use...

[yorik]

Just watched the accessibility video, this is really interesting (there is little relationship with QML, though).

One thing is specially interesting: They mention that they made their UI more "tabbable" (you can navigate through a "task" to perform using the keyboard, basically the TAB key to go from line to line until you finish the action. This is exactly how the FreeCAD task panel was designed (one more enlighting insight that Jürgen had, 20 years ago or so).

It is rarely used that way, though. Most FreeCAD task panels offer many things that need to be set simultaneously to complete the action. But we should think about this and try to look where this process could be "linearized".

[Kunda1]

AppShell, is this where the 'meat' is? https://github.com/musescore/MuseScore/ ... pshell/qml

AppShell - this is an architectural pattern that separates the UI structure from the content. In order to be able to change the structure of the application and the components separately, independently of each other. It also controls the loading of components.

it's just a container that defines the UI structure of the application and connects the application components to each other.

AppShell defines such things as toolbars, panels, central content, status bars, component life cycle, navigation, etc.

ref: https://github.com/musescore/MuseScore/wiki/AppShell

----------------------------------------------
Architecture

Each rectangle is a module in the system. Modules interact with each other through interfaces using dependency injection, actions and notifications.

ref: https://github.com/musescore/MuseScore/ ... e-overview

[adrianinsaval]

the saga continues: https://www.youtube.com/watch?v=Qct6LKbneKQ
very interesting story, would be nice to some day revamp FreeCAD's UI too but I think it's almost impossible to do to such extent without full time devs and designers.

I've seen before in this forum someone commenting that qml is where Qt focuses their development now and that QtWidgets are stale (if not dying), I wonder if it would be worth moving FreeCAD to a qml written interface, is there an equivalent to QtDesigner for qml? if not it would kinda raise the barrier for contribution, IIRC my first PR ever to FreeCAD was just modifying an ui file in QtDesigner.

[yorik]

the saga continues: https://www.youtube.com/watch?v=Qct6LKbneKQ

This is really interesting... Baffling how much they were able to achieve.

[Kunda1]

@yorik:
As @adrianinsaval mentioned above, this is the crux: the migration away from 'Qt Widgets' to 'QML'
Specifics:

phpBB [video]

[adrianinsaval]

I think the migration eases future development and gives them more artistic freedom regarding the look, but the big usability and experience improvement comes from having full time devs and designers as well as more formal user testing, rather than from using a different framework. What I'm trying to say is that big improvements can be made without migrating too.

[yorik]

The way I understand it, QML allows you to design way more advanced and customized widgets than the basic widgets that come built-in with Qt. In their case, there were a lot of things they wanted to do that wasn't possible/available with standard widgets. An really the result is stunning.

However, and that's an important point, musescore has been taken over by a company. There is now a professional team spending a lot of time on it. Their need for QML came also from the fact that they could spend a lot of time building design documents, preparing things, planning, building guidelines, testing, etc.

Also QML, contrarily to standard qt widgets, needs to be coded. No more graphical editor (as far as I know). This makes sense when only a handful developers will deal with that anyway. But when you have a community-developed software, like FreeCAD, using maybe less "shiny" features in favour of more widely, user-friendly, easily handed tools like standard Qt widgets with Qt designer, makes a lot of sense too. Same with our wiki. We could use shinier, kick-ass documentation systems. But we'd loose the easy entry that the wiki provides, and we would not have so many people wanting to contribute.

As Ton Roosendaal (father of Blender) says, your real asset is your community, not your software. I like that idea a lot. And BTW by looking at how Blender gets developed, it's still a community-developed project, although it has serious money pouring in. And notice that although they do work on the UI, they are absolutely not making it a nice shiny, polished, unified thing. People still call it an airplane cockpit

That said, of course there is a lot to learn and grab in the musescore case. We absolutely could do more "design" in FreeCAD (specially the Qt/coin interaction), and think of developing our own widgets where we need it (And with theming too it's possible to produce kick-ass results).

[onekk]

...
What I'm trying to say is that big improvements can be made without migrating too.

Crucial point is IMHO, a documented way of "making things with FC UI" as it seems that each developers has his own idea on "how to code Qt related things", this lead to a different ways of "placing things" and of "doing things" that will for sure confuse "new users" and sometimes old users that have not used a certain portion of FC.

I know also that this is not easily avoided as FC is "condensating more than 20 year" of development so it is "natural" that part of code are using some "old ways" and some "new ways".

But as it is not very documented (at least for users) how to make things with FC interface part. probably some efforts has to be made to try to make some "coding style" or at least "best practices" and iron out the differences around, at least for the "bundled WB".

It is not even clear for a casual user like me "how to tell FC to place a menu item before or after another menu item" as menu items are modified when you load a WB so some positions are not easy to predict for different WB activated, but this is only an example of problems I have had when trying to code something for a WB.

Another area is the "theme part" but there are already some developers discussing and trying to make a good job on this area, so I expect that something will be made (and judging from the developers involved I have no doubt that it will be a good work.)

Some thing to iron out seems to be also some "different behaviour" for similar tools (similar operations) among WB to name only the most used Part. Draft, Part Design, Sketcher, this is has been noted by some users, most of them newbies, but "first impressions" are important, as the new user could have "bad habits" from other program, but trying to guess what is the "casual user expected behaviour" should be a great improvement in reducing the "first impact" with FreeCAD. (I know that some different ways of doing thing are due to "very good reasons" but I think that not everything.)

Sorry for the intrusion, and for some involute thinking that are for sure in the above text.

Regards

Carlo D.

[onekk]

And notice that although they do work on the UI, they are absolutely not making it a nice shiny, polished, unified thing. People still call it an airplane cockpit
...

But how to deal with complexity? as airplane cockpit are not made to "impress users" or "confuse users", each button has his scope, and also here there are some efforts of "uniforming things" to reduce problems, that in this area are very dangerous, like some "aerial crash" has proven.

Obviously learn from other software is a good thing, but as example blender could be thought for a "casual user" better than FC but they have different scopes, so also the interface is different.

Usually Blender users are more used to use "artistic tools" than "engineering tools", so "average user" "knowledge base" is different, so you have to take in account what the user has used prior to "land" on FreeCAD (speaking only for "our" software).

And usually most software in Linux world were started as a "linux mimics" of "commercial software", and then evolved in a different thing, so even some mimics of "most used software" could be a interesting "point of view" to take in account, when rethinking the interface.

But IMHO the interface has only to be "polished" and not "totally modified", as it has proven to "be usable", so trying to see what "new users" find "most challenging" could be a good way to make some "incremental improvement". I know also that is very difficult as each user has his vision on how thing should be done, and developers are not an exception and from some discussion around some of them are very "hot" in comments this later times (Hoping this is a decent sentence, feel free to improve my English )

Regards

Carlo D.