Wikimedia Meta-Wiki

Khảo sát Mong muốn Cộng đồng 2015/Đọc

< Community Wishlist Survey 2015
This page is a translated version of the page Community Wishlist Survey 2015/Reading and the translation is 100% complete.
Other languages:

Tạo chất lượng/độ tin cậy của một bài báo rõ ràng hơn cho người đọc

Hiện nay, vẫn còn sơ khai bên ngoài và người dùng thêm-mẫu, không có cách nào để làm cho chất lượng / độ tin cậy của một bài báo rõ ràng cho người đọc bình thường. Đây là một vấn đề, do tăng thư rác thấm và như vậy (xem en:User:Doc_James/Paid_editing). Một giải pháp sẽ được cho phép bởi 1) en:Wikipedia:Metadata gadget cho tất cả độc giả theo mặc định, 2) phát triển một kịch bản bổ sung, trong đó cũng sẽ hiển thị (có thể theo yêu cầu, truy cập từ một thanh công cụ hoặc nhóm) thông tin về số lượng quan sát, đóng góp lớn, và có lẽ là một trong những rất nhiều sự tin tưởng-giá trị được thảo luận trong một số giấy tờ học tập và 3) thêm một danh sách kiểm tra bài viết cho các vấn đề chung - xem đề nghị của tôi dưới đây). --Piotrus (talk) 05:21, 10 November 2015 (UTC)[reply]

Earlier discussion and endorsements
  Endorsed Also, @Gamaliel: is going to be proposing this as a default Gadget on English soon. Sadads (talk) 15:09, 12 November 2015 (UTC)[reply]
The Metadata Gadget doesn't makes clear the quality of the articles, because no normal reader can guess what the colors represents. And there are too many colors, why use different colors for ongoing events, disambiguations, etc? Just leave the title black!--MisterSanderson (talk) 04:03, 18 November 2015 (UTC)[reply]
  Endorsed Ottawahitech (talk) 15:38, 19 November 2015 (UTC)[reply]

Phiếu

  1.   Support--Shizhao (talk) 09:30, 1 December 2015 (UTC)[reply]
  2.   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)[reply]
  3.   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)[reply]
  4.   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! Talk • Work 00:47, 2 December 2015 (UTC)[reply]
  5.   Support--Manlleus (talk) 15:40, 2 December 2015 (UTC)[reply]
  6.   Support -- SantiLak (talk) 10:47, 4 December 2015 (UTC)[reply]
  7.   Support Halibutt (talk) 00:35, 5 December 2015 (UTC)[reply]
  8.   Support --Yeza (talk) 16:56, 5 December 2015 (UTC)[reply]
  9.   Support Zamaster4536 (talk) 12:54, 6 December 2015 (UTC)[reply]
  10.   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)[reply]
  11.   Support Abyssal (talk) 16:49, 10 December 2015 (UTC)[reply]
  12.   Support --Tgr (talk) 22:20, 13 December 2015 (UTC)[reply]
  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)[reply]

Khung di động thân thiện với cổng thông tin và dự án trang đa cột

Trên nhiều cổng thông tin và WikiProjects, các trang phía trước được thiết kế với một sự sắp xếp nhiều cột của hộp. Điều này cho phép phân phối gọn gàng và nhỏ gọn của nội dung có liên quan và / hoặc không liên quan trên màn hình máy tính để bàn lớn. Tuy nhiên, những thiết kế may dựa trên wikitables là yếu tố cấu trúc trong phần lớn các trường hợp, và vì lý do này mà họ tự bản chất không tương thích với các thiết bị nhỏ. Đây là một kinh nghiệm từ bỏ wiki, nhưng tôi nghĩ rằng tình hình không phải là tốt hơn nhiều trên wiki khác (ví dụ cổng thông tin tùy ý với hiệu suất kém trên điện thoại di động: [1] [2] [3] [4] [5] [6]; ví dụ để kiểm tra hành vi di động của họ, mở các liên kết trong webbrowser của bạn và thay đổi kích thước chiều rộng cửa sổ để điện thoại thông minh kích thước).

Có rất nhiều lý do cho những kết quả nghèo. Bên cạnh thực tế là nhiều cổng thông tin đã được thành lập trong một thời gian trước khi điện thoại di động, chúng tôi vẫn phải chịu cảnh thiếu thông tin về khung các giải pháp kỹ thuật dễ dàng toàn diện để xây dựng các trang portal / dự án di động thân thiện với out-of-the-box mà không cần CSS hacks phức tạp. Vì vậy, tôi sẽ đề xuất để phát triển một khuôn khổ, chủ yếu gồm các lớp CSS trên một trang web phù hợp trong Mediawiki không gian tên và do đó sẵn sàng cho sử dụng thông thường, với những đặc tính sau:

  • Một bộ linh hoạt của lớp CSS, tách ra cho phong cách và vị trí của hộp nội dung; người dùng có thể thêm các lớp học để các yếu tố cổng thông tin và xác định phong cách và định vị bằng cách làm như vậy
  • Hộp có thể được đóng gói bằng cách sử dụng các mẫu với các thông số, mà tôi nghĩ rằng được biết đến nhiều hơn với người sử dụng wiki so với đồng bằng HTML
  • Một lần biên dịch để một trang portal / dự án, việc bố trí hộp chất điều chỉnh để hiển thị kích thước, cho dù lối vào tiêu chuẩn, lối vào điện thoại di động, hoặc một ứng dụng được sử dụng Wikimedia
  • Một tài liệu chi tiết bao gồm cả trường hợp sử dụng sẽ bổ sung cho khung này; một người sử dụng wiki trung bình sẽ có thể tạo ra một trang portal thoại di & desktop thân thiện
  • Nhiệm vụ thưởng: cho phép các kỹ thuật CSS hiện đại trong không gian tên cổng thông tin, như ví dụ truy vấn phương tiện và bất cứ điều gì có ích; kỹ thuật có tay nghề cao người sử dụng có thể nâng cao kinh nghiệm điện thoại di động và máy tính để bàn bằng cách sử dụng tính năng này

—MisterSynergy (talk) 20:01, 11 November 2015 (UTC)[reply]

Earlier discussion and endorsements
  Endorsed LeoRomero (talk)
I'm not convinced this is somewhat useful at all... I never use portals and mobile phones, and on Portuguese Wikipedia the portals are all abandoned. Why create such mechanism, if there is noone interested in implementing it on the pages?--MisterSanderson (talk) 04:08, 18 November 2015 (UTC)[reply]
Portals and Wikiprojects are dead at de:WP too. At least there is no mass interest in them. The problem with portals is, that we have so many articles and therefore it is not possible to link many of them on one page. I remember that I once thought about something like an online museum in wikipedia. In wikipedia text is number one and pictures are the last number. If we would change that and pictures are number one, maybe something new would happen? We could ask GLAM people, what they think about that. In this way portals could get a new task, not just linking loads of wp.articles. Molarus (talk) 20:19, 20 November 2015 (UTC)[reply]

Phiếu

  1.   Support MisterSynergy (talk) 09:08, 30 November 2015 (UTC)[reply]
  2.   Support --g (talk) 15:13, 1 December 2015 (UTC)[reply]
  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)[reply]
  4.   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! Talk • Work 12:32, 2 December 2015 (UTC)[reply]
    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)[reply]
    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! Talk • Work 17:29, 13 December 2015 (UTC)[reply]
  5.   Support--Manlleus (talk) 15:41, 2 December 2015 (UTC)[reply]
  6.   Support —Beleg Tâl (talk) 17:02, 2 December 2015 (UTC)[reply]
  7.   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)[reply]
  8.   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)

Danh sách đọc

Tracked in Phabricator:
Task T120756

Độc giả (đôi khi là biên tập viên) khi bỏ lỡ một bài báo thú vị và muốn đọc vào lần sau (có thể là lí dó không có thời gian). Sẽ rất dễ dáng nếu bài báo được thêm vào danh sách đang đọc để có thể đọc bất cứ khi nào! Tôi biết có rất nhiều cách tạo các dấu trang web (cả với trình duyệt và các dịch vụ cung cấp online) nhưng ý tưởng này đáng để cân nhắc 4nn1l2 (talk) 10:28, 10 November 2015 (UTC)[reply]

Earlier discussion and endorsements
  •   Oppose. There's nothing here that cannot be accomplished by the bookmark functionality in your browser, it does not improve wiki content in any way whatsoever, does not make life easier for the core community and is better suited to WMF's Reading team. MER-C (talk) 14:54, 10 November 2015 (UTC)[reply]
Hey, and if the reader isn't on his home computer? Say he is on a relative's computer, public computer, cyber coffee computer, school computer? How to add on browser's bookmarks in these situations? In contrast, how to access the home bookmarks from these computers? Note: Facebook has a internal bookmark (saving) function for these cases.--MisterSanderson (talk) 04:32, 18 November 2015 (UTC)[reply]
That can be accomplished by having multiple watchlists. Helder 17:44, 10 November 2015 (UTC)[reply]
He7d3r, having multiple watchlist would be great!--MisterSanderson (talk) 04:32, 18 November 2015 (UTC)[reply]
This could be considered a variant on the previous proposal for additional watchlist functionality. A properly generalized watchlist could also be used as a personal reading list. Cscott (talk) 18:59, 11 November 2015 (UTC)[reply]
  •   Endorsed but would also like to add specific revisions or diffs to the reading list so I can come back to them later. This could be implemented relatively easily by having a "private" (only readable by the user and admins) wiki-page plus scripts that add or subtract things from this page. Davidwr/talk 05:37, 16 November 2015 (UTC)[reply]
  •   Comment In fact this is something (or exactly) like mw:Extension:Gather (which I find nice and useful). With this, anybody can create reading lists (aka "Collections"), private of public: en:Special:Gather/by/Geraki. They can even be used as multiple watchlists (en:Special:GatherEditFeed). The bad thing is that is still in beta, and currently you can add pages only through the beta mobile interface (but you can still check them in the desktop interface). So, I endorse to continue developing this extension and enable it to the main interface for all wikipedias. -Geraki TL 12:40, 16 November 2015 (UTC)[reply]
  •   Endorsed While my PC's browser is quite capable of bookmarking pages, this does me absolutely no good when I head on over to my local library with the intent of doing a bit of fact-checking or citation gathering. When I first came to this page it was my intent to make a suggestion similar to this, so I'll endorse this one instead! I think that ideas related to a reading list, expanded functionality of a watchlist, and a to-do list can be combined to make an especially useful tool. Etamni (talk) 07:58, 17 November 2015 (UTC)[reply]
  •   Endorsed I was about to propose a private To-Do list for other uses, but it's much of the same thing. There are some sites offering ToDo lists, but it would make life much easier if each editor could open his own private discreet list inside Wikipedia - mostly since it would be easier to add links to files (in the Commons/home wiki) or pages in his home project. I currently use a site called EveryDay for this purpose, but besides some restrictions for not-paying users, the main problem is as I mentioned, linking to pages and files inside Wikimedia projects. I need these kind of lists for 3 purposes: 1. Files I have to watch - I often leave notes in uploaders' talk pages with requests for OTRS release approvals for the files, then I wait a week or two and if we don't get any response, I have to open a deletion request in the Commons. Since there are too many of those, I need a list, preferable with an option for some kind of a reminder at a certain time; 2. Info to add - For example, if I read an article and find it useful for Wikipedia as reference or just something to add as an external link, when I don't have the time to do it then, or when I cannot do it at that time from other reasons... I want to be able to get back to it later; 3. Other wiki-tasks - all sort of improvements and additions I find that I would like to work on some time sooner or later, when I would have time for it - I need a place to write it down.
    Please contact me in any question. Ldorfman (talk) 23:23, 22 November 2015 (UTC)[reply]

Phiếu

  1.   Support 4nn1l2 (talk) 02:59, 30 November 2015 (UTC)[reply]
  2.   Support בנימין (talk) 07:37, 30 November 2015 (UTC)[reply]
  3.   Support Ldorfman (talk) 22:23, 30 November 2015 (UTC)[reply]
  4.   Support Alleycat80 (talk) 09:04, 1 December 2015 (UTC)[reply]
  5.   Support --Shizhao (talk) 09:31, 1 December 2015 (UTC)[reply]
  6.   Support -- AvatarFR (talk) 13:30, 1 December 2015 (UTC)[reply]
  7.   Support simple: non-watching watchlists. --Purodha Blissenbach (talk) 14:32, 1 December 2015 (UTC)[reply]
  8.   Support --Martinligabue (talk) 15:04, 1 December 2015 (UTC)[reply]
  9.   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)[reply]
  10.   Support --Urbanecm (talk) 17:46, 1 December 2015 (UTC)[reply]
  11.   Support --Wesalius (talk) 19:10, 1 December 2015 (UTC)[reply]
  12.   Support Jules78120 (talk) 19:57, 1 December 2015 (UTC)[reply]
  13.   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...[reply]
  14.   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)[reply]
  15.   Oppose Not related to improving and maintaining wiki projects. Easily done by browser, as mentioned before. Gap9551 (talk) 23:05, 1 December 2015 (UTC)[reply]
  16.   Support Helder 23:40, 1 December 2015 (UTC)[reply]
  17.   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! Talk • Work 12:43, 2 December 2015 (UTC)[reply]
  18.   Support Why not? Regards, Kertraon (talk) 13:19, 2 December 2015 (UTC)[reply]
  19.   Support--Manlleus (talk) 15:41, 2 December 2015 (UTC)[reply]
  20.   Support--MisterSanderson (talk) 01:00, 3 December 2015 (UTC)[reply]
  21.   Support YBG (talk) 06:36, 3 December 2015 (UTC)[reply]
  22.   Support Rzuwig► 10:57, 3 December 2015 (UTC)[reply]
  23.   Support Orbwiki107 (talk) 17:24, 3 December 2015 (UTC)[reply]
  24.   Support SantiLak (talk) 10:47, 4 December 2015 (UTC)[reply]
  25.   Support Chenspec (talk) 21:16, 4 December 2015 (UTC)[reply]
  26.   Support Lester לסטר (talk) 18:09, 5 December 2015 (UTC)[reply]
  27.   Support Zamaster4536 (talk) 12:54, 6 December 2015 (UTC)[reply]
  28.   Oppose per opposes above. Don't add unnecessary clutter to readers screens. DexDor (talk) 20:07, 9 December 2015 (UTC)[reply]
  29.   Support Alkamid (talk) 22:33, 13 December 2015 (UTC)[reply]


Wikibooks sử dụng Hỗ trợ tính năng link web con để tạo nên các chương. Wikiversity thực hiện tương tự với một khóa hay các bài học. Mỗi trang dẫn sẽ có các link chỉ về các trang nguồn một cách tự động. Hơn nữa các tác giả còn đề nghị các web chứa nội dung nguồn. Tôi thích tính năng tự động hủy các thanh dẫn này hơn vì thông tin song song có thể làm nhiễu loạn người dùng

Với người dùng: Các trang wikibook, Wikiversity và các dự án khác sử dụng trang dẫn. Hiện trạng: Các link dẫn web nguồn chưa được loại bỏ. Giải pháp: thêm đoạn code behavior switch hoặc một cái gì đó tương tự -- Juetho (talk) 10:45, 18 November 2015 (UTC) [reply]

Earlier discussion and endorsements
@Helder As far as I see the BookManager uses a special way via its own metadata and is made to combine separate sites (in WP e.g.). A book in Wikibooks or a course in Wikiversity uses a manual structure with a main page and subpages. Each author has her own idea how her book is structured and shown (incl. navigation bar and list of contents). Therefore it's a manual decision for each subpage. -- Juetho (talk) 12:49, 22 November 2015 (UTC)[reply]
The whole point of the extension is not to structure books manually, so that navigation, and other things can be done automatically. Helder 17:38, 22 November 2015 (UTC)[reply]
@Nemo Please, take a look at b:en:Geometry for Elementary School/Introduction (link above -- that's an example only). Wikibooks and Wikiversity use both -- subpages by default in the main namespace (an important kind of structure in any book resp. course) in addition with a navigation bar (an important kind to navigate within a book resp. course). In these cases the links to ancestor pages are partly superfluous and disturbing. In Wikibooks and Wikiversity not a single user wants to give up these structuring methods, but many users don't want the additional links. -- Juetho (talk) 16:47, 22 November 2015 (UTC)[reply]
You can hide them using local CSS (something like span.subpages { display: none; } ). Helder 17:38, 22 November 2015 (UTC)[reply]

Phiếu

  1.   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)[reply]
  2.   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)[reply]
  3.   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)[reply]
  4.   Support --Shizhao (talk) 09:31, 1 December 2015 (UTC)[reply]
  5.   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)[reply]
  6.   Oppose --Usien6 (talk) 20:55, 1 December 2015 (UTC)[reply]
  7.   Oppose Helder 23:40, 1 December 2015 (UTC)[reply]
  8.   Support per Nyttend. Stevie is the man! Talk • Work 12:49, 2 December 2015 (UTC)[reply]
  9.   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)[reply]
  10.   Support--MisterSanderson (talk) 01:00, 3 December 2015 (UTC)[reply]
  11.   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.[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2015/Reading/vi&oldid=26753604"