Topic on Talk:Flow Portal/Archive2

I have a couple of accessibility concerns.

First: Users, for myriad reasons, such as ancient hardware or non first-world connections, often disable JavaScript. (Looking at the discussion at en:Wikipedia_talk:Notifications/New_message_indicator#The_bigger_issue_here:_Javascript, I can count at least six frequent editors whom this will affect.) I can say that, while this page is not impossible to use with JavaScript disabled, it is nearly unreadable. Every section displays as one undifferentiated blob of text. Nevermind, this is LiquidThreads, not Flow.

Furthermore, I worry about blind users with screen readers; from what I've seen, they have had challenges using some of the recently rolled-out changes, and it would be depressing if Flow didn't work properly for them.

Lastly, I worry that this will affect users with slow connections. Wikipedia is used throughout the world, but it is my understanding that broadband connections are only generally available in non-rural parts of North America, Europe, and Asia.

By "this page" do you mean this talk page, Talk:Flow Portal? This page is using Extension:LiquidThreads, not Flow. (I don't think a deployable version of Flow exists yet.) Your concerns are good ones, though – I too worry about how usable Flow will be without JS.

I had some fun a while back putting together CSS to make LiquidThreads look nice without the use of JavaScript; see w:User:PartTimeGnome/lqt.css. The format is of my own design – it doesn't look anything like the format you get with JavaScript enabled. This is only for people who keep JavaScript disabled; if JS is enabled my formatting will conflict with the normal formatting added by JavaScript and look thoroughly wrong.

Standard disclaimer: I've only tested this CSS in single browser; it might not work for you. I'm pretty sure some bits will look different in Internet Explorer, though I hope the appearance would still be better than it would be without it.

I tried out that CSS; it looks great! ( Using en:Iceweasel under en:Debian, if you're curious.) Suddenly, I can read everything without straining! :D

Hi everyone, I have some questions :)

1. will there be a fallback skin for users who do not have Javascript enabled? I know a lot of them who complained about new features because they are more and more depending on scripts - and I loved Wikipedia for the utmost waiver of Javascript.
2. I did not understand the project pages exactly - is there the possibility to subscribe only a user's board without receiving his contributions on other pages? I just want to follow the activities on his board (= talk page) just as watching it at present.
3. A big problem will be the rights management. I'm sure there will be massive protest because users can not edit posts of other users. It is possible that an user only wants to do a spelling correction in another post, or an user wants to remove a personal attack. Also, there is a problem with "work lists" started in discussions, for example if somebody wants to mark a task another one started as done.

Please excuse my English :)

1) There will almost certainly be a fallback (though it probably won't be a skin - in mediawiki parlance, a "skin" is a very specific kind of thing). I cannot promise that the experience of interacting with the system will not be painful if you don't have javascript enabled - and it may very well be that you will not be able to edit or add comments without it (given our dependance on the VisualEditor). However, the best effort will be made.

2) That is the "minimal" case for subscribing to a user, perhaps. If we look at the maximal case of subscribing to a user, the following things could be important:

1. New topics started on their board
2. New topics that they start on other boards
3. Topics they respond to in other boards
4. Edits they make to articles
5. Workflow discussions they start or get involved in (AFD, RFA, etc.)

As we go forward, we'll probably have to create a system whereby you, as a user, can have more fine-grained control over your subscriptions like this.

3) Rights management is an on-going discussion. We knew that restricting comment edit would be a Thing. But there are several routes to achieving solutions that are acceptable to the use cases we've identified.

One thing I can tell you is that we are planning for the idea of a "collaborative" post flag, which would allow for multiple people to edit it.

That is the most terrifying thing I have heard this week. Being unable to "edit or add comments" is tantamount to being forcibly en:WP:retired. I don't want to leave the project, but that would force me to, since I'd be unable to participate in the community at large.

I hope no one minds that I merged these two threads. They seemed to belong together, but I couldn’t find any documented etiquette for merging.

Yeah. I wish I could comment more about the non-javascript comment-adding part. This is really tied up in our VisualEditor functionality (which is Javascript only). I can see a case where we allow some commenting in "standard" edit modes but with a significantly restricted list of available wikitext (this is also dependent upon the parse). Honestly, it is too early for me to make realistic predictions about this.

(As far as merging threads goes, this is MediaWiki.org. It's like the wild west up in here, and BOLDness is appreciated.)

I still don't get why your're clinging to the VisualEditor when it's clear it comes with a huge amount of compatibility problems on it's back.

Why not sticking to the "good old" Wikitext or something compatible as a base and fix the Visual Editor to support all features? Then one could always offer both: The nice-and-shiny VisualEditor for all people with JavaScript and/or a reluctance towards source code; the lightweight WikiEditor for people without JavaScript and/or a preference towards markup.

The answer, as I've said before, is that it may not be technically feasible for us to do so. Since this is a fairly large design constraint, we have to account for it in the design (and assume the worst case).

Regardless, I highly doubt that the comment editor will support any more than the most rudimentary of wikitext.

I’m not sure if I’m understanding everything right here and I must say that I’m worried that there will be no way for taking part in discussions in the future anymore, just because it shall not be "technically feasible" that every user can take part like it is up to now. If it is not feasible that every user can take part on the projects and with new features, then it is better that the new features will never get live because then they make things worse. I really don’t understand that. You wrote also that there will be a fallback, but I don’t understand how it’s supposed to be, if it could be not possible to edit talk pages anymore (if I understood that right).

Now to VisualEditor: It’s AFAIK a feature that is supposed to be added optionally to the now-being system, but not replacing it in any way. So, the standard will be wikitext like now and if you want you can enable VE. Is that right? Because I can’t imagine in any way a new feature that is only accessible with JS to replace a system like normal wikitext, as the wikitext is compatible and accessible to everyone, and the new system isn’t. I think that I will not be around anymore, if it will come to that there will be no way to edit anything anymore (because VisualEditor will surely affect every page and not only talk pages). Is it that the foundation aims to get people out that haven’t the right technology for editing or am I understanding everything wrong here? It’s really hard to understand for me what is happening here and why.

All I want is that every new feature that is being developped and that has already been developped and put live, will be and will get accessible to everyone. I don’t know why, but it seems to me that there is not enough energy or drive within the foundation or developers or whatever to put that aim forward (despite the fact that this is not a commercial company who tries to make as much as money with their products but is claims to be a non-profit which I nearly can’t even believe anymore). It is or it should be the most important thing at all for every new developped feature to be accessible and compatible to everyone in a way that doesn’t affect too much, and that it doesn’t produce new errors or problems that wouldn’t be there without it. Everything else shouldn’t be as much important as that. If it doesn’t fulfil this then it should never get implemented. Cause you shouldn’t change a running system that isn’t out of order to make it out of order for a lot of people.

I agree with everything Geitost said.

I take Jorm's "may not be technically feasible" comment to mean not technically feasible with the current design. If your design cannot meet the requirements that the current system fulfils, it is a poor design. I know it feels horrible to throw away something you've poured weeks of effort into, but it's better to start afresh on something good than to keep putting effort into a poor design. And your previous effort won't be entirely wasted – you will have learnt valuable lessons that will help make the next design better.

I speak from experience here. A few years ago, my company decided to "modernise" its flagship product. (It used 80×25 text screens and was becoming unsaleable because managers who make purchasing decisions don't like the retro look. Strangely, the people actually using the software liked it!) We spent two years working on a replacement system, which was widely disliked by customers and we found it was "not technically feasible" to make the changes they wanted. So we scrapped two years of work and started again. At the time I thought this was madness; I now think this was one of the best decisions we made. Having learnt from the previous attempt we were able to produce a much better system that can do some really cool things neither of the previous systems could ever have done.

I have no objection to you using JavaScript in ways that make life easier for some editors (like the Visual Editor will), but JavaScript should never be required for any core function. If you use JavaScript for a core function, also provide a non-JS fallback mechanism (even if it is a little clunkier to use).

Like Sophus Bie, if you make the ability to edit or participate in discussions dependent on JavaScript, you will have forcibly retired me. Though perhaps a better word would be blocked – i.e. a technical restriction preventing a user from editing.

Thanks for your answers. If the system is customizable, it it much better than a rigid one and will perhaps receive more recognition.

I think there are some really good approaches in this new software. For newer editors there are some nice new features like the "Welcome" mode. But I am sure that there will be massive discussions about the things Geitost mentioned above. I can imagine, and that's partially also my optinion, that users will refuse the new system because it is to "Facebook-like".

For minor fixes in articles, I can imagine using the VisualEditor, but I can't imagine writing long articles with this tool. Sometimes, I want to save a written text offline for finishing it later, and sometimes I do the same with discussion posts. The VE will probably not support that. And there are some other points mentioned in the discussions already, so please keep normal wikitext for everyone. Editors who ever used wikitext will be faster and better in using it instead of the VE. I can understand your technical concerns, I know how difficult backward compatibility can be. But wikitext is a feature that is essential for Wikipedia, you will offend everyone if you are removing it.

Regards,

I agree, wikitext in discussions is a feature, not a bug.

Agreed. See the recently-updated FAQ for where we're at currently: Flow Portal/FAQ#Will Flow support wikitext or the VisualEditor? Note that the default on the prototype is wikitext, but if you create an account there, there is the option to use VisualEditor instead.

I would say... If you cannot enable making new comments or make it so painful to use discussions without JS that everyone without that leaves, you must not implement Flow. It would seriously harm Wikipedia. I strongly advise you to make the development of a non-JS version that enables discussing the highest priority in the Flow project. If you cannot, you must stop development of Flow. If you cannot, and try to implement the expansion, the Board will most likely stop you anyways.

If they are unaware of or willingly ignoring w:en:Unobtrusive JavaScript we can expect the worst. Many many people have already now problems with the extent of JS already used in Wikipedia. My home desktop PC gets JS timeouts every time I am editing a wikidata page f.ex. so am using the company laptop instead. I also believe, that the developpers are unaware and/or are ignoring that even in grown up countries like Germany still today telecom companies offer 192 kps internet and that German Telekom has announced to scale down in future even DSL heavily after 75 GB per month has used up. It's funny how for a couple of years we have heard any promises concerning a bigger involvement of the global south but atm the WMF does anything to close out the global south. I am sure with the VE and with flow we the number of active editors will drop dramatically. --Matthiasb (talk) 21:06, 24 July 2013 (UTC)

And when we are talking about less grown up countries... the impact is even more severe. And now a question directed at the WMF staff responsible for this: Will you do something to make it accessible to everyone without JS or with not very good internet connection, and if you cant, stop development of Flow?

Yup, they are definitely planning ways to support editors who don't have javascript, or who use screen-readers, etc. See w:Wikipedia:Flow/FAQ#Will_Flow_support_wikitext_or_use_the_VisualEditor.3F, and other comments that specifically mention "without javascript".

One of the most productive admins at en.wiki is completely blind - they have to support editors like him, or editors with slow connections/computers. The aim is always to support maximum diversity - both people, and their hardware.