2015 Community Wishlist Survey/Reading/es

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Voting has CLOSED! Thanks for your votes!

Indicar la calidad/confiabilidad de un artículo más claramente al lector[edit]

Actualmente, fuera de los esbozos y las plantillas agregadas por los editores, no hay forma de indicarle claramente al lector casual la calidad o confiabilidad de un artículo. Esto es un problema, dado el aumento de contenido promocional y similares (ver en:User:Doc_James/Paid_editing). Una solución sería: 1) activar en:Wikipedia:Metadata gadget para todos los lectores por defecto, 2) desarrollar una secuencia de comandos complementaria (tal vez invocada en demanda, accesible desde una barra de herramientas o encabezado) que mostraría información sobre la cantidad de seguidores, colaboradores principales y tal vez alguno de los valores de confianza que se han discutido en varios artículos académicos y 3) agregar una lista de verificación de artículos para problemas comunes (ver mi propuesta más abajo). --Piotrus (talk) 05:21, 10 November 2015 (UTC)

Votos[edit]

  1. Support Support--Shizhao (talk) 09:30, 1 December 2015 (UTC)
  2. Support Support This bit of literacy is incredibly important for readers - understanding that we have a process for creating content and quality Sadads (talk) 16:07, 1 December 2015 (UTC)
  3. Support Support Especially the number of watchers would be interesting and a decent simple measure of page quality. Is that number currently publicly available anywhere? Gap9551 (talk) 23:03, 1 December 2015 (UTC)
  4. Support Support #1 only as it gives an overview of the article's quality pretty succinctly. I don't think readers generally would care about the number of watchers or the other info. Stevie is the man! TalkWork 00:47, 2 December 2015 (UTC)
  5. Support Support--Manlleus (talk) 15:40, 2 December 2015 (UTC)
  6. Support Support -- SantiLak (talk) 10:47, 4 December 2015 (UTC)
  7. Support Support Halibutt (talk) 00:35, 5 December 2015 (UTC)
  8. Support Support --Yeza (talk) 16:56, 5 December 2015 (UTC)
  9. Support Support Zamaster4536 (talk) 12:54, 6 December 2015 (UTC)
  10. Comment Comment An interesting approach that could be investigated is providing automated metrics based on the age of the page, number of edits, number of contributors, shape of the distribution of number of edits by contributor and average size of edits by contributor, (c.f. xContribs), average age of words in the page, etc. This would be similar to the "factoids"/"in a nutshell" feature of OpenHub/Ohloh, e.g. https://www.openhub.net/p/mediawiki#factoids --Waldir (talk) 15:47, 8 December 2015 (UTC)
  11. Support Support Abyssal (talk) 16:49, 10 December 2015 (UTC)
  12. Support Support --Tgr (talk) 22:20, 13 December 2015 (UTC)
  13. Comment: (support) -- The user needs a simple (automated) facility to help them understand a significant number of issues (some listed above per Waldir) related to quality. When people ask me if they should trust Wikipedia, I try to remind them of how to assess trust in other areas of their life. This facility should seek to be an intelligent guide to trust; not a certification of correctness.
    This might include tool-tip like cautions of the more significant issues for the article. Such a system should recognize the age and number of editor templates already on the article. When this system is implemented, the current editor templates should be disabled for IP readers but still appear for IP editing and for logged-in users.
    Both the age and distribution distribution of references in the text affects current topics. However, the scoring must recognize that historical topics more than ~50 years old shouldn't discount quality because of non-current references.
    SBaker43 (talk) 20:02, 14 December 2015 (UTC)

Marco de trabajo amigable con los dispositivos móviles para las páginas de proyecto y portales con múltiples columnas[edit]

En muchos portales y wikiproyectos las páginas principales están diseñadas con cajas organizadas en varias columnas. Esto permite una distribución organizada y compacta de contenido relacionado (o sin relación) en grandes monitores de escritorio. Sin embargo, estos diseños desafortunadamente utilizan wikitablas como elementos estructurales en la mayoría de los casos y por tanto son intrínsecamente incompatibles con dispositivos pequeños. Esta es una experiencia de de-wiki, pero creo que la situación no es mucho mejor en otras wikis (ejemplos arbitrarios de portales con un desempeño pobre en dispositivos móviles: [1] [2] [3] [4] [5] [6];. Para probar su comportamiento en los dispositivos móviles, abre los enlaces en tu navegador y reajusta el ancho de la ventana a las dimensiones de un teléfono inteligente).

Hay muchas razones para estos pobres resultados. Además del hecho de que muchos portales fueron creados antes de la era de los dispositivos móviles, todavía sufrimos de la falta de un grupo de soluciones técnicas fácilmente comprensibles para crear páginas de portales o proyectos amigables con los dispositivos móviles sin la necesidad de usar técnicas complejas de CSS. Propongo, por tanto, desarrollar un grupo de herramientas, consistentes principalmente de clases de CSS en un sitio adecuado en el espacio de nombres MediaWiki y que por lo tanto estén disponibles para el uso común, con las siguientes propiedades:

  • Un conjunto flexible de clases CSS, separadas por estilo y posición de las cajas de contenido; los usuarios pueden agregar clases a los elementos de los portales y definir el estilo y ubicación al hacerlo.
  • Las cajas se pueden encapsular usando plantillas con parámetros, las que me parece son más conocidas a los usuarios wiki que el HTML plano.
  • Una vez aplicada a la página del portal o proyecto, la organización de las cajas se adaptaría automáticamente al tamaño del monitor, sin importar si se usa la interfaz estándar, la interfaz para dispositivos móviles o la aplicación Wikimedia.
  • Una documentación detallada, incluyendo casos de uso, complementaría este grupo de herramientas; un usuario wiki promedio debería ser capaz de crear una página de portal amigable con dispositivos móviles y navegadores de escritorio.
  • Tarea extra: Activar técnicas modernas de CSS en el espacio de nombres de portales, como por ejemplo consultas de medios y cualquier otra cosa que sea útil; los usuarios técnicamente hábiles podrían mejorar la experiencia en el escritorio y en los dispositivos móviles usando esta función.

MisterSynergy (talk) 20:01, 11 November 2015 (UTC)

Votos[edit]

  1. Support Support MisterSynergy (talk) 09:08, 30 November 2015 (UTC)
  2. Support Support --g (talk) 15:13, 1 December 2015 (UTC)
  3. Not supportive, mostly because portals should more likely be deprecated as out-of-date and generally of poor quality. We are not hearing from many projects that use them, and they have been useless to readers for many years on (at least) several of the large Wikipedias. A bit of history: on Enwiki, portal creation became popular for a period because it was easy to develop a 'featured portal', and evidence of having contributed "featured content" was a relatively quick way to becoming an administrator. Those portals were then promptly ignored by their creators, and most have not been revised in years. While the motivation may have been different on other projects, it seems they are essentially historical artifacts today. Risker (talk) 23:02, 1 December 2015 (UTC)
  4. Comment Comment I agree with Risker that portals should probably be decommissioned as they are hulks nobody has the time to work on, and I don't think they get much reader attention anyway. The true portals are the main subject articles themselves, because those are what people find when they search. WikiProjects, however, are the "portals" through which some editors go to find out how to help with particular subjects. I wouldn't oppose efforts to make them mobile-friendly, but I think the way to go is to provide a way of having alternative display code for mobile devices, rather than changing the designs of existing WikiProject pages. At any rate, many WikiProjects are short-staffed and will consider mobile access a low priority in my estimation. Stevie is the man! TalkWork 12:32, 2 December 2015 (UTC)
    I disagree with deprecating portals. They are a great way to show interesting things to readers. I have developed several sports portals in Spanish Wikipedia, with heavy use of random sections. Hey, nitable competitors appear on their birthdays!
    The problem with portals, other than lack of editors, is that we need to writhe the summaries of articlesvand update them manually. A nice tool would be insetion of page sections, therefore we could just insert the zero section. --NaBUru38 (talk) 04:05, 13 December 2015 (UTC)
    I would support some portal-like features built into main subject articles. The current separated portals are hulks that very few visit (I've looked at pageview stats) and almost nobody has the time to maintain. If we have to keep portals around, they need to be "advertised" better from main subject articles. Stevie is the man! TalkWork 17:29, 13 December 2015 (UTC)
  5. Support Support--Manlleus (talk) 15:41, 2 December 2015 (UTC)
  6. Support SupportBeleg Tâl (talk) 17:02, 2 December 2015 (UTC)
  7. Oppose Oppose - Do many readers/editors using mobile phones want this? I've just looked at some of the above examples using a small laptop (large tablet) size screen and had no problems; the material may not have been laid out quite as neatly as on a larger screen, but you can't have everything. If this went ahead then either (1) existing projects/portals would need to be converted to the new system or (2) we would have a mix of projects/portals using the old and new systems - both would increase complexity for editors. Many projects have some tabbed pages that are pointless (or worse). DexDor (talk) 20:02, 9 December 2015 (UTC)
  8. Support Support A nice first step would be optional linebreaks. If a row has two columns with an optional linebreak, the two boxes would appers side by side if the screen is wide, and top to bootom if the screen is narrow. --NaBUru38 (talk)

Lista de lectura[edit]

Algunos lectores (pero normalmente no los editores) encuentran un artículo interesante y les gustaría leerlo después, tal vez porque no tienen suficiente tiempo en ese momento. ¡Sería muy bueno si pudieran agregarlo a su lista de lectura de forma que no lo olviden! Se que hay muchas formas de agregar marcadores a páginas en internet (tanto en el navegador como en proveedores de servicios en línea) pero es una idea que vale la pena considerar. 4nn1l2 (talk) 10:28, 10 November 2015 (UTC)

Votos[edit]

  1. Support Support 4nn1l2 (talk) 02:59, 30 November 2015 (UTC)
  2. Support Support בנימין (talk) 07:37, 30 November 2015 (UTC)
  3. Support Support Ldorfman (talk) 22:23, 30 November 2015 (UTC)
  4. Support Support Alleycat80 (talk) 09:04, 1 December 2015 (UTC)
  5. Support Support --Shizhao (talk) 09:31, 1 December 2015 (UTC)
  6. Support Support -- AvatarFR (talk) 13:30, 1 December 2015 (UTC)
  7. Support Support simple: non-watching watchlists. --Purodha Blissenbach (talk) 14:32, 1 December 2015 (UTC)
  8. Support Support --Martinligabue (talk) 15:04, 1 December 2015 (UTC)
  9. Support Support -- reader focused watchlists? Or something that entices these readers to engage the already available system, but make that list more visible? Public reading lists (maybe the books extension reoriented towards IPS?) could be a good social media tool as well, Sadads (talk) 16:09, 1 December 2015 (UTC)
  10. Support Support --Urbanecm (talk) 17:46, 1 December 2015 (UTC)
  11. Support Support --Wesalius (talk) 19:10, 1 December 2015 (UTC)
  12. Support Support Jules78120 (talk) 19:57, 1 December 2015 (UTC)
  13. Oppose Strongly oppose --Usien6 (talk) 20:52, 1 December 2015 (UTC) // Can be designed by the community as a "gadget" or browser extension: no reason to burden WMF with it. By the way, Safari is already shipped with such feature with the bonus of off-line caching and cross-client syncing. Actually, every major browser (and most of the minors...) have the bookmarking feature, which does the job pretty well. Seriously, guys...
  14. Oppose Oppose Redundant to the bookmark functionality in your browser and does not improve wiki content or editor productivity. And if you're on a public computer, improvise! A piece of paper, writing on your hand, sending an email to yourself, adding it to a wiki page/watchlist are all easy workarounds. MER-C (talk) 20:58, 1 December 2015 (UTC)
  15. Oppose Oppose Not related to improving and maintaining wiki projects. Easily done by browser, as mentioned before. Gap9551 (talk) 23:05, 1 December 2015 (UTC)
  16. Support Support Helder 23:40, 1 December 2015 (UTC)
  17. Comment Comment If someone wants to develop a gadget or extension for this, that would be all right, but I don't see this going into the core wiki code. Also, Wikipedians can create a reading list on one of their user pages, prettied up using the Todo template if they like. Stevie is the man! TalkWork 12:43, 2 December 2015 (UTC)
  18. Support Support Why not? Regards, Kertraon (talk) 13:19, 2 December 2015 (UTC)
  19. Support Support--Manlleus (talk) 15:41, 2 December 2015 (UTC)
  20. Support Support--MisterSanderson (talk) 01:00, 3 December 2015 (UTC)
  21. Support Support YBG (talk) 06:36, 3 December 2015 (UTC)
  22. Support Support Rzuwig 10:57, 3 December 2015 (UTC)
  23. Support Support Orbwiki107 (talk) 17:24, 3 December 2015 (UTC)
  24. Support Support SantiLak (talk) 10:47, 4 December 2015 (UTC)
  25. Support Support Chenspec (talk) 21:16, 4 December 2015 (UTC)
  26. Support Support Lester לסטר (talk) 18:09, 5 December 2015 (UTC)
  27. Support Support Zamaster4536 (talk) 12:54, 6 December 2015 (UTC)
  28. Oppose Oppose per opposes above. Don't add unnecessary clutter to readers screens. DexDor (talk) 20:07, 9 December 2015 (UTC)
  29. Support Support Alkamid (talk) 22:33, 13 December 2015 (UTC)


== Subpáginas: Eliminar los enlaces a las páginas superiores

Wikilibros usa subpáginas para estructurar los libros en subpáginas. La Wikiversidad hace lo mismo con los cursos y las lecciones. Cada subpágina incluye una lista de enlaces a las páginas superiores automáticamente. A pesar de eso los autores agregan opciones para navegar entre los diferentes capítulos y páginas de contenido usando plantillas de navegación. En esos casos los usuarios ven los enlaces a las páginas superiores así como la barra de navegación. Por ejemplo: b:en:Geometry for Elementary School/Introduction. Preferiría eliminar los enlaces automáticos si hay una barra de navegación. La información duplicada distrae a los usuarios.

Usuarios: Wikilibros, Wikiversidad y otros proyectos que usan subpáginas. Situación actual: No es posible ocultar los enlaces a las páginas superiores. Solución: Agregar una palabra mágica __NOANCESTORLINK__ o algo parecido. -- Juetho (talk) 10:45, 18 November 2015 (UTC)

Votos[edit]

  1. Support Support - This would be useful occasionally on English Wikipedia, too - for example, there is no reason for Talk:P/poly (the talk page of the P/poly complexity class) to link to Talk:P (the article being about the letter). עוד מישהו Od Mishehu 21:21, 30 November 2015 (UTC)
  2. Support Support, and only with the magic word or a comparable feature that works page-by-page. Having it added automatically by algorithm (e.g. "if the page displays X, don't display the ancestor page") would risk its omission by a false positive, but merely making it suppressible page-by-page wouldn't be a problem. If a project needs to remove ancestor links from a whole batch of pages, it can run a bot to add the magic word to the pages in question. Nyttend (talk) 21:49, 30 November 2015 (UTC)
  3. Support Support using magic words, with a wiki-by-wiki default setting variable, for wikis like Wikiversity where these links tend to be unhelpful. --YodinT 02:43, 1 December 2015 (UTC)
  4. Support Support --Shizhao (talk) 09:31, 1 December 2015 (UTC)
  5. Oppose Oppose or make it a user preference option with appropriate wiki-wide default. I !@:#\ things being too different between wikis I am using. --Purodha Blissenbach (talk) 14:30, 1 December 2015 (UTC)
  6. Oppose Oppose --Usien6 (talk) 20:55, 1 December 2015 (UTC)
  7. Oppose Oppose Helder 23:40, 1 December 2015 (UTC)
  8. Support Support per Nyttend. Stevie is the man! TalkWork 12:49, 2 December 2015 (UTC)
  9. Oppose Oppose -- Overall wiki navigation should remain consistent throughout. Navigation templates can be redesigned or moved to resolve this issue. -- Dave Braunschweig (talk) 22:20, 2 December 2015 (UTC)
  10. Support Support--MisterSanderson (talk) 01:00, 3 December 2015 (UTC)
  11. Support Support Juetho (talk) 07:32, 8 December 2015 (UTC) -- I dont't want a wiki-wide way to suppress these small links. I only want a page-by-page option set by an author manually.