Hi, Multimedians.
I've been talking with our new multimedia team, we're just getting to the point where we have a really good idea of where we want to go after a little while of doing work mostly on existing issues and refactoring efforts, and I have a small announcement to make.
In the next few months, we intend to work on pulling upload API logic into core, and writing a new interface for uploading files from VisualEditor. Our initial plan involved refactoring UploadWizard to a point where including it in VisualEditor would not be difficult, but our new plans include usability improvements that, in my opinion, would unnecessarily enmire our work. Our team will be submitting patches to OOJS-UI, MediaWiki Core, and VisualEditor itself in an effort to get this project off the ground, as well as tweaking configuration settings in mw-config and generally running around looking for code review.
Rest assured, we intend to maintain our commitment to fixing bugs in UploadWizard as they come up, as well as bugs in the myriad other Multimedia projects. Please continue to bother the Multimedia team if and when things go wrong, we are always happy to help you, or at least point you in the right direction.
Here is a rough roadmap of where we need to go in the next few months:
# mw.Api.plugin.upload API to automatically detect what methods are available for the browser, take a File object or file input, and perform the upload ## Base upload API with simple API call, quick and dirty, with gadget proof-of-concept https://phabricator.wikimedia.org/T103397?workflow=create ## Expand to use File API where available https://phabricator.wikimedia.org/T103398 ## Expand to support stashing with appropriate continue-upload API https://phabricator.wikimedia.org/T103399 ## {{stretch}} Expand to use chunked uploading where available https://phabricator.wikimedia.org/T103398
# Tie together all of those things into an Upload object or similar in core, so we can handle it with relative ease in our mostly-UI extension ## Create Upload model API in core https://phabricator.wikimedia.org/T103413 ### Base functionality - use the new upload API to upload a file, configurable to use stash ### Base functionality - finish stash upload ### Base functionality - set file description page text for upload (to be used in finish-stash call, or in initial upload if no stash option passed in)
# Upload OOUI widget can then just use all of those things, and it can live in VE instead of having to be across a couple of extensions. ## Create upload widget in VE https://phabricator.wikimedia.org/T91717 {{epic}} ### Upload inspector ### File input widget in OOUI {{done}} ### Take file from widget, use upload API in core to stash ### Description/licensing/category form ### Emit finished upload from widget ## Use upload widget for inserting files into VE https://phabricator.wikimedia.org/T91717 (new task?) ### Add upload widget as above ### Use emitted file to construct thumbnail (file API?), caption (based on description) ## Drag-and-drop https://phabricator.wikimedia.org/T40031 ## Copy-paste https://phabricator.wikimedia.org/T39932
I don't want to derail your thread if this would be a tangent, but I was wondering if it is part of the plan to allow upload from local projects to Wikimedia Commons directly from the VisualEditor from other projects. It seems like the confusion over Commons is one of the biggest usability issues for the type of new editors VisualEditor is targeted at.
On Monday, June 22, 2015, Mark Holmquist mtraceur@member.fsf.org wrote:
Hi, Multimedians.
I've been talking with our new multimedia team, we're just getting to the point where we have a really good idea of where we want to go after a little while of doing work mostly on existing issues and refactoring efforts, and I have a small announcement to make.
In the next few months, we intend to work on pulling upload API logic into core, and writing a new interface for uploading files from VisualEditor. Our initial plan involved refactoring UploadWizard to a point where including it in VisualEditor would not be difficult, but our new plans include usability improvements that, in my opinion, would unnecessarily enmire our work. Our team will be submitting patches to OOJS-UI, MediaWiki Core, and VisualEditor itself in an effort to get this project off the ground, as well as tweaking configuration settings in mw-config and generally running around looking for code review.
Rest assured, we intend to maintain our commitment to fixing bugs in UploadWizard as they come up, as well as bugs in the myriad other Multimedia projects. Please continue to bother the Multimedia team if and when things go wrong, we are always happy to help you, or at least point you in the right direction.
Here is a rough roadmap of where we need to go in the next few months:
# mw.Api.plugin.upload API to automatically detect what methods are available for the browser, take a File object or file input, and perform the upload ## Base upload API with simple API call, quick and dirty, with gadget proof-of-concept https://phabricator.wikimedia.org/T103397?workflow=create ## Expand to use File API where available https://phabricator.wikimedia.org/T103398 ## Expand to support stashing with appropriate continue-upload API https://phabricator.wikimedia.org/T103399 ## {{stretch}} Expand to use chunked uploading where available https://phabricator.wikimedia.org/T103398
# Tie together all of those things into an Upload object or similar in core, so we can handle it with relative ease in our mostly-UI extension ## Create Upload model API in core https://phabricator.wikimedia.org/T103413 ### Base functionality - use the new upload API to upload a file, configurable to use stash ### Base functionality - finish stash upload ### Base functionality - set file description page text for upload (to be used in finish-stash call, or in initial upload if no stash option passed in)
# Upload OOUI widget can then just use all of those things, and it can live in VE instead of having to be across a couple of extensions. ## Create upload widget in VE https://phabricator.wikimedia.org/T91717 {{epic}} ### Upload inspector ### File input widget in OOUI {{done}} ### Take file from widget, use upload API in core to stash ### Description/licensing/category form ### Emit finished upload from widget ## Use upload widget for inserting files into VE https://phabricator.wikimedia.org/T91717 (new task?) ### Add upload widget as above ### Use emitted file to construct thumbnail (file API?), caption (based on description) ## Drag-and-drop https://phabricator.wikimedia.org/T40031 ## Copy-paste https://phabricator.wikimedia.org/T39932
-- Mark Holmquist Lead Engineer, Multimedia Wikimedia Foundation mtraceur@member.fsf.org javascript:; https://wikimediafoundation.org/wiki/User:MHolmquist
On 22 June 2015 at 16:05, Dominic Byrd-McDevitt < dominic.byrd-mcdevitt@wikidc.org> wrote:
I don't want to derail your thread if this would be a tangent, but I was wondering if it is part of the plan to allow upload from local projects to Wikimedia Commons directly from the VisualEditor from other projects.
It is.
It seems like the confusion over Commons is one of the biggest usability issues for the type of new editors VisualEditor is targeted at.
Agreed. We're going to have to be careful to make everything as clear as possible to users in very few words (because we have a limit of ~10–15 before users will ignore it). A worthy challenge for our designers. :-)
J.
This all sounds great. :-)
Where in this new process could someone hook in a widget that catches attempts to upload proprietary formats, and sends the file behind the scenes to Internet Archive for transcoding?
SJ On Jun 22, 2015 1:27 PM, "Mark Holmquist" mtraceur@member.fsf.org wrote:
Hi, Multimedians.
I've been talking with our new multimedia team, we're just getting to the point where we have a really good idea of where we want to go after a little while of doing work mostly on existing issues and refactoring efforts, and I have a small announcement to make.
In the next few months, we intend to work on pulling upload API logic into core, and writing a new interface for uploading files from VisualEditor. Our initial plan involved refactoring UploadWizard to a point where including it in VisualEditor would not be difficult, but our new plans include usability improvements that, in my opinion, would unnecessarily enmire our work. Our team will be submitting patches to OOJS-UI, MediaWiki Core, and VisualEditor itself in an effort to get this project off the ground, as well as tweaking configuration settings in mw-config and generally running around looking for code review.
Rest assured, we intend to maintain our commitment to fixing bugs in UploadWizard as they come up, as well as bugs in the myriad other Multimedia projects. Please continue to bother the Multimedia team if and when things go wrong, we are always happy to help you, or at least point you in the right direction.
Here is a rough roadmap of where we need to go in the next few months:
# mw.Api.plugin.upload API to automatically detect what methods are available for the browser, take a File object or file input, and perform the upload ## Base upload API with simple API call, quick and dirty, with gadget proof-of-concept https://phabricator.wikimedia.org/T103397?workflow=create ## Expand to use File API where available https://phabricator.wikimedia.org/T103398 ## Expand to support stashing with appropriate continue-upload API https://phabricator.wikimedia.org/T103399 ## {{stretch}} Expand to use chunked uploading where available https://phabricator.wikimedia.org/T103398
# Tie together all of those things into an Upload object or similar in core, so we can handle it with relative ease in our mostly-UI extension ## Create Upload model API in core https://phabricator.wikimedia.org/T103413 ### Base functionality - use the new upload API to upload a file, configurable to use stash ### Base functionality - finish stash upload ### Base functionality - set file description page text for upload (to be used in finish-stash call, or in initial upload if no stash option passed in)
# Upload OOUI widget can then just use all of those things, and it can live in VE instead of having to be across a couple of extensions. ## Create upload widget in VE https://phabricator.wikimedia.org/T91717 {{epic}} ### Upload inspector ### File input widget in OOUI {{done}} ### Take file from widget, use upload API in core to stash ### Description/licensing/category form ### Emit finished upload from widget ## Use upload widget for inserting files into VE https://phabricator.wikimedia.org/T91717 (new task?) ### Add upload widget as above ### Use emitted file to construct thumbnail (file API?), caption (based on description) ## Drag-and-drop https://phabricator.wikimedia.org/T40031 ## Copy-paste https://phabricator.wikimedia.org/T39932
-- Mark Holmquist Lead Engineer, Multimedia Wikimedia Foundation mtraceur@member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJViG6mAAoJEEPl+wghkjzxdicQALMoOspVSWENBCJ65WB+HIWy FNMgHjucR0EddYz/GA6fCca/Lxi22N/ZmDOAPIuce8hDv6roJgq3pI2hcDMF9Ugw szN6NX/T0Se8I7gHQ4ypDh+y+SdxLrpaRXIhFbrgtPTUXbiyDx4e2IK4BvQ608yG jVMV/pF27QVHP9Ovv3Jai+6qg5zwfNYzudfUktPh2JeGLWfW7QoX5eqxEQNP/xP4 EX7Aw3sTPB1ZClYEmznSWYLj4xP20qrGpikDhT6RhtnBMCqobahDK+92x1ZBHoRw N7+E2IKQzksGdwupqujifbDE/hzVRJI5x6mZQvSwdJBdyJQ1291IzWKgVfZIvcmg u9/OiP7fYz7gabhBeO1aqcwGp5zTMXNNaLnf2Zr77E18IbCoK6sAATz24btUkojj UcZVYKDB2m/SDtKaCzqnz4ZfeI0zmxd1KvdgJKoQ5wfDDKo9pjPuT0cFR0V3oF2N wmbRtmGZgBWzlTug4kuv0VPVJw1+j8jbHBKeULbB3tJi3XQ4oX7z/WjkeV4+RL9f 5CVG950hYma7EeofjDWVWxiKpBqs+w2GkSTzPklJl+Vzl4Ju4i3eYKJdMkVNlbPV qo1XayvSOG8FUqlhHxSFMcrBqZC9sL0V7sXPdQ/iAdVyL1A3Sf0IjGCDjjUEw3yj AbQDe+CMA6rQ/zo3JYKH =NHDV -----END PGP SIGNATURE-----
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
On 22 June 2015 at 16:25, Samuel Klein meta.sj@gmail.com wrote:
Where in this new process could someone hook in a widget that catches attempts to upload proprietary formats, and sends the file behind the scenes to Internet Archive for transcoding?
Ha. Well, that's an awkward policy question (and so my responsibility) wrapped inside a technical one (and so Mark's). :-)
I'm sure that such a hook could already be written for UploadWizard, though ideally it'd be done properly with a type handler; the transcoding effort, however, would mean that we would not store the original, so there'd need to be a challenging community discussion about whether retaining the original was important. It'd also be a pretty fragile system compared to doing the transcoding ourselves, without significant moral, ethical or legal gains as far as I can see, so I'd need to be convinced that it was worth spending so much effort on. But "inside it somewhere" isn't a great answer, I'm afraid. J.
I'm sure that such a hook could already be written for UploadWizard,
though ideally it'd be done properly with a type handler;
the transcoding effort, however, would mean that we would not store the
original, so there'd need to be a challenging community discussion about whether retaining the original was important.
The Internet Archive would store the original. Their mission is keeping originals available in perpetuity. Bidirectional links between the IA and commons pages could preserve the connection.
It'd also be a pretty fragile system compared to doing the transcoding
ourselves, without significant moral, ethical or legal gains as far as I can see,
Is doing it ourselves on the roadmap? IA has offered to do it now, providing a practical and temporal gain :)
But "inside it somewhere" isn't a great answer, I'm afraid.
A more specific answer would be nice, in case the people making use of such a hook are not core MW devs.
SJ
On Mon, Jun 22, 2015 at 6:06 PM, James Forrester jforrester@wikimedia.org wrote:
On 22 June 2015 at 16:25, Samuel Klein meta.sj@gmail.com wrote:
Where in this new process could someone hook in a widget that catches attempts to upload proprietary formats, and sends the file behind the scenes to Internet Archive for transcoding?
Ha. Well, that's an awkward policy question (and so my responsibility) wrapped inside a technical one (and so Mark's). :-)
I'm sure that such a hook could already be written for UploadWizard, though ideally it'd be done properly with a type handler; the transcoding effort, however, would mean that we would not store the original, so there'd need to be a challenging community discussion about whether retaining the original was important. It'd also be a pretty fragile system compared to doing the transcoding ourselves, without significant moral, ethical or legal gains as far as I can see, so I'd need to be convinced that it was worth spending so much effort on. But "inside it somewhere" isn't a great answer, I'm afraid.
That discussion already happened, see Commons:Project_scope#Must_be_an_allowable_free_file_format https://commons.wikimedia.org/wiki/Commons:Project_scope#Must_be_an_allowable_free_file_format and Commons:Requests_for_comment/MP4_Video https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/MP4_Video - there are strong objections to storing or transcoding originals files which have a proprietary format, at least in the current legal and policy landscape.
On 22 June 2015 at 18:32, Gergo Tisza gtisza@wikimedia.org wrote:
On Mon, Jun 22, 2015 at 6:06 PM, James Forrester <jforrester@wikimedia.org
wrote:
On 22 June 2015 at 16:25, Samuel Klein meta.sj@gmail.com wrote:
Where in this new process could someone hook in a widget that catches attempts to upload proprietary formats, and sends the file behind the scenes to Internet Archive for transcoding?
Ha. Well, that's an awkward policy question (and so my responsibility) wrapped inside a technical one (and so Mark's). :-)
I'm sure that such a hook could already be written for UploadWizard, though ideally it'd be done properly with a type handler; the transcoding effort, however, would mean that we would not store the original, so there'd need to be a challenging community discussion about whether retaining the original was important. It'd also be a pretty fragile system compared to doing the transcoding ourselves, without significant moral, ethical or legal gains as far as I can see, so I'd need to be convinced that it was worth spending so much effort on. But "inside it somewhere" isn't a great answer, I'm afraid.
That discussion already happened, see Commons:Project_scope#Must_be_an_allowable_free_file_format https://commons.wikimedia.org/wiki/Commons:Project_scope#Must_be_an_allowable_free_file_format and Commons:Requests_for_comment/MP4_Video https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/MP4_Video - there are strong objections to storing or transcoding originals files which have a proprietary format, at least in the current legal and policy landscape.
Exactly my point.
J.
On Tue, Jun 23, 2015 at 8:19 AM, James Forrester jforrester@wikimedia.org wrote:
On 22 June 2015 at 18:32, Gergo Tisza gtisza@wikimedia.org wrote:
On Mon, Jun 22, 2015 at 6:06 PM, James Forrester < jforrester@wikimedia.org> wrote:
On 22 June 2015 at 16:25, Samuel Klein meta.sj@gmail.com wrote:
Where in this new process could someone hook in a widget that catches attempts to upload proprietary formats, and sends the file behind the scenes to Internet Archive for transcoding?
Ha. Well, that's an awkward policy question (and so my responsibility) wrapped inside a technical one (and so Mark's). :-)
I'm sure that such a hook could already be written for UploadWizard, though ideally it'd be done properly with a type handler; the transcoding effort, however, would mean that we would not store the original, so there'd need to be a challenging community discussion about whether retaining the original was important. It'd also be a pretty fragile system compared to doing the transcoding ourselves, without significant moral, ethical or legal gains as far as I can see, so I'd need to be convinced that it was worth spending so much effort on. But "inside it somewhere" isn't a great answer, I'm afraid.
That discussion already happened, see Commons:Project_scope#Must_be_an_allowable_free_file_format https://commons.wikimedia.org/wiki/Commons:Project_scope#Must_be_an_allowable_free_file_format and Commons:Requests_for_comment/MP4_Video https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/MP4_Video - there are strong objections to storing or transcoding originals files which have a proprietary format, at least in the current legal and policy landscape.
Exactly my point.
What I mean is that the community rejects the idea of uploading files in proprietary formats, and transcoding them on our servers is blocked by scary patent licensing concerns for the most popular formats, so having the IA convert them would be a fairly significant legal gain that would make video uploading available to those users who are not video conversion experts.
Sounds like good stuff.
Is the plan to eventually use this new stuff on special:upload.
--bawolff On Jun 22, 2015 2:27 PM, "Mark Holmquist" mtraceur@member.fsf.org wrote:
Hi, Multimedians.
I've been talking with our new multimedia team, we're just getting to the
point
where we have a really good idea of where we want to go after a little
while
of doing work mostly on existing issues and refactoring efforts, and I
have
a small announcement to make.
In the next few months, we intend to work on pulling upload API logic
into core,
and writing a new interface for uploading files from VisualEditor. Our
initial
plan involved refactoring UploadWizard to a point where including it in
VisualEditor
would not be difficult, but our new plans include usability improvements
that,
in my opinion, would unnecessarily enmire our work. Our team will be
submitting
patches to OOJS-UI, MediaWiki Core, and VisualEditor itself in an effort
to get
this project off the ground, as well as tweaking configuration settings
in mw-config
and generally running around looking for code review.
Rest assured, we intend to maintain our commitment to fixing bugs in
UploadWizard
as they come up, as well as bugs in the myriad other Multimedia projects.
Please
continue to bother the Multimedia team if and when things go wrong, we
are always
happy to help you, or at least point you in the right direction.
Here is a rough roadmap of where we need to go in the next few months:
# mw.Api.plugin.upload API to automatically detect what methods are
available for the browser, take a File object or file input, and perform the upload
## Base upload API with simple API call, quick and dirty, with gadget
proof-of-concept https://phabricator.wikimedia.org/T103397?workflow=create
## Expand to use File API where available
https://phabricator.wikimedia.org/T103398
## Expand to support stashing with appropriate continue-upload API
https://phabricator.wikimedia.org/T103399
## {{stretch}} Expand to use chunked uploading where available
https://phabricator.wikimedia.org/T103398
# Tie together all of those things into an Upload object or similar in
core, so we can handle it with relative ease in our mostly-UI extension
## Create Upload model API in core
https://phabricator.wikimedia.org/T103413
### Base functionality - use the new upload API to upload a file,
configurable to use stash
### Base functionality - finish stash upload ### Base functionality - set file description page text for upload (to be
used in finish-stash call, or in initial upload if no stash option passed in)
# Upload OOUI widget can then just use all of those things, and it can
live in VE instead of having to be across a couple of extensions.
## Create upload widget in VE https://phabricator.wikimedia.org/T91717
{{epic}}
### Upload inspector ### File input widget in OOUI {{done}} ### Take file from widget, use upload API in core to stash ### Description/licensing/category form ### Emit finished upload from widget ## Use upload widget for inserting files into VE
https://phabricator.wikimedia.org/T91717 (new task?)
### Add upload widget as above ### Use emitted file to construct thumbnail (file API?), caption (based
on description)
## Drag-and-drop https://phabricator.wikimedia.org/T40031 ## Copy-paste https://phabricator.wikimedia.org/T39932
-- Mark Holmquist Lead Engineer, Multimedia Wikimedia Foundation mtraceur@member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJViG6mAAoJEEPl+wghkjzxdicQALMoOspVSWENBCJ65WB+HIWy FNMgHjucR0EddYz/GA6fCca/Lxi22N/ZmDOAPIuce8hDv6roJgq3pI2hcDMF9Ugw szN6NX/T0Se8I7gHQ4ypDh+y+SdxLrpaRXIhFbrgtPTUXbiyDx4e2IK4BvQ608yG jVMV/pF27QVHP9Ovv3Jai+6qg5zwfNYzudfUktPh2JeGLWfW7QoX5eqxEQNP/xP4 EX7Aw3sTPB1ZClYEmznSWYLj4xP20qrGpikDhT6RhtnBMCqobahDK+92x1ZBHoRw N7+E2IKQzksGdwupqujifbDE/hzVRJI5x6mZQvSwdJBdyJQ1291IzWKgVfZIvcmg u9/OiP7fYz7gabhBeO1aqcwGp5zTMXNNaLnf2Zr77E18IbCoK6sAATz24btUkojj UcZVYKDB2m/SDtKaCzqnz4ZfeI0zmxd1KvdgJKoQ5wfDDKo9pjPuT0cFR0V3oF2N wmbRtmGZgBWzlTug4kuv0VPVJw1+j8jbHBKeULbB3tJi3XQ4oX7z/WjkeV4+RL9f 5CVG950hYma7EeofjDWVWxiKpBqs+w2GkSTzPklJl+Vzl4Ju4i3eYKJdMkVNlbPV qo1XayvSOG8FUqlhHxSFMcrBqZC9sL0V7sXPdQ/iAdVyL1A3Sf0IjGCDjjUEw3yj AbQDe+CMA6rQ/zo3JYKH =NHDV -----END PGP SIGNATURE-----
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
On 22 June 2015 at 16:35, Brian Wolff bawolff@gmail.com wrote:
Sounds like good stuff.
Is the plan to eventually use this new stuff on special:upload.
Yes. But we were thinking not to do so at first, to avoid changing things too rapidly in core.
J.
The issue with inventing a custom upload tool is that it adds maintenance costs for the community and a sort of cognitive dissonance across uploaders. This new project will end up being as big as rewriting UploadWizard from scratch, *or* it will seriously risk ending up killed like the MobileFrontend custom upload tool. I'll avoid going into details because a poem can be written about each of your list points, especially "### Description/licensing/category form". The only possible escape I see is that any and all upload logic you create must be in core and used both by Special:Upload and Special:UploadWizard. T91717 must not and can't possibly be something done inside VisualEditor.
Nemo
On Tue, Jun 23, 2015 at 07:20:42AM +0200, Federico Leva (Nemo) wrote:
The only possible escape I see is that any and all upload logic you create must be in core and used both by Special:Upload and Special:UploadWizard. T91717 must not and can't possibly be something done inside VisualEditor.
We *are* putting upload logic in core. We just aren't using it in Special:Upload yet, until we have this new thing settled. And I'm pretty sure that T91717 *is* going to be done inside VisualEditor, at least in part. So...I'm not sure what you're trying to say, here.
multimedia@lists.wikimedia.org