I don't really "get" all this, yet


#1

Criticisms so-far

  • javascript not optional: I don’t want a GUI forced upon me.
  • moderately usable. What am I supposed to “do” with this?
  • confirmation mail wants me to “click” on something (I can’t just answer).
    I get the suspicion that mail is a second-class citizen here.

#2

Why so negative today? (replying to test mail interface)


#3

OK, trying to reply via mail:

Criticisms so-far

  • javascript not optional: I don’t want a GUI forced upon me.

I see.

  • moderately usable. What am I supposed to “do” with this?

What do you mean by that?

  • confirmation mail wants me to “click” on something (I can’t just answer).
    I get the suspicion that mail is a second-class citizen here.

Yeah. Mail is soooo old.


Visit Topic or reply to this email to respond.

I’d say: the other way around, no? Or are you trying to nudge me
into the web page?

You are receiving this because you enabled mailing list mode.

Yes, I did. To be honest, I’d love to have a mail-only mode.

Cheers
– tomás


#4

Trying to reply by mail.

Is it possible to create new threads by mail?


#5

Aha. Answering to the answer (via mail): the mails get the threading
right (References: and Reply-To: – good).

Latencies are a bit… long. And then are those @#*&%$ notifications,
which kick my javascript-infested browser into “grab all focus” mode
(one of many reasons I try to minimize the instances that
abomination is running in my computer, BTW).

At least I can disable that in the browser. Phew.

No, I think that kind of thing is too new a trick to teach this
old dog.

– t


#6

I wish I knew. I really wish.

Cheers
– tomás


#7

May I please ask you to not suspect the volunteers behind this service to abolish email altogether? We’re experimenting with this to find out whether Discourse can unite the mail geeks (yes, I’m one of them) and the ones who don’t like mailing lists.

javascript not optional: I don’t want a GUI forced upon me.

Understood, but that’s unfortunately how Discourse works. However, there are two things which make is less bad: 1. it’s only local javascript, served by us, 2. it’s probably well accessible with screen readers.

moderately usable. What am I supposed to “do” with this?

What are you supposed to do with mailing lists? Communicate, build inter-human relationships, have fun, and ignore if you wish.

confirmation mail wants me to “click” on something (I can’t just answer). I get the suspicion that mail is a second-class citizen here.

My personal priority is to explore the possibilities how to use Discourse like a mail list as much as possible. However, I’m afraid that at least a few web interactions are required, just as how 90% of Mailman users are “forced” to use the interface unless they know complicated mailman commands (which I still don’t know).


#8

I’ll see whether this template can be changed.


#9

There is the possibility in theory. I will try a few configurations soon.

Again: Please remember that this is an experiment. We’re not replacing anything soon, just exploring the advantages Discourse might have or haven’t.


#10

There is the possibility in theory. I will try a few configurations
soon.

Nice to hear that :slight_smile:

Again: Please remember that this is an experiment. We’re not
replacing anything soon, just exploring the advantages Discourse
might have or haven’t.

Which is what we did yesterday evening at the meetup :wink: More or less unprepared about what to expect.


#11

[…]

There is the possibility in theory. I will try a few configurations soon.

I see further downthread you did it.

Again: Please remember that this is an experiment. We’re not replacing anything soon, just exploring the advantages Discourse might have or haven’t.

Yep. Nevermind my panic squeaks from yesterday: a more
even-headed answer is coming later :slight_smile:

Cheers
– tomás


#12

May I please ask you to not suspect the volunteers behind this service to abolish email altogether? We’re experimenting with this to find out whether Discourse can unite the mail geeks (yes, I’m one of them) and the ones who don’t like mailing lists.

I don’t, mind you. At least not consciously/on purpose.

javascript not optional: I don’t want a GUI forced upon me.

Understood, but that’s unfortunately how Discourse works. However, there are two things which make is less bad: 1. it’s only local javascript, served by us, 2. it’s probably well accessible with screen readers.

My beef with Javascript is typically another: whereas with plain
HTML (and perhaps some CSS) the browser behaves as it usually
does, every javascript application behaves in a randomly different
way – the way the designer has thought is “good for me”. And
if I want to take part in the platform, I gotta swallow the app.

To me that is the opposite of software freedom :slight_smile:

moderately usable. What am I supposed to “do” with this?

What are you supposed to do with mailing lists? Communicate, build inter-human relationships, have fun, and ignore if you wish.

My question was rather directed to a (for me) pretty impenetrable
user interface.

confirmation mail wants me to “click” on something (I can’t just answer). I get the suspicion that mail is a second-class citizen here.

My personal priority is to explore the possibilities how to use Discourse like a mail list as much as possible. However, I’m afraid that at least a few web interactions are required, just as how 90% of Mailman users are “forced” to use the interface unless they know complicated mailman commands (which I still don’t know).

Mailman’s grandma had a mail interface. You could send “help”
to it for a list of commands. So it is possible…

As I said, a more complete (and even-headed) assessment is
coming…

Cheers
– tomás


#13

Hi,

somewhere in this thread I promised to write a more even-headed
evaluation of discourse. Note that this is a very personal
evaluation, and I don’t expect anyone to agree with me.

  • Free client choice

First of all, I grew up with email. This construction is very
old, and while it has developed innumerable warts, but it presents
nevertheless a set of properties which are very dear to me:

  • a protocol with a stable specification which is independent
    of the technical implementation of its clients and servers
  • a multitude of clients (Mail User Agents) with very different
    user interaction models from which I, as a user can choose
    from
  • likewise a multitude of servers which nevertheless interoperate
    with each others
  • resulting from this, a decentralised infrastructure, in which
    each participant can communicate with each other participant.

Of course, being such an old thing, it has accreted a huge pile
of hacks and warts, and there have been many things which have
crippled its “perfect” function. Spam comes to mind, and some
of the anti-spam measures, mainly pushed by the Big Ones (every
person maintaining her own SMTP server will sing the praises
of SPF, DKIM and DMARC), but we have survived, mostly.

Compared to that, what have those app silos to offer? A full
vertical integration of server and client – you can only take
part if you accept the client as offered. That’s why I call
them “silos”, in analogy to the other silos out there. While
the analogy seems unfair, I think there’s more to it than
just a fortuituous resemblance.

The absence of a protocol, and the tight coupling between
server (platform) and client (they are developed in parallel,
so there’s nearly zero cost in changing the protocol: this
is reflected by the javascript’s URLs, which carry an UUID
to make sure server and client versions match!) makes it
nigh impossible to develop an alternative client.

I want to be able to choose the software I use: this is part
of software freedom, and this is why I’m in this, after all.

  • User behaviour “engineering”

The “Big Ones” have, long ago, discovered nudging (well,
the concept is as old as ad industry, but the Big Ones
grew to their current size fueled by ad industry, so it
is no wonder that nudging is in their genes). Silos,
therefore, are very much into “nudging users into ‘right’
behaviour”, where ‘right’ is defined by the silo’s owner’s
interest.

“Ah, but” I hear you say – “discourse is different: it
is free software, after all”. Yes, and this is a Good Thing.
But nevertheless: on the one hand, user expectations are
heavily shaped by the other silos; on the other hand, most
developers shaping the free applications have day jobs
at silo companies, and on the third hand, the frameworks
in use are heavily sponsored by silo companies (of relevance
in our current case, the UI library Discourse uses, ember.js
is sponsored by Yahoo!, LinkedIn, Addepar and Bustle. While
not my enemies, they definitely aren’t my friends either.

To sum up, I think that, by extension, even free software
is showing a worrying trend in user nudging. I think this
is bound to be the next big battlefield of software freedom.
To put it in the words of Brett Frischmann, whose writing
is much more compelling than mine

"Social engineers armed with oceans of behavioral
data see predictably irrational humans as subjects
to nudge toward rationality and smart tech as an
efficient tool for nudging. They fail, however, to
appreciate that a smart-tech world of perfect
rationality is a dystopian nightmare wherein humans
are reduced to automatons—perhaps “happy” automatons,
which is hardly consolation." [1]
  • UI-driven “disconnect”

“Ah, but” I hear you say now – “luckily discourse can be (for the
most part, at least) interacted with via email”. Yes, and this is
a Very Good Thing. I’m making use of it right now. I see some
difficulties ahead, though, and I am moderately pessimistic on
whether those difficulties can be tackled: a Communication Gap,
and the Temptation of the Feature.

** The Communication Gap

Discourse’s primary UI is the Web “GUI”. Its users are seeing
a mixture of the message carried by the GUI (which is in itself
a mixture of the framework’s message and the message from the
web designer), and the “content”. When talking about what one
“sees”, there’s going to be a gap between the Web UI user and
the mail user. We will see whether this gap becomes relevant
in the communication or not. As far as personal experience
goes, I had to navigate this gap in my former company between
users of Outlook and myself, a user of Mutt.

** The Temptation of the Feature

Discourse developers, as any designers will be strongly tempted
to “enhance” the product with features which may be difficult
to map to the mail interface: this is easy, since they’ve got
client, protocol and server in their hands (or in their repos,
as the case may be). Difficult means, most of the time in this
fast-paced world, simply never…

  • Being a Luddite

You might feel the temptation to call me a luddite, and you’d
be right: I am playing the role of one, in this context. I am
convinced that, at some points in life we need that role, and
I am convinced that this is one. To defer again to Brett Frischmann,
whose writing is definitely more enjoyable than mine

"I was recently called a Luddite. It was meant to be
an insult, to suggest that I was an anti-technology
zealot. I resisted the temptation to defend my pro-tech
cred and instead explained the importance of Luddites
as a counterbalance to smart-tech utopianism." [2]
  • Closing

No, it hasn’t been a very positive review. I’m sorry for this.
But this kind of software just touches a very deep nerve in me,
one which runs parallel to my free software nerve. I hope I’ve
managed to explain why.

Cheers

[1] https://blogs.scientificamerican.com/observations/algorithm-and-blues-the-tyranny-of-the-coming-smart-tech-utopia/
[2] https://blogs.scientificamerican.com/observations/theres-nothing-wrong-with-being-a-luddite/

– tomás