Talk:Flow Portal/Interactive Prototype

Jump to: navigation, search

About this discussion

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL (talkcontribs)
Reply to "Native <input> tags"
NaBUru38 (talkcontribs)

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.

Quiddity (WMF) (talkcontribs)

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.

Reply to "Comment format"
Foxj (talkcontribs)

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 :)

TMg (talkcontribs)

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.
Reply to "Header prominence"
Stefan2 (talkcontribs)

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.

Jorm (WMF) (talkcontribs)

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.

Reply to "Redirects"
Diego Moya (talkcontribs)

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.

Reply to "Inverted page structure"
Diego Moya (talkcontribs)

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?

Jorm (WMF) (talkcontribs)

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.

Reply to "Weird comment reordering"
Lukeno94 (talkcontribs)

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.

Reply to "This looks awful" (talkcontribs)

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.

Patrick87 (talkcontribs)

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.

Reply to "About the current appearance..."

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

John Broughton (talkcontribs)

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.

Jasper Deng (talkcontribs)

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.

Quiddity (talkcontribs)

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.

Jorm (WMF) (talkcontribs)

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.

Reply to "Vandalism, privacy issues, spam, libel issues, etc."
Amire80 (talkcontribs)

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.

Reply to "Actions menu"