Re: [eclipse-pmc] Modernizing UI vs "breaking changes"

[Lars Vogel <lars.vogel@xxxxxxxxxxx>]

HI Mickael,

Thank you for your suggestion. We will discuss this in one of our next
PMC meetings.

My personal opinions are:

- Eclipse UI / UX should be constantly tried to improve
- Some changes may result is a worse experience and may be reverted at
a later stage
- L&F was never and will never be API, otherwise we could never be
able to change it
- We should follow modern and popular tools like VsCode (as these
tools most likely have a larger UX team than we have)
- Simplification of the UI is a desired goal
- Removing redundant / almost redundant UI options or functionality is
a desired goal
- Only the latest version of a competitor or a framework must be taken
into account
- I would be easier to change UI / UX defaults if we would have a way
for the user to get notified about them and a way to inform the user
how to change such things back
- If the committer group disagrees with a L&F change, any committer
can bring this to the PMC to decide

Thanks again for your initiative. I have a lot of personal suggestions
/ opinions to improve the UI / UX but due to the resistance of
changing anything in the UI in the past I'm holding them back, as I
currently do not have the time to fight such fights.

Best regards, Lars






On Wed, Jun 1, 2022 at 5:27 PM Mickael Istria <mistria@xxxxxxxxxx> wrote:
>
> Hi PMC,
>
> Lately, a few discussions have happened with proposals to "modernize" SWT and Eclipse UI. And this is a challenge to properly handle such proposals in our community. A challenge that IMO would be easier to handle if PMC can provide a set of rules about how UI changes are allowed or not.
>
> We've seen 2 discussions lately that emphasize that there are basically 2 opposite postures in the community: a group of "let's modernize" and another of "let's stick to ...".
>
> First one is about the Workbench Layout: discussion about whether to keep menu bar, moving some bars someplace else, and a lot of proposals regarding the pure layout (no API change). Some discussion has happened and some technical discussions did take place, some of them led to potential compromises. But we've read a few cases where people are mostly afraid of disruption and more or less rejecting a whole change without clear rationale beyond "I don't like it".
> Another one is about the default CTabFolder in SWT. For some technical context, this custom part of SWT is pure SWT, not native, and -unlike native parts that are delegated to the OS/Platform- SWT is responsible of the Look and Feel for those custom elements. The proposal was to improve look'and'feel for this by mimicking common patterns used in other applications, and even already used in Eclipse Dark Theme (with million of users, and 0 complaints about those patterns so far). This change was not welcome as being too disruptive, not mimicking old versions of GTK or just "not liked".
> It's worth noting that in both cases mentioned above, the proposals go in the direction of the current market trend: they are mimicking competitors like VSCode, Theia, IntelliJ; or related frameworks like GTK/Adwaita, Vue.js...
>
> While we should value discussions and diversity and I think we proudly do it every day, I'm afraid that these debates are almost always sterile and really discouraging, and even very irritating, for some people. The frustrating part about these discussions is that they usually miss an objective way to deal with those: there is no clear data of what's best in UI, it's open to interpretation and opinion. Those discussions with a lot of subjectivity can easily become ego fights, improductive, sterile, tiring, discouraging, toxic... But this is not really an individual behavior problem of our community; I do believe they're the natural result of trying to have people agreeing on something that seems too subjective.
> And we need a way to handle those better to sanitize the community; in order to clearly allow to make progress -or not- without exhausting contributors. I think the PMC needs to provide some rules to take UI decisions "systematically", removing some subjectivity and leaving less room to "bad" debate and allowing to focus on actual technical parts.
>
>
> I'll dare to suggest a few rules that the PMC could enforce for discussion when it comes to Look and Feel:
> * Usual API contracts and technical and functionality quality sustainability rules apply: a UI change shouldn't be the cause of a bug to adopters
> * The UI layout of non-natve parts is *not* an API contract and is designed as best for the current time. The Eclipse Platform can change the layout of the workbench, dialogs or custom widgets as it is decided is best by its committers without taking into account the risk of breaking clients relying on former layout. The fact that layout change towards something that seems better is the natural form of innovation, and should be desired by consumers. Consumers have acknowledged they use the Platform as a moveable UI that will constantly move towards the current direction of progress and will adopt the layout that's recommded by Platform, or hardcode their own one.
> * Only the latest version of a competitor or a framework must be taken into account when deciding of a strategy to mimic. Older versions of those competitors/frameworks cannot be considered as a reference when it comes to improving Eclipse Platform look and feel (as comparing with older references will obviously cause Eclipse Platform to lag behind the state of art).
> * UI improvements do not have to mimic existing competitors and frameworks if there is some agreement between committers that what is proposed in Eclipse Platform is better for it.
> * Look and Feel modernization must be understood by committers as a continuous and infinite, never complete process. As such, it's important to judge the changes individually: "are they an improvement over the current state?" if yes, let's adopt it, if not, let's discuss. Looking up for a perfect solution on every UI change should be avoided as much as possible, as discussions about perfection are endless and by nature not resolvable (perfection is moveable and subjective, it cannot be a common goal). Iterative approaches to UI improvements are more welcome; also because they allow to manipulate the proposals and better identify in real usage what are the main issues that need to be fixed or the best opportunities to improve, or just to decide that after all, it's good enough as it.
>
> Does this sound fair?
> --
> Mickael Istria
> Eclipse IDE developer, for Red Hat Developers
> _______________________________________________
> eclipse-pmc mailing list
> eclipse-pmc@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-pmc



-- 
Eclipse Platform project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com