Complete UI/UX split from platform

[sssilver]

Posting as a newcomer. I'm a software engineer who uses both Monal and Siskin.im.

Implementing an XMPP messenger on iOS is an extremely heavy lift. And none of the existing XMPP clients on iOS (including Monal) have exceptional UI/UX.

The problem with great UI is that it's generally extremely subjective, and everyone has either an opinion or a preference. This doesn't mix well with open-source community-driven projects, because they're either developed through consensus and UI is hard to reach consensus on, or decisions are made by a benevolent dictator who either doesn't wanna alienate developers that volunteer their energy to the project, or just dictates bad decisions on a subjective, non-technical matter.

One way open-source projects have traditionally found to try and circumvent this issue is by making UI extremely customizable, so that every contributor and user can tailor it to their liking. This causes customization bloat, which in itself is bad UX.

I'm here to discuss a radical alternative. Here's what I propose.

If Monal genuinely wants to support XMPP adoption and experience on iOS, it should focus very heavily on splitting itself into 2 projects:

1. the "engine" of XMPP messaging; literally everything that does not include UI. This includes all authentication and authorization, all encryption, push notifications, stream management, etc. This project should be a Swift package and be effortlessly embeddable into any Xcode Swift project, including ....
2. ...the "UI" of Monal, a project that uses the package above and contains only things like screens, text boxes, images, emojis, and buttons. This project would focus on implementing things like pasting an image into the chat textbox (currently unsupported), proper client-side search, beautiful login and signup experience, etc

Most importantly (and strategically) this would allow developers who maybe do not have the energy or whatever it takes to implement a whole XMPP messenger but have a fantastic UI/UX idea to effortlessly implement it in Swift, standing on the shoulders of the giants who shipped project 1. And if project 2 is the best UI to use for XMPP on iOS, well so be it -- that's fantastic!

Let a thousand XMPP clients bloom, powered by the Monal engine.

It's possible this is already very close to reality, and the engine just needs to be published as a Swift package, otherwise codebase-wise it's already completely and entirely divorced even on filesystem, project, and workspace level.

It's also possible (albeit unlikely) that there's already a Swift package for the engine and I've jumped the gun by posting this message instead of doing my homework more thoroughly. If this is the case, I apologize profusely.

What are your thoughts on this?

Much appreciated.

[ogwillow]

I think this is an incredibly great idea. +1

[TiBooX]

and the idea is older than the NeXT Step client/server distinction. (NeXT Step eventually became OS X and now macOS, iOS, watchOS, ...)
macOS ist exactly meant that way. See Darwin/UI separation.
It's actually how OOP/OOD can work/should work.

[FriedrichAltheide]

Thank you for opening the discussion. We have discussed this internally in the past.
Here are some of our thoughts on some of your arguments/topics separating Monal's XMPP framework from the UI.

More XMPP clients on iOS == better?
There are already Siskin and Monal, which are maintained, and several other unmaintained clients. The maintained ones already lack developers (hint: Monal needs more developers). More clients or even forks of existing iOS clients will not solve the lack of upstream developers. Furthermore, some of the unmaintained clients are still being promoted by other XMPP users even though they do not support proper push messages, are abandoned, or are forks of other applications without proper backporting of upstream changes/fixes.

--> There is no need for more XMPP clients on iOS. For anyone considering forking an existing XMPP client or developing a new one: Stop, and instead help work on one of the existing upstream projects.

One UI, multiple opinions
If you ask a bunch of developers/designers, there will be little overlap on how the UI should be designed/used. If you ask users, they will probably say that the UI of application x, y is good, and ask why an XMPP application cannot be designed in a similar way.

Side note: Designing a chat app like any other chat app might be a pretty good idea for accessibility (especially in terms of voice-over).

Speaking for the Monal developers: We are currently reworking the UI. So, if you have any input, feel free to speak up. Now is the time. We are an open source project and contributions are very welcome.

“Let a thousand XMPP clients bloom”
Theoretically, it would be possible to separate the UI from the XMPP framework of Monal, but who will maintain the framework, and more importantly, who will pay for it? We are aware of several private forks of Monal, so far none of the private fork developers have upstreamed any commits. We are also not aware of any donations from any of these private forks. Therefore, we are not interested in helping more non-contributing developers make money from Monal without giving anything back.
--> Separating the framework from the UI will only cost us time, without much benefit to Monal itself.

Rewriting the UI
We have already started to rewrite the UI. We will focus on the maintainability of Monal (please note that we will also try to improve the accessibility and help is always welcome).
--> We are separating the UI from the XMPP stuff if it helps us maintain Monal in the long run.

Conclusion
Considering the above, we do not think it is our job to separate the XMPP code from the UI. If you want to separate Monal's XMPP implementation into its own framework, we will not stop you. In fact, we will be happy to merge any incoming PRs that separate these parts.

Friedrich, Thilo

[sssilver]

Thanks for the thoughtful response.

If you want to separate Monal's XMPP implementation into its own framework, we will not stop you. In fact, we will be happy to merge any incoming PRs that separate these parts.

This had to be stated and it is fantastic that you stated it.

Let's imagine this is done.

How would you feel if, after that split happened, someone made an app that used the Monal platform to make an incredibly snappy, usable, accessible, robust, and beautiful UI, and most people preferred it over Monal's next UI incarnation?

Would it hurt?

Would it be more appropriate from your perspective that this UI/work was offered to the Monal project first, since you stated Monal is in need of contributors?

But you said you already have the next UI incarnation in progress. So there's already a vision. What if this UI was against that vision?

At that point would you say the proper way to do this is to offer the UI to Monal, and only pursue it as a separate project if it isn't accepted by the maintainers?

What if the maintainers request changes that the original designer/developer of this new UI vehemently disagrees with?

And what would happen if they went to chase their own vision and it turned out that more users were willing to pay ten bucks for this different UI than to use the Monal UI for free.

For all intents and purposes at that point they'd be financially benefitting from your Herculean work of having built all the non UI parts. It's human that this would sting.

These are semi-rhetorical questions but I think it's important that they're contemplated.

[tmolitor-stud-tu]

There is a simple answer to most of your questions: If no one uses Monal anymore or if we don't get enough donations to keep the push servers running, we will stop working on Monal and Monal will cease to exist. Period.

For all other questions, it very much depends on the individual case. And unlike to you I don't see much value in spending my time answering these (or even more) hypothetical questions instead of working on Monal's code or reviewing actual contributions.

I've never had a case of contributors fundamentally disagreeing with me about the UI. @CCordeeate and @lissine0 both contributed some code/ui and both know that I'm very open to good arguments and my visions of current and future UI designs have never been set in stone and will never be.

[lissine0]

We are aware of several private forks of Monal, so far none of the private fork developers have upstreamed any commits. We are also not aware of any donations from any of these private forks. Therefore, we are not interested in helping more non-contributing developers make money from Monal without giving anything back.

What do you think about re-licensing to a copyleft license like GPL? the forks will at least have to share their modifications.
The reason why the README says ** NO GPL ** is because the previous maintainer was afraid of the app being pulled from Apple's App store #166 (comment)

Generally speaking I have a strict no GPL rule. Because you can't have GPL apps in the App Store (https://arstechnica.com/gadgets/2011/01/vlc-for-ios-vanishes-2-months-after-eruption-of-gpl-dispute/).

But the incidents above are all related to GPLv2 https://opensource.stackexchange.com/questions/9500/is-apple-allowed-to-distribute-gplv3-licensed-software-through-its-ios-app-store

Besides, there are GPL apps which have been on the App store for years e.g. https://github.com/tigase/siskin-im/ and https://github.com/signalapp/Signal-iOS (AGPL)

And there are weaker copyleft licenses like MPL 2.0 or CDDL or EPL

What do you think?
Or do you reckon re-licensing would too much of a hassle?

[tmolitor-stud-tu]

Relicensing would in theory need every contributor to give their okay to this (at least if their contribution is still in the code and if it wasn't something small like a typo fix).

Someone will have to go through the complete github history of about 14 years and check every contribution if it meets the above criteria, then compile a list of contributors that have to be asked.

If someone wants to do this, I'm all in favor of GPL2 or even GPL3 :)