Last modified: 2014-10-13 19:28:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T69258, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 67258 - Flow: Preview and Edit are not possible simultaneously
Flow: Preview and Edit are not possible simultaneously
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Flow (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-06-28 19:03 UTC by Quiddity
Modified: 2014-10-13 19:28 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
screenshot - before and after Preview (163.20 KB, image/png)
2014-06-28 19:03 UTC, Quiddity
Details

Description Quiddity 2014-06-28 19:03:17 UTC
Created attachment 15774 [details]
screenshot - before and after Preview

Split from bug 67192:

(Bartosz Dziewoński wrote)
> Why is Flow hiding the text area when you're previewing a comment, and
> replacing it with a huge green message bubble? That's confusing. Please just
> do the normal MediaWiki thing for this and no complicated explanations will
> be necessary.

I'll attach a screenshot from http://en.wikipedia.beta.wmflabs.org/wiki/Talk:Flow

I think this is an interesting new experiment. It reminds me of Slashdot comments, where one can only Edit OR Preview, but not both at the same time. (eg. try previewing a test reply at http://ask.slashdot.org/story/14/06/27/1957239/ )

The normal MediaWiki thing, is to use the message:
[[MediaWiki:Previewnote]]
and then show the previewed text
and then show the edit box,
[Which enables us to both Preview and Edit the wikitext simultaneously.]

The downsides of the normal MediaWiki thing, which I believe this experiment is trying to solve, are that it:
* Doubles the quantity of text onscreen
* Pushes the text I'm replying to, further up the window (often above the fold)
* The "This is just a preview" message might be missed by newcomers
* other?

The downsides of the new experiment are:
* Doubles the amount clicking required, for editors who use "preview" a lot. (which should be encouraged!)
* Can't Preview and Edit at the same time. (eg. If I'm wondering how a complicated template will work, I'll:  preview, tweak, preview, tweak, preview, tweak, preview, save. -- Having the Previewed-text stay static on my screen, but just changing slightly each time I preview, is immensely helpful. Versus, having to retain it in my memory whilst I'm in edit-mode)

(Sidenote: I use the UserScript https://en.wikipedia.org/wiki/User:Js/ajaxPreview which makes previewing especially fast, and solves the whole Regular-Preview problem of "Refreshes the entire page, and moves you to #Top".)

I would suggest returning to the normal preview-method. (Especially because the javascript version currently on mediawiki.org/enwiki seem to use something akin to the ajaxPreview, which is nice and fast and non-jarring. (albeit needs aethetic updates))
Then also, place the standard [[MediaWiki:Previewnote]] message in a tooltip at the side, next to the "reply" button. That will provide less inline-text to distract someone whilst they're composing a post. (and less new messages to translate! cf. the original bug)
But I'm willing to be convinced otherwise. :)
Comment 1 Danny Horn 2014-06-30 17:01:35 UTC
Yeah, this is something we should look at. Thanks for bringing it up!
Comment 2 Quiddity 2014-10-13 19:28:40 UTC
Another downside to the new experiment:
* it makes ctrl-Z (undo) non-functional, after previewing.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links