what-about-design: rework conclusion

Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
This commit is contained in:
Maxime “pep” Buquet 2020-07-20 16:20:07 +02:00
parent 0a2e86c874
commit e1f3ebb099
Signed by: pep
GPG key ID: DEDA74AEECA9D0F2

View file

@ -102,11 +102,11 @@ is, and how the experience for it should be, i.e., design. This process should
be applied across a set of implementations, using the same design guidelines and
ensuring interoperability.
In practice it is not enough if somebody using [Conversations] on mobile talks
to somebody else using [Dino] on desktop, even if they both follow the
Compliance Suites of year X and can then interop on a “basic” level (still
pretty advanced to be honest), they have different design guidelines and there
will inevitably be areas where they differ and some features won't behave as
It is not enough if somebody using [Conversations] on mobile talks to somebody
else using [Dino] on desktop, even if they both follow the Compliance Suites
of year X and can then interop on a “basic” level, which to be honest, is
still pretty advanced, they have different design guidelines and there will
inevitably be areas where they differ and some features won't behave as
expected on the other side. The issue is not that there is no design
guidelines, it's that they're not the same.
@ -115,7 +115,7 @@ guidelines, it's that they're not the same.
[CS-2020]: https://xmpp.org/extensions/xep-0423.html
# What now?
# And in practice?
Multiple solutions following this design process already exist, such as
[Xabber] and [Tigase]. [Snikket] is a new addition in this domain. You can
@ -128,12 +128,11 @@ its goal: to provide a server and a (set of) client(s) that interoperate
properly and have common design guidelines that match the expected userbase.
Maybe you're not part of Snikket's target, in which case there might someday
be a similar solution that's more adapted to your use-case.
For the more technical of us who understand the protocol and/or can deal with
less unified designs, it may be ok to continue using our current applications
and work around these issues ourselves. For the mass audiences I believe this
is not an option.
be a similar solution that's more adapted to your use-case. For the more
technical of us who understand the protocol and/or can deal with less unified
designs, it may be ok to continue using our current applications and work
around these issues ourselves. For the mass audiences I believe this is not an
option.
[Conversations]: https://conversations.im
[Dino]: https://dino.im
@ -150,9 +149,10 @@ To the question I set to answer at the beginning I say this: Why does it
matter? For whom? My goal is to bring standardization, decentralization, and
extensibility to mass audiences. Not to bring XMPP to them. As explained above
I believe we need product suites with common design guidelines, and they
should include these properties. The protocol by itself is not enough.
should include these properties. XMPP has good building blocks but lacks
consorted design.
I want decentralization and standardization to prevent users from being locked
in closed -- often also proprietary -- silos such as WhatsApp, Hangouts,
Slack, MS Teams, or even Signal. And I want extensibility to prevent being
stuck in the past and adapt to the people's needs.
Slack, MS Teams, Tik-Tok, or even Signal. And I want extensibility to prevent being
stuck in the past and to adapt to the people's needs.