what-about-design: rework conclusion
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
This commit is contained in:
parent
0a2e86c874
commit
e1f3ebb099
1 changed files with 15 additions and 15 deletions
|
@ -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.
|
||||
|
|
Loading…
Reference in a new issue