Usability matters. It's easier to tell people to open a browser window and point them at a URL than tell them to download an IRC chat client and how to connect to the server and... On Wed, Dec 7, 2016 at 5:41 PM William Yager wrote:

What are the advantages of this over the #haskell IRC on freenode? It's very active, usually with over 1500 nicks at any given time.

I generally prefer IRC to any of these hip web chat solutions because IRC is client-agnostic and very rugged against companies folding or deciding they don't want to host a project any more. Basically the only way to kill an IRC channel is through social attrition, whereas any social value built up in hosted chat services might disappear overnight.

The one major advantage of hosted chats over IRC is that they work better with mobile users, but I don't think that's very relevant for haskell dev.

Will

On Wed, Dec 7, 2016 at 7:34 AM, Ben Spencer wrote:

Why Gitter you might ask?

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

It's easier to tell people to open a browser window and point them at a URL

You could always point someone to https://webchat.freenode.net/ or any other web based IRC client. On Wed, Dec 7, 2016 at 11:51 AM, Christopher Allen wrote:

For that, there's http://fpchat.com/ which is an established Slack community. The #haskell channel alone has 1,208 people in it right now.

On Wed, Dec 7, 2016 at 10:50 AM, Tomas Carnecky wrote:

...

Usability matters. It's easier to tell people to open a browser window and point them at a URL than tell them to download an IRC chat client and how to connect to the server and...

On Wed, Dec 7, 2016 at 5:41 PM William Yager wrote:

...

What are the advantages of this over the #haskell IRC on freenode? It's very active, usually with over 1500 nicks at any given time.

I generally prefer IRC to any of these hip web chat solutions because

IRC

...

is client-agnostic and very rugged against companies folding or deciding they don't want to host a project any more. Basically the only way to kill an IRC channel is through social attrition, whereas any social value built up in hosted chat services might disappear overnight.

The one major advantage of hosted chats over IRC is that they work better with mobile users, but I don't think that's very relevant for haskell dev.

Will

On Wed, Dec 7, 2016 at 7:34 AM, Ben Spencer

...

wrote:

...

Why Gitter you might ask?

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Tomas Carnecky writes:

Usability matters. It's easier to tell people to open a browser window and point them at a URL than tell them to download an IRC chat client and how to connect to the server and...

As someone relying on Accessibility on a daily basis, I notice that this myth does not apply to me. As a blind user, working with a browser-based chat system is definitely less accessible then a native local client solution using something established and well-tested like IRC. Actually, I am afraid most of you have absolutely no idea how bad web accessibility has become in the modern days of realtime web-based applications. The digital divide is about to hit really hard with the next wave of new technology hype. HTML + JavaScript was never designed to be an application development platform, and forcing it to be one does not make the job for assistive technology providers easier, in fact, it makes it virtually impossible.

On Wed, Dec 7, 2016 at 5:41 PM William Yager wrote:

...

What are the advantages of this over the #haskell IRC on freenode? It's very active, usually with over 1500 nicks at any given time.

I generally prefer IRC to any of these hip web chat solutions because IRC is client-agnostic and very rugged against companies folding or deciding they don't want to host a project any more. Basically the only way to kill an IRC channel is through social attrition, whereas any social value built up in hosted chat services might disappear overnight.

The one major advantage of hosted chats over IRC is that they work better with mobile users, but I don't think that's very relevant for haskell dev.

Will

On Wed, Dec 7, 2016 at 7:34 AM, Ben Spencer wrote:

Why Gitter you might ask?

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- CYa, ⡍⠁⠗⠊⠕ | Blog: https://blind.guru/ GitHub: https://github.com/mlang/ .''`. | Twitter: @blindbird23 FaceBook: disyled : :' : | SoundCloud: `. `' | YouTube: `-

On 2016-12-12 19:38, Joachim Durchholz wrote:

Am 12.12.2016 um 19:27 schrieb Mario Lang:

...

The digital divide is about to hit really hard with the next wave of new technology hype. HTML + JavaScript was never designed to be an application development platform, and forcing it to be one does not make the job for assistive technology providers easier, in fact, it makes it virtually impossible.

That's one of the things I have been disliking about how the W3C has been pushing Javascript instead of simply extending the set of standard controls. What's also missing is UI design guidelines such as those that have been established for Mac, Windows, and Linux. Most webapps have a horrid user experience even for me, who is neither blind nor colorblind nor mouse-precision-impaired, i.e. usability is bad even for mainstream users.

Of course we are part of the problem. The general approach when it comes to Haskell on the web seems to be to throw some react and some ghcjs and some jquery and some god-knows-what together, and be done with it so you can get back to Haskell. I get that people want to stay in Haskell land, and these technologies are not bad per se, but we might have set the wrong incentives so that we rely on them too much. Most of the frameworks we have are absolutely not UI- or accessibility-oriented. If someone wants to create a static site with five pages, and it feels easier to rely on ghcjs+react with all its setup, have the user add three security exceptions, and then still crash the browser than it is to create five static pages, then we failed. Or rather, some parts of our community were too successful. It's kind of funny how many of us use Haskell because we'd rather think ten minutes than debug for twenty, but when it comes to web stuff many of us still throw careful consideration overboard. It's probably because the whole web dev world is a bit bonkers. But if any community has the right people to add a voice of reason, I'd still think ours might be a strong candidate. Naturally it's not a really loud voice, but then we do have some great server libraries as a selling point. Cheers, MarLinn

On 13/12/16 7:27 AM, Mario Lang wrote:

Actually, I am afraid most of you have absolutely no idea how bad web accessibility has become in the modern days of realtime web-based applications. The digital divide is about to hit really hard with the next wave of new technology hype. HTML + JavaScript was never designed to be an application development platform, and forcing it to be one does not make the job for assistive technology providers easier, in fact, it makes it virtually impossible.

A few years ago when our departmental web-site was being redesigned I had some usability concerns and went to the local Blind Institute to ask their advice. I have forgotten their exact words, but the gist will stay with me for a long time: * It's no harder to make an accessible site than an inaccessible site. * You just have to seriously WANT to. (Our site doesn't use the design I was concerned about any more.)