Community Wishlist Survey 2020/Wikiversity

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2020
Wikiversity
11 proposals, 61 contributors, 161 support votes
The survey has closed. Thanks for your participation :)



ContentTranslation for Wikiversity

  • Problem: the tool ContentTranslation actually only works on Wikipedia. It would be useful on Wikiversity for translating pages for one language to an other.
  • Who would benefit: contributors and students
  • Proposed solution: install ContentTranslation on Wikiversity
  • More comments:
  • Phabricator tickets:
  • Proposer: Lionel Scheepmans ✉ Contact French native speaker, sorry for my dysorthography 18:30, 29 October 2019 (UTC)[reply]

Discussion

Voting

Simple structured input forms

  • Problem: Information is often far better input via a form rather than editing wikimarkup (like this page). Especially when either A) the same fields will be repeatedly required or B) when new users are involved. New users are often put off my wikimarkup, even when templates and preloaded text is used (example). This leads to projects and affiliates often using google forms in stead then copy-pasting the information to wiki (example). Currently a small number of outstanding issues remain on the Pageforms Extension that could address this by making an in-house, general-purpose form tool with structured inputs.
  • Who would benefit:
Example use case in wikiversity: It'd be great to be able to use this peer review submission form rather than the current system (peer reviews are submitted via this google form, which deposits them to a google spreadsheet like this, where they're manually copied to the relevant article talkpage, and noted down on this tracking table, and maybe at some point will have their metadata added to Wikidata). Similarly useful for submitting articles in stead of this google form.
  • Proposed solution: A way of having structured forms to create and edit specific wiki pages that always have the same layout/format. Particularly useful capabilities listed below with submitting peer reviewer comments as the worked example:
Inputs:
  1. Free text box for content to be added to page section or inside template (e.g. the content of a peer review, or a faculty webpage)
  2. Dropdown list or autocompleted textbox of predefined options to pick from:
    1. Populated/autocompleted from wikidata like when typing into wikidata field (e.g. to pick affiliation from wikidata-listed organisations)
    2. Populated/autocompleted from category (e.g. to specify which article is being reviewed)
    3. Hardcoded list (e.g. whether to have identity open or embargoed)
    4. Tickbox that when clicked will add set text (e.g. declaration of no competing interests)
  3. Ability upload of a file (e.g. pdf of peer reviewer comments/annotations)
  4. Distinguish between required and optional fields
  5. Ability to show additional fields based on what has previously been picked (e.g. if user states that they wish have their identity embargoed, box appears to ask them to provide description of credentials, or makes the credentials box required rather than optional)
  6. Ability to pre-fill some of those fields using info in the URL (e.g. when link is sent via email to potential peer reviewer for specific article)
  7. Submission button to convert those chosen options into the required wikitext and save to the specified page (e.g. the peer review page).
  8. Option to edit which fields are displayed depending on whether the submitting user is listed in a template, or on wikidata as either the submitting author
Outputs:
  1. Add text to page (e.g. the content of a peer review)
  2. Create new page (e.g. when the first per review is submitted, create the talkpage)
  3. Replace text in a specific page section or template
  4. Update wikidata item (e.g. add {{{}}})
  5. Add file to commons or locally
  6. Create new wikidata item (e.g. if reviewer provides ORCID, but wikidata item for them doesn't yet exist)
  7. Add information to the user's hidden information (e.g. if they had not previously added an email address to their account, allow them to do so via the form, but eventually other info such as committed identity)
Although it'd be useful to have as many of these functions as possible, I've tried to order them from most necessary to most optional.

Discussion

Unfortunately, this extension would require much more work to be deployable on WMF than it's assumed. We can't dedicate this amount of time to it because we will have other projects to work on next year. Regardless, thank you for participating in our survey! MaxSem (WMF) (talk) 00:58, 19 November 2019 (UTC)[reply]

@MaxSem (WMF): Is there scope for a stripped down version to be implemented that don't include the abilities that cause security issues? The main elements that would be the most useful are:
  • Saving text to a page
  • Updating a wikidata item
  • Creation of a new page
  • Upload of a file
via any kind of structured form that can have e.g.:
  • Dropdown lists populated from wikidata or categories
  • Dropdown lists populated from set of options
  • Presentation of additional options based on those previously entered
  • Free text field
T.Shafee(Evo﹠Evo)talk 02:20, 19 November 2019 (UTC)[reply]
T.Shafee(Evo﹠Evo), hello! We have discussed this as a team, and we think that this wish can be unarchived, if it has some changes. First, the wish should be rewritten to not imply that it will include deploying Page Forms. Second, we propose a change of title to something like 'provide a form to create new articles for wiki journal structures.' If these changes are made, the wish will be more flexible and manageable for us. Please make these changes before tomorrow at 18:00 UTC (which is when voting begins). Thank you! --IFried (WMF) (talk) 21:25, 19 November 2019 (UTC)[reply]
Ok, I'll edit up this page and move to a different tile to focus on the specific use case and requested capabilities rather than the extension itself. I'll add a link to this oldid so that people can see the earlier version if they wish. T.Shafee(Evo﹠Evo)talk 04:56, 20 November 2019 (UTC)[reply]
Initial submission titled "Extension:Page forms on WMF servers", see this oldid. T.Shafee(Evo﹠Evo)talk 01:51, 21 November 2019 (UTC)[reply]
  • Just to be clear, this proposal is about installing the Cargo extension on Wikiversity, right? (As opposed to SemanticMediaWiki, which has been rejected already.) Or is it about making PageForms work without Cargo and with a different kind of "backend"? Nemo 09:13, 22 November 2019 (UTC)[reply]

I've updated the application to focus on specific capability set rather than any particular tool to achieve those capabilities. T.Shafee(Evo﹠Evo)talk 01:51, 21 November 2019 (UTC)[reply]

Voting

Ability to change the license listed at the bottom of the page

  • Problem: The license at the bottom of each pages is the same site wide. This is less appropriate for sites that may have different licensing for different pages. This wikiversity example, or wikisource example are both licnesesd CC-BY, yet the bottom of the page still claims that they are CC BY-SA (No idea what the page metadata says).
  • Who would benefit: Those making any pages that aren't CC BY-SA
  • Proposed solution: Simply allow display of different licesnse (and altered page metadata) based on a template or category.
  • More comments:
  • Phabricator tickets:
  • Proposer: T.Shafee(Evo﹠Evo)talk 08:24, 9 November 2019 (UTC)[reply]

Discussion

  • Who should be making the decision about which license to use on a page, and what criteria should they utilize? Libcub (talk) 08:42, 22 November 2019 (UTC)[reply]
    Through it might vary for other projects, I'd envisage that in the case of wikisource, it's be decided based on the license of the original source, and in the case of wikiversity, it'd be decided by agreement of all the contributors (after which additional contributors would be editing under that new license). T.Shafee(Evo﹠Evo)talk 09:17, 22 November 2019 (UTC)[reply]
  • Individual users cannot have the power to change the license of the content. It seems more appropriate to make a separate project with the required license, if interested. Pages can have multiple licenses while being CC-BY-SA (as long as the other licenses or copyright statuses are more permissive, of course). Nemo 09:20, 22 November 2019 (UTC)[reply]

Voting

Export published WikiJournal articles to DOCX or PDF

  • Problem: After a WikiJournal paper has been accepted for publication, it requires a labour-intensive process to customize the layout, formatting and front page. This process is currently done manually and will become an impediment as the journal scales up and accepts more submissions. The previous PDF generator has been offline for a while.
  • Who would benefit: WikiJournal editors in particular, and anyone who prefers to read content in a PDF format (including Wikibooks).
  • Proposed solution: The current process becomes automated upon article acceptance.
  • More comments: Related: Wikibooks#EPUB_generation
  • Phabricator tickets:
  • Proposer: OhanaUnitedTalk page 14:40, 1 November 2019 (UTC)[reply]

Discussion

  • Support PDF generation. I'm not sure about DOCX, but certainly exporting PDFs is a very common feature of academic publishing. —Justin (koavf)❤T☮C☺M☯ 19:39, 2 November 2019 (UTC)[reply]
  • This is a good point, there are other projects and subcommunities in Wikiversity, who may benefit. We used to publish an educative magazine on Czech Wikiversity. Juandev (talk) 08:36, 4 November 2019 (UTC)[reply]
  • Would this feaure allow export of any wiki page? I think that it would be useful for offline use of articles from other wikis. If a reader just copies text from a page into a word processor, it is likely that the resulting document won't have the correct attribution. If the wiki offers a word processor friendly export, we can facilitate correct offline reuse. The format need not be Docx, but should be somthing that opens easily in Microsoft Word, Google Docs, Libre Office or elsewhere. AlasdairW (talk) 23:32, 7 November 2019 (UTC)[reply]
  • Docx is useless and impossible to support. ODT is perfectly fine and was supported by the mw:Extension:Collection (as developed by PediaPress) before the WMF destroyed it a few years ago. Nemo 09:21, 22 November 2019 (UTC)[reply]

Voting

Export pages as JATS-compliant XML

Discussion

Voting

Autopopulate userpage starting info from ORCID

  • Problem: When new users who already have an ORCID account create a Wikimedia account, their userpage is initially blank despite useful info existing to populate it
  • Who would benefit: New Wikiversity users commonly have ORCIDs and also commonly edit under their real names. This may also be relevant to that subsection of the Wikipedia community who also does
  • Proposed solution: When new users sign up to Wikiversity, ask if they have an orcid account and whether they would like it to be used to initially populate their new userpage. Various levels of integration are possible, but may also be an initial step towards ORCID also listing wikimedia contribution summary stats or featured articles in ORCID profiles. See also Meta:ORCID.
  • More comments:
    • Option 1) Just auto add an {{authority control}} template based on the orcid
    • Option 2) Copy over basic information from ORCID to populate the userpage
    • Option 3) Add/transclude their scholia profile to the userpage
    • Option 4) Allow users to verify their ORCID and associate it with their Wikimedia identity
    • Option 5) Allow users to log in using their ORCID profile
  • Phabricator tickets: (T136943 for option 4/5)
  • Proposer: T.Shafee(Evo﹠Evo)talk 10:42, 29 October 2019 (UTC)[reply]

Discussion

Voting

Inclusion of interactive Dimensions, Altmetrics, Crossref badges in pages

Discussion

Voting

Sample skins for presentations

There is often a small screen facing the presenter, and a big screen facing the audience; the presenter's screen may show slide notes and timing information
  • Problem: Currently, if you want to upload a presentation to Wikimedia, you convert it to a PDF and put it on Commons. This format is not easily modifiable, reusable, or accessible. If you want to display Mediawiki pages on a big screen, you can use the F11 key to fullscreen the browser content (try it now; hit F11 again to return). But that leaves the screen cluttered with Mediawiki sidebars, and there are no convenient navigation functions for switching between slides. There are users who create their presentation on Wikiversity and try to create their own presentation skin to display it. The skins are not perfect, due to the lack of CSS knowledge, and thus cannot be used in main namespaces.
  • Who would benefit:
    • Anyone wanting to give a slideshow talk, or reuse wiki content in a talk, or vice-versa. Slideshow skins would provide easier way to use Wikiversity for lectures. Wikiversity users have a particular interest in putting lecture slides online.
    • Everybody interested in the topic of the slideshow talk. Presentations placed on Wikiversity as markup provide more opportunities for collaboration and learning than presentations left in PDF on Wikimedia Commons. Collaborative creation of slideshow content would be much easier.
  • Proposed solution: A Mediawiki implementation of a web-based slideshow, allowing wiki pages to be used as fullscreen presentation slides. A good addition would be a download/export function to get a flat file containing the presentation. Ideally, there should be second screen capability, so that the presenter can also see a countdown timer and a short set of point-form notes per slide. ~Five sample skins in CSS for lectures/presentations, which might be attached to a special namespace, or selected by individual users wanting to use Wikiversity for presentations, would provide choice in styling.
  • More comments: Mediawiki obviously already renders in browsers, so this might be a fairly easy way to provide a really useful functionality. It could also attract users and content to Wikiversity.
    • Example: v:en:User:Juandev/CEE19/Structured Data on Wikimedia Commons is handled by a skin in v:en:User:Juandev/monobook.css
    • The same format could be used to display an academic poster, made with existing Wikiversity tools, on a screen. SVG already does this well, but less wiki-reusably.
    • The W3C has a (flat-file) format and freely-licensed implementation, HTML Slidy, which might be useful. It exports/is XML; PDF export might also be useful, and might overlap with the article-export proposal.
    • I'm not sure whether it would be appropriate to do this with a skin (skin experts, I'd welcome your comments). If a skin with slide-navigation functions would be OK, then we could do the rest with a template taking, as parameters, a list of the wiki pages/sections to be used as slides, and displaying a slide-thumbnail menu with switch-skin links. Any page with that template would then become a slideshow. Perhaps second-screen capability could be done with a popup?
  • Phabricator tickets:
  • Proposer: Juandev (talk) 07:36, 4 November 2019 (UTC) and HLHJ (talk) 23:45, 3 November 2019 (UTC) (merged proposal)[reply]

Discussion

Juandev, if I've understood you correctly, this is similar to the #Wiki-based slideshows/posters proposal. Would a merge be OK? If you want to merge it, please do. HLHJ (talk) 00:59, 8 November 2019 (UTC)[reply]

Well, I am not sure. Poster proposal is about having one simple skin for all Wikiversity pages, this colls for multiple skins. Maybe you can merge it, but ask for more skins, from which the person willing to present directly a Wikiversity page could change. Like we have more skins in our preferences for hole wiki (Monobook, Vector, chicken). I wonder if this is an extension, it could work pretty well for every wiki project and e.g. Wikipedia presentation would benefit out of it also. Juandev (talk) 10:01, 10 November 2019 (UTC)

Thanks to Bawolff for assessing the technical difficulty ("at a glance sounds do-able and an apprppriate difficulty level for community wishlist"). HLHJ (talk) 18:37, 9 November 2019 (UTC)[reply]

Juandev, MusikAnimal (WMF), I have merged from Community Wishlist Survey 2020/Archive/Wiki-based slideshows/posters as requested. Comments welcome, especially if I have misunderstood you, Juandev. HLHJ (talk) 02:11, 20 November 2019 (UTC)[reply]

I'm wondering if multiple separate skins are really needed for styling, or if a bit of supplementary custom CSS would do. Something like Wikipedia:Help:User style and maybe Wikipedia:Help:HTML in wikitext. Swapping background images, heading and text styles would cover pretty much everything a lot of people do to their slides, so several little "slide-styles" could quickly be written, with an easy UI for picking one. Mini slide-styles, modifying a single full slideshow-skin, seems as though it might be easier than multiple full skins. Expert opinion welcome. HLHJ (talk) 02:20, 21 November 2019 (UTC)[reply]

Voting

PROGRESS REPORT Feature

  • Problem: Need a Performance related Feature for both The Reader's & Author's.
  • Who would benefit: The Wikiversity users , course authors .all the learning community that Wikimedia Foundation project can support.it will certainly give a boost to fulfill Wikiversity & the wikimedias goal.
  • Proposed solution: To implement this features we can take a approach similar to moodle's ."Activity completion". MOODLE is in open licence.
  • More comments: It is obvious that it can be implemented for the reader's,cause Wikiversity already have many officialy completed 'resources' https://en.m.wikiversity.org/wiki/Category:Completed_resources

like this one Electric_Circuit_Analysis or this. Introduction_to_Computers

At first we should create a MOODLE style "layout".for the current "Learn by doing" courses. The current policy permit's it cause it isn't about 'conventional courses'.It's actually the current Wikiversity style learning only with a technical 'layout'.

Wiki course authors will have the options to choice 'Course formats' . admin will have privilege to limit 'course formats' when necessary .

After getting a 'layout' it should be easy to implement the 'progress report' features.

Discussion

I think this is hardly applicable at this stage of Wikiversity when there is not a uniform method or platform for course creating. I wonder that this solution would also need some programming on the site of Wikiversity like creating course platform, which will have a stable format and which will allow developers to plug other features like progress report. Juandev (talk) 21:46, 10 November 2019 (UTC)[reply]

Thanks @Juandev:

, to raise this valid question . Actually that's the reason why I advised to implement a MOODLE style "layout" first . Then we will be 1 step closer to get a "uniform method or platform for course creating". Hope you got your answer .THANKS.--MASUM THE GREAT (talk) 09:44, 27 November 2019 (UTC)[reply]

Voting

Transcluding Wikipedia complete article or section on wikiversity courses

Discussion

  • I have mixed feelings about this. On the one hand, it is nice to have the most up to date information from Wikipedia in Wikiversity. But on the other hand, if the Wikipedia article or section is restructured, rewritten for a more expert audience, or otherwise changed dramatically, it may no longer be the best fit for a Wikiversity course. Libcub (talk) 08:40, 22 November 2019 (UTC)[reply]
The extension also allows to transclude a specific version of an article, rather than the most recent one. Sophivorus (talk) 10:07, 22 November 2019 (UTC)[reply]

Voting

Speed reading video option for wikiversity MOOCs

  • Problem: Some MOOCs in French Wikiversity include videos (example), but the video player does not allow users to change the playback speed. Watching at a faster playback speed saves time.
  • Who would benefit: Video viewers on Wikiversity
  • Proposed solution: Updating the Wikimedia video player
  • More comments:
  • Phabricator tickets: T174393
  • Proposer: Lionel Scheepmans ✉ Contact French native speaker, sorry for my dysorthography 01:03, 29 October 2019 (UTC)[reply]

Discussion

I like this idea. I prefer to watch talking-heads informative videos at ~double speed. Slowly trawling through a video is very frustrating, especially when you are just trying to find one fact. Adjustable playback speed would benefit other projects, too; if this proposal therefore gets turned down as out-of-scope for this year, please to re-nominate it next year. I have boldly polished the English, please revert or modify if I have misunderstood you. HLHJ (talk) 21:53, 3 November 2019 (UTC)[reply]

Definitely a good idea! Juandev (talk) 08:31, 4 November 2019 (UTC)[reply]

The new video.js beta player does have the ability to change playback speed. It would however require some software change to expose that feature conditionally (showing it all the time is not going to be efficient on most of our other sites. Oh btw, depending on your browser, it is sometimes possible to right click the video and adapt the playback speed in that way. —TheDJ (talk • contribs) 13:21, 4 November 2019 (UTC)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2020/Wikiversity&oldid=19607197"