On Sat, Jun 7, 2014 at 3:51 PM, Erik Moeller erik@wikimedia.org wrote:
With that said, we will likely experiment with improvements to the existing talk page model as well, just to see how far we can push it. The mobile apps team is interested in implementing talk page support in the apps, and since Flow is still some way out, that may be a good case study to see what we can do on the basis of the existing wikitext conversational model.
Flow is intended to be a system that is effective both for new and experienced users. Everyone working on the system understands that it cannot succeed if it doesn't serve the needs of experienced users. This is why we're intentionally designing it in the context of a gradually increasing number of real-world use cases.
As an example, the Teahouse would be an interesting real-world use case where both new and experienced users interact. Longer term, high volume pages like Village Pumps may make for good use cases.
We can measure and compare the characteristics of conversations in such venues over time. At the most basic level, how many new and experienced users participate? At the more granular level, how long does it take users to perform tasks? Only if Flow compares well to other methods of organizing talk pages, should it be used.
But I've increasingly been getting the impression that there aren't a lot of WMF staff who actually like wikis, let alone developing Mediawiki core.
The WMF technical staff is a pretty healthy mix of people with prior Wikimedia editing experience, people who became Wikimedians on the job, people who contributed to MediaWiki before, people who've not contributed to MediaWiki but who've been part of other open source efforts, and people who're completely new to both Wikimedia and open source. I'll let them speak for whether they like wikis or MediaWiki core, but I think a love/hate relationship with both is not uncommon nor unwarranted. ;-)
Meanwhile, Flow does automatic signatures, but its current design
actually
makes indenting much more problematic from a reader perspective than the current indenting structure.
Flow stores the comments as a structured tree
That seems a fundamental mistake. A discussion isn't a tree, it's a dag. It's possible for a single comment in a discussion to refer to zero or more earlier comments.
-- Martijn
It may be possible to create intuitive ways to display
change over time in a thread view -- if folks have seen examples of that, I'd love to see them.
If it's sturctured as a tree, you won't be able to catch all context.
With that said, rather than maintaining that any given display is inherently superior, or that a fundamental change is inherently bad, I think we should formulate changes as testable hypotheses to the greatest extent possible. Are we increasing readability? Are we improving the quality of conversations? Are we enabling people to participate who otherwise would not?
It's difficult to tell which post is being responded to, who's responding to whom, the responses don't thread well, and it's not possible to rethread a discussion.
Flow doesn't yet have any kind of quoting functionality, which I think would be necessary to add even if we ultimately commit to a deeply threaded default display. It's a hybrid model with limited thread depth, which arguably gives us some of the drawbacks of threading (no clear chronological structure) with some of the drawbacks of flat forums (no consistent reply-level structure). Danny (Flow PM) very much wants to test different user experiences; it's even possible that the "best" experience will vary by use case.
endless scrolling, inability to archive,
The current archiving system for talk pages is an adequate way to retain the history of conversations, but it doesn't actually make it very accessible. I can't easily see all posts by a certain author, for example, and individual threads cannot be categorized or tagged. Summaries, to the extent that they exist, don't automatically surface in relevant places.
Suffice it to say that one of the design goals of the Flow project is very much to build a searchable and understandable history of conversations. We will want to test different mechanisms and see how well they function to manage large conversational archives, including intuitive search tools, tagging of specific threads, etc.
inability to completely remove a thread from a page without actual
deletion and/or
suppression,
The current "comment corpses" have already been identified as an issue and we'll experiment with different ways to manage hiding/deletion of comments.
complex process to find, create, and edit page headers, etc.
There's an "Edit" button which pops up next to the header when mousing over it. I agree that discoverability could be improved, and this UI pattern is also not mobile-friendly. LQT solved this through [Edit↑] [History↑] [Delete↑] links right next to the header.
each product team is working in a silo. Common UI issues are being
addressed
differently across products, increasing the complexity of editing for
both new
and experienced users.
This is absolutely a fair criticism -- there are pretty significant silo effects in the current org, and mechanisms and venues for cross-functional conversation and cross-team mobility are lacking. These are common organizational challenges at times of fast growth, and ones we're tackling on multiple fronts right now. Specifically with regard to Flow:
- Flow was always designed with VisualEditor in mind, and already uses
Parsoid as its parser. Having many mini-VE invocations on a single page is not entirely trivial, but a challenge the team absolutely wants to take on (currently slated for Q2 in the next fiscal).
- Jon Robson from the Mobile Web team will soon begin day-to-day work
with Flow to help the team develop in a more mobile-oriented fashion, and also to share code/templates to the greatest extent possible (currently through an extension shared by both projects).
- The Mobile Web team has recently ported VisualEditor to the tablet
user experience in alpha mode, and in the process, helped uncover and address issues with VisualEditor's libraries and development assumptions.
- We're looking into the best ways to resource the mediawiki.ui
efforts for better integration of standard utility libraries, frameworks, assets, and templates in MediaWiki core, to ensure better standardization of the user experience.
The main product lines have a pretty clear common through line: enabling more users to become part of Wikimedia projects and enabling existing users to work more effectively, by modernizing the user experience, in partnership with the community. We tend to err on the side of being bold, but we're also prepared to walk back when we move too quickly or haven't paid sufficient attention to concerns.
All best, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l