Grants:IdeaLab/Easier table's description
Project idea
[edit]What is the problem you're trying to solve?
[edit]
When reading any long table, the reader loses sight of column headers when scrolling vertically down in the table. This is especially aggravating in long sortable tables, where the main aim usually is to compare several rows' information. For example, in Comparison of operating systems, the table headers disappear upward out of view, and it becomes difficult for the reader to make comparisons.
The same problem occurs when scrolling right in some tables, as columns of row titles disappear when the reader scrolls horizontally. This perhaps is less of a problem for readers, as there is no sorting of tables horizontally, and editors may have avoided constructing very wide tables. There certainly must be cases where tables that are both tall and wide would be useful to have, but such tables are not useful to readers if title rows and columns scroll out of view.
- Update: However there is Template:Scrolling table, at least in the English wikipedia, which allows for horizontal scrolling of a table? Is there no analogue for vertical scrolling? Maybe to find out just requires a question at Wikipedia:Village Pump (technical)?
- Update 2 (April 2017): New feature addresses vertical scrolling, at least in the English wikipedia in select browsers: Preferences -> Gadgets -> Testing and Development -> Make sure that headers of tables remain in view as long as the table is in view (Requires Safari or Chrome). --Doncram (talk) 15:48, 20 April 2017 (UTC)
What is your solution?
[edit]
A solution would be a programming change somewhere (in media-wiki language? in javascript code? in XHTML? in a template?) that locks (keeps fixed) the table's header rows so that users can easier relate contents to respective headers/titles. And allows fixing of column titles (and perhaps also of row titles) as done in spreadsheet software.
Goals
[edit]If a programming change can be implemented, this will allow readers to make better use of existing long tables. This will allow editors to create larger tables that are still useful, to better address existing topics. Perhaps it will allow consolidation of information that currently is presented in multiple tables. And it likely will enable adequate Wikipedia coverage of new topics where both vertical and horizontal dimensions need to be very large.
Get Involved
[edit]About the idea creator
[edit]Participants
[edit]- Designer New table structure's design. Dorivaldo de C. M. dos Santos (talk) 21:40, 15 March 2016 (UTC)
- But a designer of a programming solution is needed.
- Researcher Speed up researches to make the idea conforms to Wikimedia conformity. Dorivaldo de C. M. dos Santos (talk) 23:40, 15 March 2016 (UTC)
- But a researcher of how well various programming solutions work for readers, or in what settings (articles) this allows better presentation of ideas to readers, etc., may be needed. Maybe no one can be interested in programming this, rather than working on other programming priorities, if there is no survey or other evidence of how useful it would be.
- Advisor Advise the development issues as it grows in complexity. Dorivaldo de C. M. dos Santos (talk) 23:56, 15 March 2016 (UTC)
- What an advisor is needed for depends on the design, the volunteer, etc.
- Volunteer Being available to participate in different branches and phases of the idea development. Dorivaldo de C. M. dos Santos (talk) 00:48, 16 March 2016 (UTC)
- Volunteer capable of revising media-wiki programming language (or programming in javascript or whatever else is needed) is needed.
- Volunteer capable of finding where programming enhancements get done (is this on a "features wanted" list already?), and finding volunteer(s) and/or advisors for them is needed.
Endorsements
[edit]- A programming change here would allow merger of list-articles that are currently split for readability, and allow sorting of the information previously split that cannot now be done. I and other editors have accepted limitations of tables in Wikipedia that we would never accept in spreadsheet software. This is so basic, while we should perhaps be allowed features better than spreadsheet software allows.
- For example, comparison of data three-dimensional tables should be possible. Imagine a window displaying a Rollodex-like deck of cards, with one card (which can display a small table of X vs. Y information) completely visible, and top edges of following cards (differing on a dimension Z) visible above. If two such windows onto the same deck are presented side-by-side, the reader could scroll each forward and back in order to compare information on any card to any other card. And the reader could be allowed to rotate the dimensions so that they could compare tables of X vs. Z information and so on.
- Further, for relational database data, the reader could scroll through one table's rows in the window on the left, and, given a certain row is displayed there, then scroll through additional characteristics specific to that row in a window on the right. When filling out forms on the internet, we often select country, then only certain states or provinces are acceptable choices in the next entry. Why can't wikipedia editors present information for readers to browse in the same way we are all accustomed to doing, elsewhere?
- However, who/how can any of this be programmed? The original request is most basic and most important. Could a javascript extension (or other programming) be created, at least for users who are willing to adjust their account settings in some way? Doncram (talk) 16:41, 16 March 2016 (UTC)
Expand your idea
[edit]Would a grant from the Wikimedia Foundation help make your idea happen? You can expand this idea into a grant proposal.