Page MenuHomePhabricator

Sketch alternative approaches to previewing reply
Open, Needs TriagePublic

Description

As Ed surfaced in chat, conversations [1] about what the most useful workflow [2] for previewing a reply composed in wikitext have been going on for some time.

The design, thus far [3], has the preview "replacing" a contributor's text input.

This task is about exploring what an approach might look like where a contributor is able to view their text input and a preview of how their text input will be rendered on the page side-by-side.

Details

Platform: desktop

Open questions

A ranked list, where "1." is the most important question to be answered

  1. Where is the live preview shown in relationship to the text input area? Above it? Below it? Somewhere else?
  2. How should the live preview be styled?
  3. What should be shown within the preview window as the preview is being populated?
  4. When should the preview window become visible to the user?
  5. Should there be a "fallback" experience on slow connections? What should this experience look like?
  6. Should contributors be able to hide and/or disable live previews?

Community input

We are seeking community input on-wiki, here: Talk:Talk pages project/replying

Done

  • Mockup showing what it would be like for contributors to be able to view their text input and a preview of how that text input would be rendered on the page when published
  • Mockups to both approaches are posted on wiki for contributor input

  1. T155732, Preview "oddity" w.r.t. sidebar, A Preview panel that doesn't obscure the wikitext edit box (Was: No feature parity)
  2. Does the preview "overtake" the text input area? Is the preview presented in a way such that the content a contributor has composed and the preview of said text are viewable simultaneously?
  3. Zeplin + T235592

Event Timeline

ppelberg created this task.Wed, Nov 13, 1:33 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptWed, Nov 13, 1:33 AM
ppelberg reassigned this task from ppelberg to iamjessklein.Wed, Nov 13, 2:17 AM
ppelberg updated the task description. (Show Details)
ppelberg updated the task description. (Show Details)
ppelberg added a subscriber: Esanders.
ppelberg updated the task description. (Show Details)Wed, Nov 13, 2:21 AM

As we talked about during today's meeting, we are seeking more information about what use cases would benefit from the "simultaneous approach." [1]

We think posting sketches of the different approaches [when they're ready] on the project page (https://www.mediawiki.org/wiki/Talk_pages_project/replying) will help with this.

Notes
So far, contributors have cited the following reasons as justification for the "simultaneous approach":

  • Speed: "...wait several seconds for the application to switch context between the two views." Source: T155732#2964588
  • Comparing wikitext with preview is difficult: "...new wikitext editor shows preview in place of wikitext, therefore an editor can not compare code with preview at all." Source: T155732#2961909

  1. "Simultaneous approach": Contributors are be able to view their text input and a preview of how that text input would be rendered on the page simultaneously

As @matmarex noted in T235592#5646728, the "simultaneous approach" could be helpful in communicating to contributors they don't need to manually indent/outdent their replies or sign their comments.

I think the way User:Thnidu articulates why they value previews is helpful: "...a large part of their value for me is spotting errors of execution as well as errors of intention." See: this thread

ppelberg added a comment.EditedWed, Dec 4, 8:55 PM

Update: 4-Dec

  • We are working to define how much of the previewing workflow we can design by EOD Friday, 6-Dec. Having minimal designs by this Friday should leave us enough time to have them implemented and live on the on the prototyper server by EOD Friday, 13-Dec, the time we're targeting for the initial round of usertesting.com testing to begin.
  • In discussing the above this morning, we arrived at the following ranked open questions, which are now documented in the task description:
    • 1. Where is the live preview shown in relationship to the text input area? Above it? Below it? Somewhere else?
    • 2. How should the live preview be styled?
    • 3. What should be shown within the preview window as the preview is being populated?
    • 4. When should the preview window become visible to the user?
    • 5. Should there be a "fallback" experience on slow connections? What should this experience look like?
    • 6. Should contributors be able to hide and/or disable live previews?

Still open: what are the answers to the above questions in the context of mobile?

ppelberg updated the task description. (Show Details)Wed, Dec 4, 8:57 PM
ppelberg updated the task description. (Show Details)

Task description update

ppelberg updated the task description. (Show Details)Fri, Dec 6, 12:19 AM

Update: 4-Dec

  • We are working to define how much of the previewing workflow we can design by EOD Friday, 6-Dec. Having minimal designs by this Friday should leave us enough time to have them implemented and live on the on the prototyper server by EOD Friday, 13-Dec, the time we're targeting for the initial round of usertesting.com testing to begin.

6-Dec: update and next steps

  • We are going to run the initial user test without making any significant changes [1] to the current UX
  • Next week, we will test the live previewing functionality to be sure there is nothing fundamentally broken or confusing that needs to be fixed before the initial round of user testing begins on Friday, 13-Dec.
  • Next week: we will start sketching ideas for what previewing could look like when it is implemented for real

cc @Esanders @iamjessklein


  1. "Significant changes": e.g. we're not going to implement any new designs between now and the time we run an initial user test of the prototype
JTannerWMF added a subscriber: JTannerWMF.

This will be high priority for next quarter.