Talk:Flow Portal/Interactive Prototype

From MediaWiki.org
Jump to: navigation, search

Contents

Thread titleRepliesLast modified
What about all the nice things Wikitext offers us? Will they be available in Flow?4923:33, 24 November 2013
Native <input> tags122:56, 23 November 2013
Comment format103:07, 17 November 2013
Editing?1806:04, 19 August 2013
Redirects123:40, 17 August 2013
Header prominence120:31, 13 August 2013
It's awful!606:02, 30 July 2013
Weird comment reordering121:04, 23 July 2013
Inverted page structure014:39, 22 July 2013
Markup-mode *needed* in editor2713:04, 22 July 2013
I liked it a lot - here's why502:34, 22 July 2013
This looks awful007:48, 18 July 2013
Vandalism, privacy issues, spam, libel issues, etc.300:23, 17 July 2013
About the current appearance...116:38, 15 July 2013
Visuals in updated prototype - anywhere close to final FLOW?213:17, 15 July 2013
Flow wastes too much space214:03, 14 July 2013
Actions menu009:03, 14 July 2013
Few quirks, but pretty good otherwise.122:04, 13 July 2013
My two cents121:16, 5 July 2013
To/From105:15, 5 July 2013
First page
First page
Previous page
Previous page
Last page
Last page

What about all the nice things Wikitext offers us? Will they be available in Flow?

Talk pages are necessary to talk about the content we put into articles. Will we be able to use the same features and syntax in Flow as we can use in Wikitext? Some examples that just come to my mind:

  • Basic syntax for text formatting, font size, font face, lists.
  • Wikilinks (including interwikilinks to all WMF projects).
  • Including images and tables using the same code as in Wikitext, appearing the same as in Wikitext
  • Including templates and using custom tags like <code>, <source>

Right now were able to include everything we could put into an article on talk pages. This is absolutely necessary to efficiently produce content for Wikimedia projects. We can't discuss content without visualizing it on talk pages and highlighting the necessary Wikitext.

Patrick87 (talk)21:37, 15 May 2013

Flow will utilize the VisualEditor, so you'll be able to do all the things that the VisualEditor supports.

It's important to note that we are currently focusing only on User Talk pages, and not article talk pages.

Jorm (WMF) (talk)21:39, 15 May 2013

So you are saying that you're forcing everyone into using the Visual Editor, even experienced editors which are much more comfortable with classic Wikitext? Is there a reason to force users using VisualEditor? Shouldn't it be optional so everybody can choose?

"Currently focusing only on User Talk pages" already implies that it will probably be extended to other talk pages as well. Besides that it doesn't really make a difference if it's used only on user talk pages or also article talk pages. User talk pages have exact same needs as article talk pages in my opinion.

Patrick87 (talk)21:50, 15 May 2013

The primary reasons why we are using the VisualEditor in Flow are to a) create a consistent user experience for people and b) to ensure that all posts will be able to be edited by the VisualEditor. Starting with the VE is the best way to ensure that.

Jorm (WMF) (talk)22:06, 15 May 2013

Well, consistent would be to have the same editing functionality everywhere on Wikipedia (basically what we have now) instead of mixing normal articles with LiquidThreads and Flow.

Where is consistency when I'm forced to use Visual Editor on talk pages although I don't like it?

I think you put the cart before the horse: If Visual Editor isn't able to correctly parse all Wikitext it should be fixed. Using a crippled Visual Editor as a "consistent base" neglecting functionality that was there since the early days is just wrong.

If you can't achieve Flow to be as flexible as current talk pages are it will never be a satisfactory replacement.

Patrick87 (talk)22:16, 15 May 2013

You might find watching some of the user test videos enlightening with regards to why Wikitext is a bad idea.

Jorm (WMF) (talk)22:21, 15 May 2013
 

There's also another thing to consider:

It is entirely possible that the data for each post will not be saved as wikitext because there are considerable performance issues that arise when doing so. If this is the case, things like templates will simply be unable to be supported.

Jorm (WMF) (talk)22:34, 15 May 2013
 

I don't think forcing a single experience onto all editors is conducive to any goals. Just let newbies use the visual editor on the talkpage if they like, but let me use the wikieditor.

Maunus (talk)23:19, 14 July 2013
 
 

Many editors disable the Visual Editor. Are they going to be unable to talk? Or are you going to override their preference setting?

Kww (talk)21:35, 14 July 2013

See also Thread:Talk:Flow Portal/Interactive Prototype/Markup-mode *needed* in editor/reply (20) below. Will talk be disabled for people using certain web browsers? If so, then how will we interact with those users?

Stefan2 (talk)18:52, 15 July 2013

It's been stated a few times that they will "provide a fallback mode" for people without javascript, or with browsers that don't support VisualEditor. Nobody will be forcibly excluded. (Take the rumors/hyperbole some people are spreading, with a grain of salt. There are a lot of unfounded/erroneous/exaggerated statements being made recently. Not all, but a lot.)

Quiddity (talk)02:07, 16 July 2013
 
 

Wow, wait a second. What's going on here? I believed in you, guys. You always told us you want to analyze the existing workflows and provide an alternative interface for these workflows without breaking them. Using wikitext on talk pages is an essential feature. Removing this feature is out of the question. This would make the whole Flow project pointless.

Articles are edited in wikitext and always will be edited in wikitext no matter if the wikitext is edited in a WYSIWYG editor or at the source level. Experienced users (the goddam stakeholders in our valuable and beloved Wikimedia landscape) will always use wikitext. Always. They did this for over 10 years and will continue to do this for another 10 years for the same reason LaTeX is still used by experienced users since 30 years. It's not that these LaTeX users are grumpy old people and the only reason they are still editing at the source level is that they are to lazy to learn something new. Young people still learn and love LaTeX today. Same with wikitext. If articles are edited in wikitext it does not make any sense to ban wikitext from talk pages. Not even from user talk pages. We want to talk about the articles we write. We want to show examples of different formating options. We want to talk about different implementations of a template on our user talk pages. We need the same syntax we are using in the articles.

I really don't see a reason why it should not be possible to simply rely on wikitext in discussions like LiquidThreads does right now. Discussions don't use much formatting anyway. Unexperienced users don't need to care about any syntax details. They write a sentence and press "save". They don't need any WYSIWYG. This will only lead them to make their posts super-fancy with colors and all other formatting options they find. This is not helpful. We need talk pages to talk about articles. That's all.

Sure, wikitext is not nice and it's definitely a good idea to make it better (e.g. get rid of the single vs. double brackets confusion, ban deprecated HTML feature like the <font> and everlasting <center> crap). It's not that we need the current implementation of wikitext. It's a language. Languages can be translated. But we need source level editing for both articles and most talk pages. Please don't ruin the wonderful Flow project by banning wikitext. One thing is for sure: If you do this the big communities (especially the German community) will ban Flow. I don't want this to happen. I want a better software for talk pages. But it can't be all WYSIWYG. It must be a well balanced mixture.

TMg18:13, 31 July 2013

I'v never had significant problems with learning wikitext, I know to use double square brackts for internal and interwiki links, and single square brackets for external links other than interwiki, what's so confusing about that, let alone for experienced. One thing is for sure, if liquid threads or flow are enabled on all talk pages, the name signing code (~~~ which signs the post, ~~~~ which signs and dates it and ~~~~~ which produces only the date stamp) is probably unneccesary, and probably should be eliminted from the wikitext on such sites. On a related topic, see this relevant wikipedia ruling, had we not needed the name signing code, there would have been one less remedy in that arbitration case. Also in the WP signature guideline there is a limit to signature length in markup as well as display. With liquid threads and flow, signature clutter is eliminated. Also see Zelda Wiki's signature policy , liquid threads eliminates the need for method 2 and I'm sure flow will too.

Myrtonos@13:03, 29 September 2013
 
 

A few points

  • The current prototype only uses VisualEditor for editing if you enable it in Special:Preferences > Editing. We'll temporarily be disabling VE for Flow soon, the integration needs work (e.g. a separate preference for Flow or maybe an [Edit/Edit source] way to switch editor, an appropriate VE toolbar for Flow, etc.).
  • Most wikitext will work, I believe including everything Patrick87 originally mentioned. We're using Parsoid to parse wikitext. There are... challenges with things like magic words relative to the current "Page", and whether to store expanded templates.
  • You can always use a subpage for the few wiki markup features that don't work in a Flow post, e.g. reflists.
S Page (WMF) (talk)23:16, 12 November 2013

Does Flow properly support templates which display differently for different editors? Commons has lots of templates which display differently depending on the language setting. See for example Commons:Template:Dont upload Wikipedia thumbnails (depends on Commons:Template:Autotranslate), Commons:Template:Original upload log (uses MediaWiki namespace transclution) and Commons:Template:Self-photographed (depends on Commons:Template:LangSwitch).

Stefan2 (talk)00:23, 13 November 2013

Good question. I don't know.

S Page (WMF) (talk)23:33, 24 November 2013
 
 
 

Native <input> tags

67.252.103.2303:30, 22 November 2013
 

Comment format

Hi! I want to show my views on comment format. First of all, the Thank button shouldn't appear and disappear when the cursor moves over each comment, it's annoying. The permalink icon is small so it's ok, but the Thank button is too big for that feature.

The date should be on the top right (as in Gmail), not at the bottom.

The extra details on the user and timestamp work fine, except that I would remove the seconds and the timezone, and shorten the timestamp to "Fri, 15 Nov 2013 14:04", so it's easier to read.

last but not least, where's the Reply button? I can't see it anywhere.

NaBUru38 (talk)23:05, 16 November 2013

Hi NaBUru38, thanks for your feedback on the current layout and interface.

Re: the Reply button, it is positioned directly to the left of the Thanks button (see annotated screenshot), so there must be a bug preventing it from rendering correctly in your browser. Please could you tell me what browser and OS you are using, and if you have javascript turned off? That way I can file a bug, and try to reproduce it myself, too. Thanks.

Quiddity (WMF) (talk)03:07, 17 November 2013
 

Will it be possible to edit messages (both our own and others')? I couldn't find any indication of such in the interface.

Waldir (talk)23:59, 9 May 2013
Edited by another user.
Last edit: 20:31, 15 July 2013

From what was said during the office hours today, yes, certain groups (presumably local admins) would have the ability to edit other people's comments, but most users would not have that ability. Users will always have the ability to edit their own comments. Finally, whether it is the commenter or a sysop that edits the comment, the change will me logged/marked.

Staffer should feel free to correct me if I'm wrong. (Testing to edit someone elses text... Mange01 (talk) 20:31, 15 July 2013 (UTC))

Sven Manguard (talk)01:32, 10 May 2013

Ok, sounds good enough, although it'd be nice to see the intended user interface for that :) I'd just add that probably requiring a sysop to edit someone else's comment would be a little overkill. I think something more akin to rollbacker, or editor would be more adequate.

Waldir (talk)12:08, 16 May 2013

Nice. I believe in this. But I want to be able to edit my own text, but prevent non-administrators from changing it, perhaps causing some kind of indication that the message is revised. That feature is a recent trend in social media.

Mange01 (talk)20:29, 15 July 2013

See the newest version of Flow Portal/Interactive Prototype, which adds a text indicator once you've edited someone's comment (enter "admin mode" (in the sidebar) to test it out).

See Thread:Talk:Flow Portal/Interactive Prototype/Vandalism, privacy issues, spam, libel issues, etc./reply (2) for my comment&pointer about user-level-restrictions.

Quiddity (talk)02:16, 16 July 2013

I agree, that really shouldn't be called an "admin" action - it is a part of everyday wiki cleanup to move around or archive comments left by others in the wrong place, or left inappropriately. Making that right something that all editors or rollbackers have should suffice.

Sj (talk)08:05, 16 July 2013
 
 
 

I would like to stress this a bit. I find it very strange that there is no "edit" action for all posts in the mock-up. There are lots and lots of reasons why an experienced user wants and should be able to edit posts written by other users:

  • Simply fixing a broken link.
  • Clean other markup and make the post more readable. For example add or remove newlines. Some users tend to put an empty line after every sentence. This makes talk pages ugly and confusing no matter what software is used and should be allowed to fix.
  • Move a post or parts of a post to an other talk page and leaving a "moved to" hint.
  • Top reason: What if I want to copy and paste parts of the wikitext an other user wrote to use it in the article? Or even simpler to look at it and learn the syntax.

Therefor, in my opinion it must be possible to edit all posts. At least for autoconfirmed users. All other users should have the possibility to show the wikitext of all posts like they have with every protected page.

TMg17:35, 31 July 2013

It is to be local Wikipedia option as to who is to be able to edit others' posts. Although WMF's initial concept was to be admins only, en.Wikipedia has come out strongly for all users.

Arthur Rubin en.Wiki (talken.Wiki)17:51, 1 August 2013

What does "en.Wikipedia has come out strongly" mean? Do you have a link?

TMg19:43, 13 August 2013
 
 
 
 

If a user has multiple accounts (for example an extra account for insecure connections, or a bot account), the user talk page for the extra account is often redirected so that the posts end up at the talk page of the main account. Also, if a user account is renamed, the user and user talk pages for the previous user name tend to be redirected to the new user name. How will these features be implemented using Flow? I hope it won't be like Wikia's horrible message wall where I can't figure out how to add that kind of redirects.

Stefan2 (talk)12:39, 1 August 2013

I think that user renames should end up working transparently, for the most part.

What you're talking about is the concept of "Merging Boards". I have a chat with Erik about its implementation; I can't imagine it being that difficult.

Jorm (WMF) (talk)23:40, 17 August 2013
 

Header prominence

While I understand design is backseat to functionality at the moment, and that this is likely far from finished, I'd like to politely point out that, as it stands, the username block (with the "6 months ago" etc) is ridiculously prominent and dwarfs the (much more important) thread headers. I think having massive font sizes and bold colours for the usernames is pretty backwards, and I think the username should probably be at the bottom of the comment as opposed to the top. Just my opinion but hopefully you can see the concern :)

Foxj (talk)04:34, 10 August 2013

I agree:

  • The font size of the thread headlines is to small.
  • The font size and colored boxes with the user names are a little bit to big.
  • There are still to much border lines and boxes. Even if most of them are dimmed.
  • The total width of the page in the current prototype is way to narrow. It's limited to only 700px width some "max-width" and even "width" CSS styles. This wastes huge amounts of space even on medium size monitors. This will make discussions with very deep nesting nearly impossible to read. I think I wrote this before but I can't find it any more. Don't tell me this fixed width is required because of small screens. It's not a problem to make the CSS "responsive". It scales down on small screens and scales up on large screens.
TMg20:31, 13 August 2013
 

It's awful!

It's awful. It works extremely slowly on my computer. 178.66.190.120 20:05, 18 May 2013 (UTC)

178.66.190.12020:05, 18 May 2013

It's a demo. It has not been optimized for speed in any way. Since everything is loaded and parsed via JSON, it's going to be slow no matter what. In the real world, it will be much faster since rendering will happen on the server.

Jorm (WMF) (talk)21:25, 18 May 2013

Both expanding and collapsing all threads take about 1 minute, and page hangs for that time. 178.66.175.191 14:49, 21 May 2013 (UTC)

178.66.175.19114:49, 21 May 2013

Expand/Collapse all will most definitely not be in the final product. The function doesn't make sense when a page is an infinite-scrolling buffer (you could activate a "collapse all" but then topics that have not loaded at the time will not be collapsed, etc.).

It is also very important to note that this is an "interactive prototype". It's built out of html, javascript, and hope. It has not been optimized in any way and, by its nature of constructing and destroying elements on the fly, is going to be significantly slower than the real thing.

Jorm (WMF) (talk)22:48, 22 May 2013

If "collapse all" is not available, will you provide a "Table of Contents" or "Titles List" instead? An overview function, allowing you to see the titles for all threads (and sub-threads) in a page is an essential function for quickly scanning the contents of a talk page. "Collapse all" was a poor substitute, but it at least provides that function in a limited form.

Diego Moya (talk)06:02, 30 July 2013
 
 
 

Curiously, I found it pretty quick on mine.

Anthere (talk)20:29, 23 May 2013

¿Que es este sitio?

Leitoxx (talk)22:04, 29 July 2013
 
 

Weird comment reordering

I'm testing the new prototype and I'm unable to make sense of how comments are reordered when several thread levels are involved. I don't know if this is a bug or the expected behavior, given that the post is animated and mover to different place after I press "Reply" instead of standing there where I wrote it.

Say we have this existing conversation:

  • Post by user A
    • Post by user B
      • Post by user C

Now if I post a reply to the first post by user A, this is the result:

  • Post by user A
      • Post by user B
    • My reply to user A
        • Post by user C

This makes it seem like user C was replying directly to me! Also all connection between user B and C is lost. The only hint that something weird happened (apart from the conversation not making any sense) is because "My reply to user A" has a more recent timestamp than "Post by user C".

What I expected to happen is this:

  • Post by user A
    • Post by user B
      • Post by user C
    • My reply to user A

This is how conversations with different depth levels are handled nowadays. It's a common idiom at places like Slashdot and Reddit. I hope this behavior is a bug? If not, can someone please explain it to me?

Diego Moya (talk)13:54, 22 July 2013

I think the behavior you're seeing is a bug and an artifact of the fact that the content is loaded from a JSON file and has no real structure.

Jorm (WMF) (talk)21:04, 23 July 2013
 

Inverted page structure

The current page structure at the board looks upside-down to me. The floating toolbar with the option to start a new thread obscures the page navigation, and input actions are usually found at the bottom of dialogs.

I have this suggestions to improve the page layout:

  • put the input form "Click here to start a discussion with UserX" at the bottom of the page. At the top of the page put a "back to top" link or a breadcrumb (see below).
  • Include the form "Click here to start a discussion with UserX" when watching a filtered thread (the default status when following a notification).
  • When watching a filtered thread, change the "Back to board" button to a breadcrumb that also shows the thread title, like this:
 " Back to Ryan_Vasey's board > Can page curation stop a copyvio spammer?"

This should increase the reader's awareness of where a conversation is taking place, and make it more explicit when starting a new thread where it will be located.

Diego Moya (talk)14:33, 22 July 2013

Markup-mode *needed* in editor

Edited by another user.
Last edit: 02:54, 15 July 2013

Since VisualEditor is active on English Wikipedia now I had experimented with it here and there. And what should I say – I hate it! Whatever I do quickly with a few characters in Wikitext (e.g. Wikilinks, text formatting, embedding graphics, templates, etc.) needs at least the same amount of clicks through various windows in VE and takes ages therefore. In my opinion this is just unacceptable for experienced users – and I'm not the only one as the overwhelming consensus regarding the necessity for an opt-out of VE shows.

I don't want to get into the discussion whether VE is a good or a bad thing here. Personally I even think it's great for newbies or people with a reluctance towards markup in general. But there needs to be a choice!
I therefore strongly suggest that – however the final FLOW will look like – a tiny checkbox is installed somewhere in preferences where one can select whether to edit comments in a simple markup editor or VisualEditor (and maybe even a small button in both editors to switch to the counterpart directly from the UI).

Don't get me wrong, I don't want to be able to use all functionality of Wikitext (Jorm already pointed out that this won't be possible due to how comments will be saved in the backend). But all formatting that will be available to the FLOW-VE editor (which will only be a subset of the normal functionality, too) should be available in a FLOW-Wikitext editor.

Patrick87 (talk)22:14, 13 July 2013

You should strive to achieve Zen acceptance that the only editor for Flow will be the VisualEditor. If, by the time Flow is released, the VisualEditor supports a native code editor, it will likely be there. But nothing is promised - nor can it be.

Jorm (WMF) (talk)22:24, 13 July 2013

Well, maybe you should strive to get the native code editor ready by then. Otherwise you'll have a really hard time to achieve Zen acceptance that Flow will be rejected.

I'm sure you followed the discussions around the VE start on English Wikipedia – they were more than heated and I'm glad nobody came to death (merely joking). All this was only because the VE editor was deployed in parallel to the WikiEditor. Now, can you imagine what would have happened if the WikiEditor was removed in favor of VE? I honestly can't (and I don't want). But exactly this is what you are proposing!

I don't mind if the markup editor is part of VE or not. But I'm sure if there is no markup editor available the day Flow should be deployed will be the day it is either abandoned or the day on which many editors will be searching other projects to spend their time on.

Patrick87 (talk)22:54, 13 July 2013

You'll have to talk to the VisualEditor team about their functionality, I'm afraid.

Jorm (WMF) (talk)05:11, 14 July 2013

Oh, come on Brandon. We're all sitting in the same boat (while we can leave it when it sinks, you can't).

Now you ask me (who I am not involved with the WMF or development at all) to talk to your colleagues how they should design VisualEditor to work with your discussion system?

I'm not bugging you with this for the sake of bugging. I do it because I know it will cause serious clashes (to the point of people boycotting Flow or even leaving, both of which can't be your goal), when it is not fixed. I propose you achieve Zen acceptance that a markup editor is needed and start to negotiate with the VE team how fast they can implement a markup editor.

I do not understand why you're giving yourself so stubborn regarding this issue. It helps neither you nor Flow nor the community to deny the obvious.

Patrick87 (talk)13:50, 14 July 2013

I'm saying that I can't promise anything about what the VisualEditor will and will not support. I am not working on that project and cannot speak for their roadmap, nor do I have any level of influence over it.

Jorm (WMF) (talk)22:08, 14 July 2013
 
 
 

Why should anyone achieve "Zen acceptance" of the Visual Editor? Why should anyone be required to use it in order to use this as a replacement for talk pages? When I disable the Visual Editor, that's exactly what I expect to happen. I don't expect it to suddenly pop up again under a different name.

Kww (talk)21:25, 14 July 2013

I agree. I want to disable it entirely and I certainly dont want to be forced to used it on talkpages.Maunus (talk)

Maunus (talk)23:16, 14 July 2013

While I'm not entirely sure I'd want to disable it entirely myself (we'll see how I like it when it is done), I do want the option to be there. No one should have to be forced to use it. I agree with the sentiment that if you disable VE it shouldn't pop up again on another type of page.

Zellfaze (talk)12:51, 15 July 2013
 
 

When I'm reading and editing Wikipedia on my phone, I am usually using Opera Mini as that browser uses up a lot less power and bandwidth. The browser is marked with a big red X mark.svg at VisualEditor/Target browser matrix. How will I be able to respond to a comment posted on my talk page, if there is no way to use the visual editor using Opera Mini? Also, 8% of the users use MSIE 8.0, which isn't supported either. How will they be able to respond to comments posted on their talk pages? I'm seeing no choice but to post a big notice on my talk page and in the corresponding edit notice saying that posts to my talk page won't be read or answered and that you have to post a message in wikitext at Special:MyPage/talk instead.

Stefan2 (talk)18:09, 15 July 2013

As has been stated many times, there will be a "fall back" editor mode for those users who cannot use the VisualEditor. This fallback editor will not be as fully functional as the Flow's version of the VisualEditor.

For example, the Flow version of the editor will allow you to "ping" or "mention" users by typing an "@" sign and then you'll be given an auto-complete of the username to fill out. We can't do that with a fallback editor. It's functionality that will not exist (same with other auto-completion tasks). There are other differences as well: in order to ensure "future compatibility" the fallback editor will likely support only a subset of the full wikitext language.

I'm sorry you feel that you will have to create a complicated, unfriendly work-around. I would urge you to at least think positively and try the tool out first before assuming that the universe is ending.

Jorm (WMF) (talk)00:27, 17 July 2013

NO! I really HATE the VE.

Wolf Lambert (talk)09:16, 22 July 2013
 
 
 

So, the WMF is going to screw over the visually impaired? Going to break every bot that edits talk pages? Remove the ability to copy material from the article to the talk page? [Or are you going to force VisualEditor on article pages too?

Is everyone in the WMF on drugs?

Adam Cuerden (talk)23:27, 14 July 2013

For that matter, how will templates work on talk pages if Wikitext isn't even supported? Are you expecting your users to recode nearly a decade's worth of supplemental material in order to let you have your Flow? Because, if you do, expect the flow to stop pretty quickly.

Adam Cuerden (talk)23:32, 14 July 2013

Templates will likely be supported in two ways:

  • As being subst'ed in (like from a bot post, for instance)
  • As to the degree that the VisualEditor currently supports them.

What we are trying to avoid is the situation where broken/horrific wikitext is inserted into posts that make them unusable and unreadable in the future (like the current way hatnotes are implemented, with a collapse top and a collapse bottom template).

Jorm (WMF) (talk)00:01, 15 July 2013

What's horrific about the hatnotes?

Cyclopia (talk)20:17, 15 July 2013

Hatnote templates are actually broken, incorrect wikitext. They create code sections that are extremely difficult to parse because neither the top nor the bottom template is "syntactically complete" - each is but one half of a wikitext idiom (or program, if you like).

Flow has built-in functionality that replaces hatnotes.

Jorm (WMF) (talk)00:29, 17 July 2013
 
 
 

No one has said anything about screwing over the visually impaired - and, in fact, there's an earlier thread about just that (visual impairment and dictation software and disabled javascript). Obviously there will be a fallback version. It will not be as feature complete - by necessity - and it will likely be clunky, slower, and less usable (as is the way of things like this).

I'm not sure where you get the "cannot copy content" from. I don't believe anyone has said anything like that.

I would like to request that we have less hyperbole. It makes the conversation needlessly hostile.

Jorm (WMF) (talk)23:58, 14 July 2013

Jorm - VE does not support copying of formatted information from one page to another. Copying a footnote (let's say, footnote 3) simply pastes a "[3]" to the new page.

It's quite common, in talk page discussions, to copy/paste wikitext that is, or includes footnotes, from articles - for example, to show what was removed by an edit. It's common - perhaps even more common - to post potential footnote to a talk page, and - if acceptable - to have them copied to the article by another editor. That's what we ask those with conflict of interest issues to do, for example.

John Broughton (talk)01:50, 15 July 2013

Yeah, and I think that's one of the things they're working on fixing. Seriously, though: I'm not on the VisualEditor team, and I can't speak for their roadmap.

Jorm (WMF) (talk)01:52, 15 July 2013

I'm not entirely sure anyone can speak for their roadmap at this point. The Engineering Roadmap and the Mediawiki Roadmap's sections on Visual Editor are maybe not so verbose.

EDIT: Though I may be being a little bit hard on the engineering road map. It does have some information, but it really isn't as detailed as I would like.

Zellfaze (talk)12:50, 15 July 2013
 

Though if Flow is going to rely exclusively on the VisualEditor, your feature set is their feature set, isn't it? How can you create a design for your interface if you don't know and can't control the one module that is core to the possibilities of your tool's workflow?

Diego Moya (talk)13:27, 15 July 2013
 
 
 
 
 

I liked it a lot - here's why

Some of the previous comments have mentioned that the majority of the comments have been critical of Flow. I, however, like it a lot. Perhaps it's because I tried to follow along with the development of Flow and with Jorm's thoughts on this and other subjects, but there are also other reasons:

  • I much prefer that you won't have to click "edit" to start editing but simply place the cursor in the right place and start typing
  • after clicking "save", Flow seems to work the way most normal systems do, with not reloading the page and you having to scroll down to the right place, but rather stay on the right comment
  • I think the thing about not having to sign your comments is long overdue and will significantly improve life on the wikis I am active on. On Swedish Wikipedia our Report an error page, and newcomers' talk pages are full with comments about their forgetting to sign
  • it seems to be very much easier to teach to new editors; something that I do a lot
  • automatic indentation is one of the good things about Liquid Threads, and it is good to see it included here. So many people get it wrong in the present wikitext system
  • the "unsubscribe from topic" and other topic choices make Flow look like something that I want to work with. There are so many topics that start out promising but then go on forever, and these type of choices make that easier to deal with, rather than having to unwatch the whole talk page/Wikipedia page
  • the left hand arrow that allows you to minimize or maximize a topic is better than what we have now, where you can scroll through the same things over and over (I trust that the choice for the topic will be remembered?)
  • the "working" image (the W logo being drawn) is beautiful
  • I like being able to mark pages as read. Not enough systems have that option
  • the box with the profile page, archived talk, etc is very good to have on top, instead of to the left. It make those tools easier to find

To couter some of the criticism about Flow taking too much space for each comment, I don't really think that is going to be an issue. I've seen Jorm working and I am confident that this is something he will work on, and get others to help. Perhaps a system with the user name to the left and the comment to the right.

I would ask for a way to "favorite" a topic, to keep it near the top of the page.

All in all, an improvement that I look forward to seeing deployed. Thanks for your work.

Hannibal (talk)22:56, 13 July 2013

That's great feedback (clearly explained, well-separated, and positive!), and an interesting suggestion. Thanks! More suggestions would be welcome.

Quiddity (talk)20:18, 14 July 2013
 

Thank you so much for this feedback. As Quiddity says, it is very good and well-explained.

Regarding your suggestion about each topic remembering its closed or open state, I would love to do that, but there may be technical limitations that prevent it. It's a lot of data to process and store. I know how we would do it (it would be another field in your "subscription" to the topic) but there may be issues with remembering state on topics you aren't subscribed to (which would create a weird and inconsistent user experience). However, I'll look into it and talk to our software guys about it.

Jorm (WMF) (talk)00:49, 15 July 2013
 

This is largely just a "me too" on Hannibal's comments. All of this is going to come with some points of friction--to pick an example, I've poked folks on every side of this discussion about the impedence-mismatch that's going to come from AfC drafts currently living on talk pages--but I think the cost of the change will be amply repaid by how much nicer an environment this will be for discussion.

Joe Decker (talk)17:41, 16 July 2013

AfC just needs to be moved to another namespace to keep it away from Flow; it's not, and not intended to be, suitable for the concept of Flow.

That being said, the prototype would be suitable for an additional place for Wikipedia discussions. In my opinion, and that of all en.Wikipedia editors who have expressed an opinion at w:WT:Flow, as that it, as presently conceived, is not suitable for a complete replacement of user talk pages, and cannot be made into a replacement for article talk pages without undoing much of what is presently proposed.

Arthur Rubin en.Wiki (talken.Wiki)20:29, 19 July 2013
 

It's nice to counter some of the negative feedback, but we should also try really hard to think of suggestions for improvement. I agree that the prototype has many significant improvements and I'm glad that you highlighted the space issue as an area to improve. Hopefully Jorm does take that seriously as you suggest. It feels somehow very crowded partly due to the margins and large font. A minimalist version for those who have sharp eyesight and want to take in a lot of information quickly would be nice. I also agree with many of the other comments on this page (e.g., source editing for convenient wikilinking and stuff).

The floating "start new discussion" box is distracting and takes up a ton of space, making it a negative. There's tons of empty space to the right where you could float some sort of menu with various options, including even a table of contents which could be helpful. If I want to start a new discussion I'll have figured that out when I land on the page. Notably, the prototype squeezes the text into a fixed-width div of 798 pixels (at least on my laptop) whereas the status quo is a fluid div which generally ends up being significantly wider in general for me. I believe some research suggests that short widths are easier to read, but it comes at the expense of more scrolling. The empty space on the right could also be used, although I really like the idea of being able to minimize things if you're in the minimalist mood, which I often am.

I have a little trouble understanding how this is all going to fit together based on this prototype. Is there going to be any actual test server, where we can play and it will save? It seems that there's generally been a reluctance to let editors test in a test environment, which I don't understand.

On the higher-level, the tagging will be nice although details are scarce (Talk:Flow_Portal#Thread_tags_27816 and Flow_Portal/Architecture#Tags) - it's not clear that the tags discussed in Flow_Portal/Use_cases#Talk_namespace are the same. There should also be more readily-available ways to list pages which are having a lot of discussion and I imagine the feed will allow you to select which tags to follow, which could reduce siloing and could help editors meet other people in the more informal space of talkpages. Often a user talkpage discussion will actually be related to a discussion on an article talkpage or an ANI talk, and tagging or linking these could help show the totality of the discussion.

ImperfectlyInformed (talk)22:58, 21 July 2013
 

This looks awful

Seriously. It's clunky beyond belief in its appearance; it looks like it came from the 1980s, and not in a cool "retro" way either. It looks like a particularly low-rent forum. It takes up more room than a talk page, and is literally no improvement over a talk page that has actually been used correctly.

Lukeno94 (talk)07:48, 18 July 2013

Vandalism, privacy issues, spam, libel issues, etc.

Today, every editor has the ability to remove vandalism, violations of privacy, libel, purely attack postings, wikichat, and so on from talk pages. Flow doesn't allow that!?!

What I'm seeing is statements like "Administrators must be able to delete individual comments or entire topics"; "certain groups (presumably local admins) would have the ability to edit other people's comments, but most users would not have that ability". Do you have any idea how many thousands of posts are deleted (directly or via revert) every day from talk pages? Are you really seriously thinking that whenever an editor sees something wrong, he/she should summon an admin?

The larger issue is that wikitext, and diffs, establish accountability. Yes, any editor can delete another editor's comments, but do that more than once - after a warning, probably posted via template, on the editor's user talk page - and that editor is likely to get blocked. Yes, any editor can edit anyone else's comments - but it better be constructive and defensible, or

And that's the problem with Flow as it seems to be conceived - exactly the problem that has resulted in moderation on discussion boards, and for comments to blog posts, and to a lot of blog posts not even allowing comments - it takes a lot of work to prevent abuse. Wikis solve that problem by enabling any editor to be a moderator (remove abuse). And the ability to see exactly what an editor did (diffs) establish accountability - yes, editors have all this power, but they also can be held to task.

So, if we're talking grand design here, the software absolutely needs to meet three major requirements:

  • (1) A majority of the experienced editors (for example, those with rollback privileges) must be enabled to fix problematical posts; the system will fail catastrophically (spam, vandalism, abuse attacks, etc, on user talk pages) if only admins can act on problematical posts.
  • (2) It must be possible for editors to edit the posts of others, not just hide or delete them. For example, in an article talk page, some issues are potentially libelous; it's critical to remove the libelous part without just deleting the posting if a good discussion is to continue (and, obviously, to prevent editors from feeling that their posts are being censored).
  • (3) There has to be accountability when someone edits someone else's posting (or deletes it, of course). That is, there has to be an "audit trail" - which is what diffs are - so editors can be accountable. There also has be to be some way to scan the editing that other editors have done (that's one use of diffs, in history pages); otherwise "accountability" is a pointless word.

If Flow can't do (2) and (3), that's a deal-breaker, as far as I'm concerned. The English Wikipedia isn't a pristine world where 99.9 percent of posts are non-abusive. Rather, it's a very messy place, with lots of vandals and spammers and trolls and newly-registered editors who don't understand community norms and IP editors who often have zero understanding of - and zero commitment to - Wikipedia's rules. In such semi-chaos, (almost) every experienced editor needs to be a moderator of sorts, and moderation has to be more than just deleting problematical postings.

John Broughton (talk)02:48, 15 July 2013

I have to concur and note that this was one of the pet peeves I've seen with LiquidThreads. Although most people can edit most posts, only admins can outright delete them.

Jasper Deng (talk)02:50, 15 July 2013

See w:Wikipedia_talk:Flow#Arbitrary_Section_Break_1, particularly Jorm's and Whatamidoing's comments. Editing other people's comments is just a user-right, which will (presumably) be up to us to decide how it is given out (and/or changed later on). If it can be restricted to "group-admin", it can be restricted (or unrestricted) in any way.

Quiddity (talk)04:37, 15 July 2013
 

There's a lot here; I'll see if I can capture all of it.

Currently, the prototype defines the following:

  • Editing your own comments is something you have the right to do.
  • Editing the comments of others is something that requires privilege (in the prototype, that's the "admin" toggle)
  • Deleting a comment is something anyone can do.
  • Restoring a comment is something anyone can do.
  • Deleting a topic (and all comments in it) is something anyone can do.
  • Restoring a topic (and all comments in it) is something anyone can do.
  • Closing a topic (hatnoting it) is something anyone can do.
  • Re-opening a topic is something anyone can do.
  • Suppressing a topic is something only those with privilege can do.
  • Editing a topic title is something anyone can do.

All of those use cases above are doable in the prototype. There is another use case - suppressing a comment - that has not been implemented in the prototype but will be in the next revision.

When comments are edited - by anyone - a marker is placed in the comment indicating that it was altered and by whom.

When a comment or topic is deleted - by anyone - a marker is placed indicating that an item was deleted and by whom. Leaving the marker is important for thread continuity and to note that replies to the comment have been left to something no longer there.

The only functional difference between the current model and the Flow model is that the ability to edit someone else's comments is restricted. That's it.

Jorm (WMF) (talk)00:23, 17 July 2013
 

About the current appearance...

It looks very VERY old.

My suggestion: 1. Getting rid off that awful grey background as soon as possible, and picking another color (maybe light blue), with a glittering fade out effect - similar to the one Microsoft Windows 8 tiles use. 2. Changing the confusing arrows design to the standard + and - convention, in order to collapse and expand replies and threads. 3. Space a bit (just a bit) between the different replies, so that they appear in an entire different boxes. This looks nicer and easier to read. 4. Change the titles' view of each thread - current design looks almost exactly like current Wikipedia's one, which, once again, looks anachronistic.


That's all for now, as for a 5 minutes impression.
Oz.

84.111.9.22016:14, 15 July 2013

Sorry, but what's wrong with Wikipedia's current style? It's functional maybe that is what you mistake for "anachronistic"?

I think Flow should look much more as if it actually was Wikipedia. Currently Flow looks like something completely different, forcefully plugged into MediaWiki, without the intention of making it blend in.

I'm fine with a skin that has all this "glitter" you're proposing (and that can be chosen if the user likes glitter more than functionality). But it should be used site-wide, as every skin should. Everything else will always look like unfinished work or patch-work.

Patrick87 (talk)16:38, 15 July 2013
 

Visuals in updated prototype - anywhere close to final FLOW?

Edited by author.
Last edit: 22:15, 13 July 2013

Hi Jorm,

you just updated the interactive prototype and I noticed that there are many changes regarding visuals (padding, user infos like post count and the like).

Does this mean that we're approaching a state were we can comment on visuals? Or should we still focus on functionality rather than UI?

Patrick87 (talk)21:53, 13 July 2013

Feel free to comment all you like. You should know that these visuals (the buttons, etc.) are very close to the final Agora designs that we will be rolling out. So you'll be commenting on Agora more than Flow, but as far as you're concerned, they're the same.

Jorm (WMF) (talk)21:58, 13 July 2013

If you're taking feedback on the visuals, I have my share of comments. (Warning, wall of text below).

- The borders around each comment are too big and heavy. They provide too low density of text - requiring a lot of scrolling. Also while colorful, they're distracting - I want my eye to flow towards the text, not the interaction chrome. Make them low-contrast and to the left of text, like every other discussion system does for good reason.


- I find the overall navigation metaphor confusing. If I click on a notification, it shows a conversation without context, and no clear indication of where I'm located. I've barely noticed after the fact that there's a breadcrumb at the top with the label "Back to board" - it should be more clear to what place it returns (i.e. "Back to <username> board").


- I'm not sure in what order one is expected to consume the conten. The old talk pages (as well as every blog in existence since the 90's) have a table of contents that show conversations on the order of creation. With the automatic reordering, all spatial is lost. If you skip one single thread, it's impossible to tell whether you've already read it or not. The "mark as read" is a workaround - it forces the user to manage a manual upkeep of the read status, which should be automatic.

There should be a static index where all threads are located by creation so thread titles can be scanned and located quickly. Again, copy the well-proven interface of blogs and you won't err.

If you want a flowing interface to keep track of updates, that's fine, but that shouldn't be the primary navigation metaphor; conversations are different than items in the review backlog, which need to be reviewed just once. When you want to get back once and again to the same content, there must be a static structure to relate all of it; I find the blog metaphor the best one for Wikipedia, where discussions can be kept alive for months and referred to for years after they've finished. Please don't reinvent the wheel, forum threading is an already solved problem - just copy the state of the art and provide refinements on it, not whole new paradigms.


- As for the "Mark as read" button, it's unclear what will be marked when pressed: the whole thread? the whole *board*? Only the current comment? All comments above? Here you can copy the design at GMail's thread - the "mark unread from here" button available at each comment, exits the thread, and only previous comments are marked as read - everything below the button is kept unread. That's a exquisite solution, even if non-standard, and works reasonably well.


I hope these comments will help refine the interface. I have a severe case of lost-in-hyperspace case with that flow metaphor.

Diego Moya (talk)13:12, 15 July 2013
 
 

Flow wastes too much space

I just checked the interactive prototype and saw that most "threads" only contained few posts. I then thought about how some threads at en:WP:VP would look in Flow – and I shuddered. The already page-long discussions would virtually get endless. Even when Flow leaves out some messages I think this could be a serious problem.

Also from a usability point-of-view I think there is plenty room for improvement: Currently a comment with two lines of text (those two lines are the real content of a comment, everything else is more or less background information, and should be treated like that) take up roughly 8 lines of space. This is four times the space necessary.

Sure, the prototype looks, nice, but I'm afraid it wouldn't be fit for real world usage. As an example I took two screenshots: The current style of the interactive prototype, and a version I quickly reduced in size:
Flow layout 1 (current).pngFlow layout 2 (proposal).png
It's only half the height while showing exactly the same information! And it could even be optimized further (e.g. the header currently takes two lines, too).

Patrick87 (talk)23:22, 13 July 2013

Right.

Jorm (WMF) (talk)05:10, 14 July 2013

I would also favor an action Reply over an edit box after each comment, like Patrick87 says it makes the UI more compact, but also less cluttered with standard texts.

Erik Zachte (talk)14:03, 14 July 2013
 
 

Actions menu

In Vector, actions in "Toolbox" (What links here, Upload file) and in the dropdown menu near the search box (mostly Move), are unknown to quite a lot of editors. I don't have precise data, but new users ask me where to find these actions quite frequently, so I'm assuming that they hard to find at least to some people.

I am writing this, because the same would be true for the actions in the little "Actions" menu in the corner. It would make more sense if the actions would appear as simple links written in a human language rather than hidden in the menu. Maybe some actions that are expected to be rare can be put there, but not all.

Amir E. Aharoni (talk)09:03, 14 July 2013

Few quirks, but pretty good otherwise.

I noticed that on the boards, it could get long at times, especially at Fully Chaos. Could we make it smaller? I like it, and know it's just a demo, but the space thing needs more work. Also, I loved the fact that I was an admin, and the link to List of animals with fictional diplomas!

Buffbills7701 (talk)22:19, 5 July 2013
Edited by 0 users.
Last edit: 21:58, 13 July 2013

The load times are an artifact of this being a prototype. It has to render everything from JSON source files. It should be significantly faster in the real world.

Jorm (WMF) (talk)21:58, 13 July 2013
 

My two cents

I appreciate the time and effort that is being put into this project, and several of the changes from the traditional talk page format may be helpful. However, there are several major elements of Flow (as it stands now) that make me very opposed to its future use, in particular on the English Wikipedia. (I'm going to refer to the current interface used for talkpages as "Talk Prime" to same time/space.)

First and foremost, the interface is clunky. Discussions take up a lot more space than they would if rendered as wikitext in Talk Prime. From a design standpoint, the Flow interface appears drastically different from Wikipedia's default skin. When compared to the rest of Wikipedia, Flow honestly looks like it comes from a different website altogether. It even looks like it comes from a different kind of website—more like a chat forum or social network.

This brings me to my next point, which is about Flow's timestamp format. In Talk Prime, timestamps render as the UTC time and date at the moment of posting. Flow renders timestamps as "about [x] [unit of time] ago", and the exact date and time is accessible upon hovering over the text. While this may be useful for people unfamiliar with UTC, it is a huge departure from Wikipedia's current practices. It also makes it harder for those of us reading on mobile phones to get the exact date/time of posting. I imagine it would also pose an accessibility issue for visually impaired people reading Wikipedia with a text-to-voice screen reader.

I also dislike that the edit count of a user is displayed. I will expand on this and other points later, but for now I have to go as my lunch break is up. Cheers, Cymru.lass (talk) 19:35, 5 July 2013 (UTC)

Cymru.lass (talk)19:35, 5 July 2013

Keep in mind that it is just a concept-mockup, and not a design proposal.

E.g. The timestamps for a post are stored in a database, and could be styled/displayed according to user preferences, just like our current Special:Preferences system allows.

So, think more about the abstract ideas and big-picture - don't pay too much attention to the prototypes's visual-design and layout. See also Thread:Talk:Flow Portal/Flow is too tall/reply (6)

Quiddity (talk)21:16, 5 July 2013
 

Jorm responds to many comments, although I had no clue Jorm was to this page. Maybe some sort of "To:" function could be included. Also, second level responses by others seem gangish rather than informative. Which brings up the subject of who patrols the vandalism patrolls. I personally am tired of vandals using warnings to vandalize user talk pages. I've found one way to avoid them is to finish the article off Wikipedia. Then, contribute it and forget it. The way Nupedia was probably written by those asked to write them.

67.101.80.18705:04, 5 July 2013

Have you encountered the new en:WP:Notifications features? One of those, is the new "Mentions" feature, whereby if you link to a username, and sign the post with 4-tildes in the same save, it will send a Notification to the user saying "You have been mentioned by x at y."

You do have to be logged in to receive Notifications though.

AFAIK, Notifications is only in a few wikis at the moment (such as here and en.wiki), but will be rolled out to meta in the next few months, and other languages in the latter half of the year.

Cross-wiki Notifications, are also on the roadmap.

This, and other "To:" type functionality, is already being strongly thought about for Flow and Notifications. Good times are ahead!

Quiddity (talk)05:15, 5 July 2013
 
First page
First page
Previous page
Previous page
Last page
Last page