Máirín,
On 2018-10-19 14:43, Máirín Duffy wrote:
I'm open to all of those suggestions as well as committing to design
and CSS work for them. I would need a web dev to help me though; I'm
not great with Django.
Please note, the reason Hyperkitty didn't cause this sort of thread or
honestly any sort of drama or controversy when it was deployed is
because it required no current users to change anything about their
workflow, with one small exception - mm3 didn't come out w topic
support which was used on the packagers list. (I don't believe that's
an issue anymore.)
The whole point of the design was to enable a new group of would be
contributors be able to participate alongside the folks already there,
so that everyone could participate together. Existing ML users never
need to use Hyperkitty if they don't want to, and yet, users new to
the project can start reading and participating in threads right away
w no mail client config and never receiving a single email if they so
desire.
I believe quite strongly (and have from the start when I first heard
of the project) that Discourse's basic UX model is fundamentally
flawed. If we deploy discourse and roll it out, we *may* get new
users, but as noted in this thread, we will lose existing ones.
Participating in upstream effort on Discourse, improving it, etc is
foolish bc the fundamental model is broken.
When some people think of email, they think of mutt or thunderbird,
annoying client config, setting up procmail or fetchmail or whatever
other complex elaborate tools many of the ppl reading this use. Email
is just a basic standard. Discourse does not follow that standard.
There is no reason a social media timeline like experience for the
teenagers is not possible using email as the underlying system. Jabber
never really took off, except Google Hangouts and FB messenger both
used it (no idea if they still do.) The reason our open standards like
email and xmpp are dying off is bc the primary biz model of the
companies that used them relies on getting eyes on ads, and scanning
content in ways that mean giving users a choice of client that works
best for their needs is off the table.
Basically dont confuse the front end youre used to with the underlying
tech.
I think it's a better idea to use a tool based on open standards, that
allows users to use the client experience that works best for them. If
you try to force everyone down one road it won't work.
A nice, informed response!
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: p...@pricom.com.au
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
