Maps, Directions, and Place Reviews
Tools for your convenience
Text file with fields for 1-99 listed:
- Google Docs format
- Plain text format (downloadable)
Excel spreadsheet (1-99) for easier data entry that creates a formatted column:
- Google Docs format
- Excel 2003 format (downloadable, recommended)
Suggestions or problem reports would be appreciated. Ponydepression (talk) 18:36, 17 April 2010 (UTC)
Tracking Spreadsheet Template Excel Video
Recent change: width
I notice an editor has changed the template so that "width" is a "new" parameter. The parameter has not been added to the documentation, nor was it discussed or even announced here. The change does NOT expand the width of the table, and I wonder if the editor intended that to be the effect. If not, I'm not certain of the purpose of this change. Should we revert? And isn't it time we protected this template so only admins can update it, considering the many articles it's used in, to prevent it from being affected by vandalism, not to mention well intentioned but untested / undocumented / unapproved changes? --A Knight Who Says Ni (talk) 12:31, 1 May 2010 (UTC)
- The width parameter allows changing the table width (such as "width=300px") as in many similar templates. Some articles have right-side infoboxes or photos which require the track-listing to be narrowed to fit, alongside the left margin of the page. By default, the width=100% will appear unchanged in all other articles using the template. That's why the template had seemed functionally identical to the prior revision. It is possible to redesign the width to auto-narrow when alongside infoboxes, which would perhaps be a better solution. The current width=100% is a "magic number" that demands shifting the track-listing table into an area of the page which has the complete width of the page (no images/infoboxes there). For that reason, tables also have trouble formatting when a single column of a table is set width=100%, as a logical conflict with the width of the whole table being above 100% (although that is possible, such as width=105% to trigger a bottom scrollbar). Often, tables are designed with no explicit width, but rather having spacer columns between text columns, and the table will then automatically change width, auto-narrowing alongside infoboxes or images in each article. Basically, defaulting a table as width=100% will usually cause trouble in short articles with infoboxes. As far as I know, there is no essay fully explaining this issue, so few editors are aware of the tricks to make tables auto-narrow alongside infoboxes (in short articles). I have written about other problems; for example, see essays:
Proposal to auto-narrow width
The following example (live) shows how the track-listing table aligns with an infobox & image. When a table is set as width:100%, then that table is forced down a page until it can span the full width of the page (with no infoboxes or images alongside). The track-table is displayed by {{track_listing/sandbox}}:
To close a large gap above a wikitable, remove the style option "width: 100%;" from the table header in the template, and allow the width to auto-narrow. Large gaps often appear in short articles which mix an infobox with a table, as in the example here.
The next issue is to narrow the table, in general, to prevent an over-wide display, by reducing the 2nd 100% to be 80% as:
Those 2 settings should allow the table width to auto-narrow, as specifically needed in each article. -Wikid77 02:53, 2 May 2010 (UTC)
- I have made many similar changes (removing "width:100%"), but I tested it in this topic by using {User:Wikid77/Template:test} instead of template {track listing} for those Beatles tracks. When I tried the current revision in Firefox, I see that browser did ignore the "width:100%". I usually go to a public library to see what some users, who can't change their computers, will see by default. Logically, it just makes sense to remove "100%" because common sense would conclude "width:100%" means 100% wide. Take the simplest solution, and move on to other articles. -Wikid77 (talk) 13:40, 2 May 2010 (UTC)
- I have updated {{Track listing/sandbox}} and used it in the example (above), to show the effects of removing "width:100%" and setting "0 = width:80%;". There are so many browsers, to consider testing, that I would do the most-logical change and remove "width:100%" since any other browser would likely think, "100% means force the table as 100% wide". Again, after years of analyzing wikitables, I have found the best tables have almost no width=xx options set anywhere in the tables: let the columns shift depending on how long the titles are. However, we could add a parameter "width=500px" when people want to force large, multiple track-tables into a consistent pattern of width. Have you viewed the track-tables on the "Safari" browser? -Wikid77 (talk) 21:26, 2 May 2010 (UTC)
I'm confused. What is the intention here ? I tried reading the above and i'm totally confused.
- What problem are we fixing ? (answer: wrapping on narrow screens; sight-impaired viewing; tables@infoboxes)
- Who is affected by the problem
- What are we changing (answer: column width settings & new width=580px. -Wikid77 )
- Who is affected by the change ? (answer: over 10,000 articles)
--TheDJ (talk o contribs) 21:49, 2 May 2010 (UTC)
Automatic Track Listing Converter
Hey everyone. I realize always having to manually enter in all of the track information is a drag, even with templates, so I created a program to do most of the heavy lifting. Essentially you paste in the old track information, select the options, and click convert. The output will be directed to Notepad.
Note that since this requires Notepad, it will only run on Windows systems. I've only tested it on Windows XP specifically.
It comes with no warranty, but it does come with the source code ;) It was written in AutoIT.
It also only pipes out the Track title and Length automatically; any notes must be entered manually, although the blank form is generated.
For instance, at the intial screen, copy and paste this:
# "Razor" - 6:48 ([[Dave Grohl]])
# "Over and Out" - 5:56 (Grohl, [[Taylor Hawkins]], [[Nate Mendel]], [[Chris Shiflett]])
and, depending on the options, this is the output.
{{Track listing
| title1 = Razor
| length1 = 6:48
| title2 = Over and Out
| length2 = 5:56
}}
Again, everything should be checked for accuracy; this just does most of the gruntwork. However, it should allow for much easier horizontal rather than vertical comparisons.
Please try it out and get back to me.
It can be found here...
http://sourceforge.net/projects/tlconverter/files/
Cheers, Foofighter1337
P.S., I'm new to editing Wikipedia, so I'm terribly sorry if I violated any rules. --Preceding unsigned comment added by Foofighter1337 (talk o contribs) 08:52, 5 May 2010 (UTC)
hAudio microformat
I plan to add the hAudio microformat to this template; but first it would be useful to have the parameters of {{Tracklist/Track}}
This documentation is still required, please. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:39, 12 May 2010 (UTC)
Proposal to redesign table width to fit longer titles
I have redesigned the template in "/sandbox2" to auto-widen for long titles to fit the full page width, if needed. There have been multiple problems with the table width:
The new revision will auto-widen the track-table when titles are very long, and no longer leave white-space at the end of the table, unless using new parameter marginright=10em. -Wikid77 04:42, 3 May 2010 (UTC)
Cause of over-wide tables
The problems of unusual table widths were caused by multiple issues:
Those were fixed, as follows:
The solution involves making the width settings to be optional parameters, but also defaulting the column widths in pixels (such as 270px, not as percent 60%) to fit the size of the titles given. When a user widens a browser screen, then the table will auto-widen to fit the space, but not wider than needed. -Wikid77 15:22, 3 May 2010 (UTC)
Impact of auto-widened tables
Rather than span the entire page, an auto-widened table tends to be only as wide, as needed, to fit the actual titles, writers, and other entries for a specific album. For years, the display of track-tables had been geared to span across wide laptop screens, where track tables were typically very wide tables, similar to accountant ledger sheets. Now, the spacing between columns will be controlled, if needed, by setting the spacer gapwidth=35px (or similar) when wide tables are needed in an article. For a list of other parameters used to widen a table, see subtopic below: "#Customizing auto-widened tables". -Wikid77 19:25, 3 May 2010 (UTC)
Customizing auto-widened tables
With the table columns defined by pixel widths ("270px" or "95px"), it is possible to precisely set the width of each column, and now spacer-gap columns will be used to spread columns across a page. This capability is needed for WP:Featured articles, where the quality of typesetting can be an important issue.
The new parameters, for width-control, are as follows:
When there are multiple track-tables, stacked together as a set, it might be necessary to set each table with titlewidth=350px (or similar) so that short-title tables align with long-title tables. By default, each track-table will auto-widen to fit whatever long titles are listed. So the various techniques for aligning multiple track-tables are:
In rare cases, such as group song collaborations, it might be necessary to insert multiple "<br>" breaks in a Writer's list, so as to wrap all the names down the screen. There is no "one size fits all" plan for displaying tracks of an album, so that's why customizing of column widths is needed, in rare cases. Consider users with narrow windows, versus wide laptop screens. Sometimes, an extremely long title should be force-wrapped by inserting a "<br>" break. -Wikid77 (talk) 19:26, 3 May 2010
Examples of /sandbox2 to auto-widen
The examples below show the current table-format, versus the proposed /sandbox2 table-format for various album tracks. The difference is most obvious when the browser text-size is increased (as with sight-impaired users) or the browser window is narrowed to 800x600 width, or even narrower for hand-held devices.
Current revision:
Proposed /sandbox2:
For wide-screen windows, the examples for the current version & /sandbox2 will appear similar in table width. When set properly, the title-column will have the same width for each disc in a set. Again, the track-tables should still be readable with large browser text-size settings, per the WP:Accessibility policy. -Wikid77 (talk) 13:06, 3 May 2010 (UTC)
- Currently, gapwidth=12px is the default spacing, after the Title (or before the Writer, Lyrics, Music or extra-column). Each track-table can increase that gapwidth, if there is a crowding problem. The 800x600 width is noted by WP:Accessibility, but the template is not the wiki-police, so I allowed it to force a table to width=700px (or more), if the writers of an article feel a track-table should be that wide. -Wikid77 (talk) 03:43, 4 May 2010 (UTC)
- Blank-line bug in /sandbox2: The whitespace gap above testcase-1 "Side Two" was caused by /sandbox2 skipping a blank line for each 2 tracks omitted, starting on Track 9 (skipping 8 tracks, or 4 blank lines). I put HTML comments between rows to suppress those wiki-spastic newlines (it always takes me too long to find where MediaWiki newlines are being inserted). Hence: Kids don't do this: Don't ever invent a spastic markup language which spawns newlines; don't drop out of college but stay and learn about "context free grammar" & "string grammar" and help stamp out newline madness. -Wikid77 (talk) 20:43, 3 May 2010 (UTC)
- I see no problem with those HTML comments between rows, as a safety net. Perhaps some people think of a spare tire as a "quick-and-dirty fix" for having a flat far down the road, but I see spare tires as just one, of multiple options, to keep a car in operation. For decades, people have suggested "defensive programming" of software, adding multiple levels of safety nets, rather than try to solve a problem in just "2 lines of code" which would fail on related problems or mistakes in the future. The most important issue is to keep moving to provide better formatting of track-tables, such as customizing the layout in WP:Featured articles, or allowing larger text-size for sight-impaired readers using narrow screens. -Wikid77 (talk) 09:25, 4 May 2010 (UTC)
I was honestly unsure of where to place this, as the "auto-widen/width" topic has been split off into several sub-topics, but since I'm giving an example with my concern, I figured I would place it here. I think the width issue needs to be rethought, as while I can see the need for it to be adjusted for those with smaller screens, the changes are having an undesired effect on larger screens (if you ask me.) Take a look at this "real world" example of a busier table than the example shown:
The proposed version is unnecessarily scrunching the table and causing wraps that aren't needed on larger screens. As stated, I can understand needed to adjust the template so it plays nicer with smaller screens, but I don't think that should come as a penalty to larger ones. You have implemented the width option to override the default width, but by default I think it should better adapt to the screen size.
This example also brings up a tiny issue that I think should perhaps been looked into. In the example of the revised version, I have a total_length set, as well as addtotal (which, perhaps should be "add_length" or "add_total_length"?) and it results in both being shown. Now obviously this isn't the "correct" usage, but I think the template should have some kind of check for this type of redundancy. I believe only one value should be shown (if possible). In that case, I think manual should override auto. - Mizery Made (talk · contribs) 19:07, 7 May 2010 (UTC)
Migration plan for auto-widened tables
04-May-2010: In general, the use of auto-widened track-tables should require editing of only a few album articles, to migrate into the new format, such as using customized width parameters. As could be expected, during prior years, many articles have already placed images, or infoboxes, alongside the track tables, to limit their extreme width on wide, laptop screens. In many cases, those track-tables (viewed on laptops) will appear only slightly narrower, in width, when auto-widened to fit long titles. The greatest gains, in table readability, will come in tables with just Title+Length, or to users of narrow-window screens, such as on desktop monitors, or narrow half-screen windows. Because most music tracks have titles with fewer than 10 words, the vast majority of auto-widened tables should appear "normal" even if narrower than before. The greatest surprises will come in tables with one extremely long title, or 4 people writing a single song, and those tables should be customized, such as splitting the long title (with "<br>") to avoid an excessively-wide table, due to one long song title or 4-6 songwriters (etc.). In migrating to auto-widened tables, the new customized width parameters (titlewidth=350px, gapwidth=25px, width=585px, or mr=10px) will allow refining the appearance of track-tables in WP:Featured articles, for the first time in years. In general, spot-check several, perhaps 29, of the "somewhat popular albums of all time" to ensure that the most surprising table layouts have been adjusted. Far more albums in articles, now, will gain clearer track-tables, rather than become awkward, or unbalanced, lists of recordings. No longer will 2 columns of a track-table have words which run-together, such as the last word of a title join to a Writer, as word+name ("Bridge over TroubledPaul Simon"). On balance, most track-tables should appear clearer than before. -Wikid77 (talk) 03:17, 4 May 2010 (UTC)
- All these issues need to be considered, all together, so that everyone can be prepared to move forward, with the re-formatting, or customization, of track-tables. We should avoid getting trapped in a "paralysis of analysis" - the track-tables have been awkward for over 3 years, so we need to keep moving to make progress. I don't mind making more improvements once-a-week, if that is needed to provide better functionality for more users. The issue of the shifting "show/hide" buttons, noted above, is another concern: the "[show]" button remains at the end of a table when parameter width=510px (etc.) is specified, but we also need to allow the table width to be variable, when the "[show]" button will slide to the left. I regret that so many issues are being juggled here, but it has been 3 years waiting to allow customized track-tables. -Wikid77 (talk) 09:25, 4 May 2010 (UTC)
- Weak support, because I only vaguely understand pixel padding. I do think that an important part of this work, is documenting it for the template instructions, in a way that non-technical people can understand. Support would probably improve if the documentation were prepared now instead of later or as an afterthought. --A Knight Who Says Ni (talk) 12:42, 4 May 2010 (UTC)
- Weak support. By playing around with the window size on the test cases I can appreciate the benefits that the /sandbox2 proposal brings to narrow screen displays. Furthermore, the issue of the shifting "show/hide" buttons is not a showstopper for me; I think this is something we can get used to. However, I think the proposal has a serious issue when displayed on standard laptop or desktop full screens. It looks like the table narrows itself more than necessary, leading to some of the cells being displayed over multiple lines when it's not really necessary. The worst example is in section 4.3 where the Writer(s) column is so narrow that track 9 ("Paul Rodgers, Paul Kossoff, Andy Fraser, Simon Kirke") is displayed over 4 lines(!), while there is a huge amount of whitespace to the right of the table. That's totally unnecessary and I believe the table should be able to auto-adapt better without us having to parametrize it manually. The same phenomena is also seen in section 2.3 where the title (incl. the note) often displays on 2 rows while, again, there is lots of whitespace to the right of the table. Finally, I agree wholeheartedly with Knight on his demand regarding the documentation. - IbLeo(talk) 21:06, 4 May 2010 (UTC)
- It would be great if we had to templates, because those related to game OST, one would slightly be larger than the other. we seen multi templates for stuff like this, why not for tracklist? i was thinking it would have two extra sections, extra and extrab i honestly don't see what the problem is for having a bit of extra space thoughBread Ninja (talk) 18:36, 5 May 2010 (UTC)
New parameter endnotes & endnotes_color
The new parameter "endnotes=XXX" (in /sandbox2) would put text at the bottom of a track-table, with the default endnotes_color=#F3F3F3 (light gray). Many readers have wide laptop screens, so extra thought is needed to design tables to also fit in narrow square windows (such as 800x600). For testing as square windows, the table width can be restricted as width=585px, then observe the spacing of table columns. Only some browsers auto-widen the columns to fit longer text, so the handling of extra-wide text could be helped by putting a bottom end-note to explain the entry "4 authors[a]" and defining note [a] with new parameter "endnote=[a] - The 4 authors are...". For multiple notes [a], [b], [c] (etc.), the endnote text could contain "<br>" breaks or use the colon-indent for each note line after "| endnotes=".
The endnotes (above), in markup language, spans 3 lines, as follows:
| endnotes_color = #F0F0F0 | endnotes=Notes:<br> [a] - This song was recorded in 1 take, selected as best version.<br> [b] - The 5 writers are Paul McCartney, John Lennon, C, D & E. | length1= 4:13
The endnotes=xxx is basically free-form text, to allow any style of table footnotes. The use of note letters "[a]" & "[b]" is customary, to distinguish from an article's numbered footnotes [1], [2], [3] (etc.). Those letters can have the "sup" superscript tag ("<sup>[b]</sup>"). Now, with an article intended for young readers, the first note could be clarified to emphasize its location inside the table: "(see table note: [a])" being more obvious to young readers. As always, any use of reftag footnotes will list those notes at the bottom of the page in the Notes/References sections. By using endnotes=xxx, there will no longer be a need to force any column to contain an extremely long entry. -Wikid77 (talk) 17:49, 5 May 2010 (UTC)
- Endnotes for more than just Writers: The endnotes text is also used for other entries, beyond just the writers, and could be used to explain, as an endnote, that a particular track's length is the midpoint between 2 songs that run together, sounding as if both songs were only one track. Similar table endnotes are used in numerous Wikipedia articles, such as explaining the source of city population statistics. An endnote could be used to indicate the primary writers, versus perhaps 3-5 other collaborators who had only minor contributions to the lyrics. I realize that readers with wide laptop screens are not often aware of the readability problems for users with square windows, or who read the track listing on an iPhone or small handheld device. The layout of a track table needs to reflect consensus of the various readers affected. -Wikid77 00:20, 6 May 2010 (UTC)
New parameter addtotal=yes
The new parameter "addtotal=yes" (in /sandbox2) will add the track lengths (minutes/seconds in dot colon format mm:ss) and show the total of those numbers (length1 + length2 + length3...) at the bottom of the Length column. The total would be in the same location as with parameter "total_length=mm:ss". However, the sum of minutes/seconds for addtotal=yes would be calculated, live, by adding each of the parameters (length1=mm:ss) in the track-table. -Wikid77 (talk) 19:56, 6 May 2010 (UTC)
Proposal for limited use of 2nd Template:Tracklist_custom
06-May-2010: I agree that having 2 track-list templates is a better solution: in a volunteer project, it is too difficult to expect everyone to take time to consider, and refine, all the new options "forced" onto everyone, as a single track-list template. A new Template:Tracklist_custom, as a vanguard template providing new features, will lessen the impact to all those 15,000(?) album articles, and allow long-term live testing of features, so more people will have ample time to evaluate the impact of new features. Some new features, after being evaluated in {Tracklist_custom}, long-term, could then be added into {Track listing}, after many people have taken the time to consider the new functionality. Again, volunteers do not have time to evaluate the potential of widespread changes to over 15,000 articles, in a few weeks. The 2nd template would simplify the exploration of new features, without scaring the current users about impacts to the other 15,000 articles. We would annotate the documentation subpages to note the use of those 2 templates (one for most articles, the other for custom tables, with similarity between the two), allowing a broader range of features to support the entire user base of Wikipedia. -Wikid77 (talk) 00:47, 6 May 2010 (UTC)
- There are many other templates which have variations, but I understand that some people worry about the diversity, and spend enormous amounts of time trying to delete such variations of templates. Again, it has been about 3 years that Template:Track_listing has appeared as an over-narrow template on square windows (such as 800x600 pixels). As of 2010, those users with narrow windows can no longer be ignored, per WP:Accessibility. The major conflict is between the main standard template, which is used in "countless" articles (perhaps 15,000?), and attempts to add enhancements, without subjecting all articles to somewhat unproven options, which could have unforseen consequences, not to mention alarming the numerous users unaware that major changes were being made. As far as other variations, simply recommend that users consider making changes to one of the 2 existing templates, rather than create a third or fourth variation template. Please consider the frustrations of people who do not have time now, during the current 2 weeks, to ensure that proposed changes would be compatible with their plans for article track-tables. The use of a single track-table template has stifled improvements for years, but we don't need to try to force everyone to accept improvements now, while allowing improvements to be used in some articles. Once a standard template has been modified, there is the danger of unforseen consequences, so using a 2nd, customized, template avoids many, many problems, while planning to update the main template. -Wikid77 (talk) 16:40, 6 May 2010 (UTC)
- I strongly oppose a forked template, per all the good reasons already stated by Knight. Furthermore, Wikid77, I feel that adding all those options left, right and center is working against you. Although some of them, are really good ideas (like the automatic addition of track lengths), they are logically independent from the raison d'être of this discussion--i.e. the attempt to improve the auto-widening capabilities of the template--and should go into separate threads. So I suggest at this point to concentrate on the auto-widening and leave the other improvements aside for later. If you can get the new version to work well for the vast majority of readers that use a standard laptop or desktop screen (see Mizery Made's concern above) I am with you. - IbLeo(talk) 06:29, 9 May 2010 (UTC)
Source of the article : Wikipedia
EmoticonEmoticon