Jump to content

Template talk:Portal bar

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Module talk:Portal bar)

noviewer class so Media Viewer skip Portal Bar's images

[edit]

I noticed that when using the Media Viewer to browse an article's images (e.g. those in Charlize Theron#See also) that the images in the Portal bar appear. This seems highly undesirable. There is a special class ("noviewer") that can used to have Media Viewer skip images, see Wikipedia talk:Media Viewer#Some images need to be excluded). Seems like a good idea for this template to use it. Jason Quinn (talk) 22:13, 16 January 2015 (UTC)[reply]

At a quick glance, I'm not sure how to add that class. (Sorry, I'm not much of a coder.) Tell me precisely what you want added and where and I'll do it when I have time. Alternatively, if you can do it yourself, go for it. – Maky « talk » 23:01, 16 January 2015 (UTC)[reply]
 Done — hike395 (talk) 14:55, 20 December 2021 (UTC)[reply]

Version without Module:Navbox

[edit]

This template currently outputs (in most cases) a <table> inside a <table>, when a tableless layout can achieve the same appearance. The template started using Template:Navbox and its nested tables with this diff, but I'm not sure why. I put a simplified version in the module sandbox (see testcases). Does this look okay? Matt Fitzpatrick (talk) 11:07, 18 June 2016 (UTC)[reply]

Edit requested

Changes

  • wraps list in a navigation region labeled "Portals", instead of nested single-cell tables
    • reduces HTML output about 200 bytes
    • provides accessibility context (WAVE report on testcases)
    • should reduce browser load (nested tables are slow)
  • removes margins from list
    • list is no longer horizontally and vertically off center

Incorporates feedback from WT:WCAG#Module:Portal bar. Thanks again to Redrose64 for pointing out that some of these images cannot be unlinked.

Matt Fitzpatrick (talk) 21:52, 28 June 2016 (UTC)[reply]

Added bonus, I just noticed the MediaViewer problem reported above in 2015 by Jason Quinn. This edit accidentally fixes that. The navigation region's "metadata" class keeps the images from being cycled in MediaViewer. Matt Fitzpatrick (talk) 22:17, 28 June 2016 (UTC)[reply]
@Matt Fitzpatrick: Done. Looked at this for a while. Code looks more lightweight here. And yeah, not sure why Navbox was needed. I think many folks support less tables in general. The new "aria-label Portals" looks okay to me, and bolding the entire thing as you've done doesn't seem to be a problem. Cheers, — Andy W. (talk · ctb) 07:45, 29 June 2016 (UTC)[reply]
  • @Matt Fitzpatrick and Andy M. Wang, this edit appears to have introduced a 1em top margin for the portal bar, which makes the bar look strange when it was designed to run flush against the nav boxes at the bottom of the page. Please revert and we can discuss as necessary (ping me if so) czar 10:24, 13 July 2016 (UTC)[reply]
I rolled back Module:Portal bar/sandbox to the previous version, and added a new test at Template:Portal bar/testcases. Looks like the new ("main") version isn't getting the "table.navbox + table.navbox { margin-top: -1px; }" from MediaWiki:Common.css that the old ("sandbox") version did. I'll have to do some user CSS testing to make sure, but I have a hunch adding class="navbox" back to the portal bar, then adjusting the CSS to work with any element might work. Matt Fitzpatrick (talk) 11:11, 13 July 2016 (UTC)[reply]
Too close to bedtime to test this properly, but my first thought was readding the navbox class to bordered portal bars (Special:Diff/727480237/729612900), and editing Common.css to allow non-table elements to be navboxes (Old revision of User:Matt_Fitzpatrick/common.css). Will of course need wider notice, and careful testing of all things navbox related. I don't see at first glance any style declarations the table.navbox selector overrides that .navbox by itself wouldn't, though. Matt Fitzpatrick (talk) 12:13, 13 July 2016 (UTC)[reply]
@Matt Fitzpatrick and Czar: Undid. Matt, I'm assuming you would be able to handle this. (I'm attempting to take a bit of a semi-wikibreak right now) — Andy W. (talk · ctb) 16:01, 13 July 2016 (UTC)[reply]
I'm putting up an edit request for MediaWiki:Common.css shortly. Old revision of User:Matt Fitzpatrick/common.css summarizes the edit request. The new CSS should resolve visual discrepancies in Template:Portal bar/testcases, but should not affect any part of Template:Navbox/testcases. Please let me know if you notice anything's gone wrong. Matt Fitzpatrick (talk) 23:13, 14 July 2016 (UTC)[reply]

Border

[edit]

Why there is no border around images when compared to {{portal}}? Borders are defined in subpages, for example Module:Portal/images/j contains ["japan"] = "Flag of Japan.svg|border|link=|alt=", but display for {{portal|Japan}} (right) and {{portal bar|Japan}} (below) is different when we are looking for border:

Also, |link=|alt= could be moved to main module page(s) rather than being defined for each entry.--Obsuser (talk) 16:01, 4 May 2017 (UTC)[reply]

I don't think a border surrounding each image would improve the bar's appearance. I think would add unnecessary clutter. -- Michael Bednarek (talk) 01:44, 5 May 2017 (UTC)[reply]
Not every, but those that have [""] = "|border",. --Obsuser (talk) 17:16, 7 May 2017 (UTC)[reply]

Design

[edit]

Hi,

I propose to edit this template to add a better design. In the French equivalent template fr:Modèle:Portail, the size of the text and the width of the space taken by the text adapts to the number of portals added. The problem here is that if five portals are entered, their names are all squeezed in the smae space as one or two portals. This is a portal promotion measure.

--Railfan01 (talk) 07:28, 12 May 2018 (UTC)[reply]

 Done (see below) — hike395 (talk) 14:57, 20 December 2021 (UTC)[reply]

Proposed change to template

[edit]

I propose making two changes to the template (via Module:Portal bar):

  1. Add "nomobile" class to the portal bar, to make it not display on mobile WP. This would make it consistent with other navboxes that contain internal links at the bottom of articles.
  2. Only use the word "portal" once, at the beginning of the bar, rather than repeating "portal" for every link. This would make the template more compact, and more consistent with Template:Subject bar.

I've coded up these changes in Module:Portal bar/sandbox and Module:Portal bar/sandbox/styles.css. To demonstrate the proposal, here is a before/after:

Current
Proposed

You can see other examples at Template:Portal bar/testcases (the sandbox version has the proposed change).

What do other editors think of the proposed change? Suggestions to make the template better are more than welcome! — hike395 (talk) 13:39, 5 December 2021 (UTC)[reply]

I think the more compact design is an improvement, as is the slightly reduced icon size. -- Michael Bednarek (talk) 14:47, 11 December 2021 (UTC)[reply]
The text alignment in the Proposed bar doesn't look right, it seems as if the word Portals is middle aligned to its cell and the word Czech Republic is slightly higher (as are the other text labels).
Not repeating the word portal seems like a good idea, I'd want to check with non-English language readers to make sure it doesn't have any weird unintended consequences but it should probably work. -- 109.78.202.228 (talk) 20:49, 11 December 2021 (UTC)[reply]
I see (Chrome, Firefox) a slight misalignment the other way: the word "Portals:" seems a little bit higher than the icons and portal names. -- Michael Bednarek (talk) 02:04, 12 December 2021 (UTC)[reply]
I'd almost forgotten I'd switched to using Edge (mostly), I'm surprised that there would be any rendering differences from Chrome but fork that. Do we have any click data to show that readers actually use these portals or do they exist because editors like the look of them? (After reading WP:OVERLINK I tend to think repeating very similar links all over the place, like in a portal box or portal bar, is a waste of time, mostly harmless but pointless.) -- 109.78.202.157 (talk) 05:50, 12 December 2021 (UTC)[reply]

@Michael Bednarek and 109.78.202.157: I've reimplemented the layout using CSS Flexbox. I've attempted to make the baselines of all of the text strings line up vertically. Does this look good to you? (see above). — hike395 (talk) 17:39, 17 December 2021 (UTC)[reply]

As I wrote before, I think the changes are an improvement, and I can't see any alignment issues now. -- Michael Bednarek (talk) 03:29, 18 December 2021 (UTC)[reply]
 Done Thanks for checking! Upgraded the main template now. — hike395 (talk) 07:56, 18 December 2021 (UTC)[reply]

@Hike395, Michael Bednarek, and 109.78.202.157: Pardon me—I only just discovered the change. I'd prefer it if the content was still center-aligned within the bar, rather than left-aligned as it is now. It looks odd in the browser window of my (very wide) desktop display (the content of the above examples takes up less than a third of the bar). —DocWatson42 (talk) 06:20, 19 December 2021 (UTC)[reply]

@DocWatson42: Thanks for letting me know. You're right that I was optimizing for the case of smaller screens, which are more common nowadays. If you shrink your window horizontally, you can see how the bar responds to smaller screens. I also made Template:Subject bar call Module:Portal bar, and there were 20,000+ articles where a previous version of portal bar was left-aligned.
You're welcome. ^_^ —DocWatson42 (talk) 07:03, 19 December 2021 (UTC)[reply]
I can try and make a center-aligned version in the Sandbox (I'm still a newbie at modern CSS, so it might take me a number of attempts). In the meanwhile, it would be good to come to a consensus about left- versus center-aligned. Maybe left-aligned for small screens and centered for big ones? I like the left-alignment for small screens. I hope other editors will chime in. — hike395 (talk) 06:47, 19 December 2021 (UTC)[reply]
Left-alignment shouldn't matter for smaller windows, as the content compresses over to the left anyway (and then down when the window becomes narrow enough. I took Mr. Bednarek's advice and checked the above examples again.). —DocWatson42 (talk) 07:03, 19 December 2021 (UTC)[reply]
It turns out centering for large screens was quite easy (thanks to justify-content in CSS Flexbox). There's a working version you can look at in Template:Portal bar/testcases: the sandbox version has the centering for screens >768px across. I agree with Doc that this looks better. Any other comments or suggestions? — hike395 (talk) 07:17, 19 December 2021 (UTC)[reply]
Later: figured out centering on the small-screen version, too. That's now live in the sandbox. @DocWatson42 and Michael Bednarek: what do you think? — hike395 (talk) 07:59, 19 December 2021 (UTC)[reply]
Fine. I suppose having the content centred is a less severe change from the old format, so that shouldn't ruffle too many feathers. -- Michael Bednarek (talk) 10:42, 19 December 2021 (UTC)[reply]
 Done I promoted the sandbox CSS file to main. — hike395 (talk) 14:29, 19 December 2021 (UTC)[reply]
@Hike395: I'm sorry I missed this, though I'm replying because I've seen the results, which look good. You've (apparently) even fixed another problem—when portal bars were adjacent to Authority control templates there used to be a space between them, which I no longer see. —DocWatson42 (talk) 04:37, 22 December 2021 (UTC)[reply]
Yes, both {{Portal bar}} and {{Sister bar}} will now abut to all navboxes, and to each other. Let me know if you see any other odd spacing issues with them. — hike395 (talk) 05:32, 22 December 2021 (UTC)[reply]

Display on mobile?

[edit]

On Iran, I converted an instance of {{Portal}} to {{Portal bar}} (via {{Subject bar}}), and Moxy objected, because {{Portal bar}} did not display on mobile. In response to their feedback, I've turned mobile display back on for {{Portal bar}}.

Is there a consensus for whether {{Portal bar}} should display on mobile? What do other editors think? — hike395 (talk) 14:43, 20 December 2021 (UTC)[reply]

@Hike395: I'd like it. IMHO all content should be displayed in mobile mode (e.g. navbars, which are also currently invisible). —DocWatson42 (talk) 04:37, 22 December 2021 (UTC)[reply]
I gather that the mobile display for {{Portal}} just got turned on, too, so that seems to be the trend. — hike395 (talk) 05:29, 22 December 2021 (UTC)[reply]

"Template:Prb" listed at Redirects for discussion

[edit]

An editor has identified a potential problem with the redirect Template:Prb and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 January 5#Template:Prb until a consensus is reached, and readers of this page are welcome to contribute to the discussion. MB 15:38, 5 January 2022 (UTC)[reply]

Adjacent navboxes confusion

[edit]

The Charles III footer looked like this this morning:

This seems very easy to misread as saying that those fifteen links (Monarchy, Royalty, United Kingdom...) are the "related article" links that Wikipedia is offering the reader. (I moved the portal bar inside the navboxes collection in response to this issue, but I don't know if that's an appropriate fix.)

There's a similar example at Template:Portal_bar/testcases#Adjacent_navboxes:

A reader who doesn't know what a portal is can easily misread this as the blue box being a simple header for the five links below it. In both this and the Charles III case the blue bar has a "show" button, but a reader who believes that they're already looking at the list of articles wouldn't think that they needed to click it.

Is there a better way to display portal bars - either their design, or their MOS rules for placement - so that they can't be misread in this way? Lord Belbury (talk) 14:15, 14 September 2022 (UTC)[reply]

I definitely see your point. However, MOS:ORDER does currently indicate that {{Portal bar}} should go after the navboxes. If you want to move them somewhere else, we would have to get consensus at MOS:ORDER.
One possibility is to add a bit of whitespace before the Portal bar, if the previous object is a navbox. For example:
Is that enough? Is it too subtle? — hike395 (talk) 00:40, 15 September 2022 (UTC)[reply]
It's a bit subtle. You could try bringing the left and right borders in a bit, and/or changing the "Portals:" heading to a full, coloured box on the left of the template to make that the heading. Even that can still be misread in the Charles III example, though, which is unfortunate.
Interesting that MOS:ORDER says to put the portal bar after all navboxes. Does that mean that the Template:Portal_bar/testcases#Adjacent_navboxes example (with Slovakia below the portals) would never happen in an actual article? --Lord Belbury (talk) 09:13, 15 September 2022 (UTC)[reply]
It can happen if the test case could occur if the second navbox is {{Authority control}} (per MOS:ORDER). Let me play with the margin a bit in the sandbox. — hike395 (talk) 11:58, 15 September 2022 (UTC)[reply]
Later -- see above and below. Now there is 1em top/bottom margin and 5em right/left margin. What do editors think? — hike395 (talk) 12:09, 15 September 2022 (UTC)[reply]
Although it deviates from the style of normal bottom-material boxes, in light of the valid concerns above, I think it's good solution. -- Michael Bednarek (talk) 13:01, 15 September 2022 (UTC)[reply]
 Implemented --- this was an easy CSS change, we can revert if it turns out to be unpopular. — hike395 (talk) 01:52, 17 September 2022 (UTC)[reply]
While I understand why this has been done, I have to say, it's quite aesthetically unpleasing and makes an articles bottom section look rather messy. In all honesty, I don't see adequate proof that this was a major source of confusion in the first place. While it theoretically could be, the portal bar has been the same width and length as other templates for years without appearing to cause any issue. Personally, I trust most readers to be intelligent enough to realize that the "show" button will show more links, and the portal bar already looked different enough for readers to notice that they're two separate things. Krisgabwoosh (talk) 16:51, 17 September 2022 (UTC)[reply]
I would trust most web users to understand what the "[show]" button might mean on a plain rectangle offering a title but no other content: that it shows more content.
But under the status quo design, a portal bar immediately below a closed navbox looks a lot like an open navbox, with no suggestion to the user that any content has been obscured, meaning that they have no impetus to look for a way to access that information. I strongly doubt that many web users would be able to anticipate what the "[show]" button would do on a box like that, if they were reading it as a single box with a title and some links. They might interpret it as "show more links" if the button said "[more]", but I don't think they'd get there from "[show]". --Lord Belbury (talk) 19:15, 17 September 2022 (UTC)[reply]
My main issue is that the smaller bar size looks out of place and a bit disjointed under the navboxes. Like a puzzle piece that doesn't quite fit, y'know? Krisgabwoosh (talk) 21:34, 17 September 2022 (UTC)[reply]
@Krisgabwoosh: Is there a better way to do this? I agree it looks somewhat ugly now (see, e.g., Alcohol (chemistry)#General references). I suspect the best way to do this is to change MOS:ORDER to put {{Portal bar}} before the Navboxes. We could try that, but I bet it would be difficult to get consensus for the change. How about having a full-width box with a 1em gap? (see above for a test of that) — hike395 (talk) 21:36, 17 September 2022 (UTC)[reply]
Personally, I think it still needs to be demonstrated that this is a major source of confusion. But assuming it is, perhaps the white background could be changed to something more distinguishable. Alternatively, "Portals:", which at present is situated on the left hand side, could be moved to the top middle, almost as a header. Krisgabwoosh (talk) 21:55, 17 September 2022 (UTC)[reply]
I'd agree that the current version is more disjointed, but that doesn't really seem like an obvious negative, to me. Navbox links and portals are very different things, with the MOS emphasising that they aren't interchangeable. But conversely, yes, putting the "Portals:" pseudo-heading at the top would be another solution. Making this template look more like a full navbox, even giving the title bar a background colour, makes it harder to misread as being the second half of the previous navbox.
I'd love to see it demonstrated that the average Wikipedia reader even understands what a collapsed navbox is! That it's a thing they can expand to see links to other articles, rather than just being some kind of category banner where the text in the middle is sometimes clickable. Does Wikipedia have a UI team anywhere who run surveys on that kind of thing? --Lord Belbury (talk) 22:17, 17 September 2022 (UTC)[reply]

I don't know of a UI team that does surveys or tests, so it's up to us editors to guess. I've implemented a version in the sandbox which has "Portals" at 100% font size in the middle of the box as a header, see above. What do editors think of this? (It might look weird if there are only 1 or 2 portals) Does this solve the problem that Lord Belbury brought up? — hike395 (talk) 22:37, 17 September 2022 (UTC)[reply]

I think I like this new version much better. It keeps the portal bar in symmetrical alignment with the navboxes while differentiating the contents of the navbox with those of the portal bar. I'd support this if implemented. Krisgabwoosh (talk) 23:13, 17 September 2022 (UTC)[reply]
An earlier version of the portals bar had a centered heading, "Portals", and we moved away from that because it created unnecessary white space (see above #Design and #Proposed change to template, althought the examples there no longer reflect the original design or how it was changed). -- Michael Bednarek (talk) 06:08, 18 September 2022 (UTC)[reply]
I'm not really sure this differentiates it enough; it has the same issue where the closed navbox above it looks like its header, with "Portals" still looking like a subheading within that box. I think the template either needs punching up to the same weight as a navbox (with a solid coloured title, clearly conveying the idea that all of these little boxes at the end of the article have a heading and some content), or to looking nothing like a navbox (which the wider margin seems fine for).
On the 1-or-2 portal issue, isn't {{Portal}} generally used instead in those cases? --Lord Belbury (talk) 07:31, 18 September 2022 (UTC)[reply]

@Lord Belbury, Hike395, Michael Bednarek, and Krisgabwoosh: Did the changes discussed above intend that the Portal bar be narrower than the width of the page? It's currently displaying for me (latest macOS and version of Firefox in desktop mode) as somewhat narrower than full width (e.g., in John Gamble (baseball)#External links), as are the first two examples above..— Preceding unsigned comment added by DocWatson42 (talk • contribs) 06:53, 18 September 2022 (UTC)[reply]

Yes, this was an intentional change to the template. I guess the thread doesn't make much sense when examples get changed retroactively: it was introduced with Hike395's Now there is 1em top/bottom margin and 5em right/left margin. What do editors think? above, and then implemented. --Lord Belbury (talk) 07:18, 18 September 2022 (UTC)[reply]
I don't like the presently implemented change at all. The less than full width portal bar just looks weird, and doesn't really solve the confusion problem. The simple solution to the problem identified at the start of this section is to modify MOS:ORDER to indicate that a (full width) {{Portal bar}} should go before the navboxes, not after them. As the present MOS:ORDER sequence has already now been identified as confusing, it shouldn't be difficult to obtain consensus for such a modification. Bahnfrend (talk) 07:24, 18 September 2022 (UTC)[reply]
We could give in and go the route we went with Authority Control, formatting the Portal bar to appear as though it's another navbox. I.E.: Krisgabwoosh (talk) 10:54, 18 September 2022 (UTC)[reply]
There clearly isn't a consensus for the narrower box, so I've reverted to status quo ante.
@Krisgabwoosh: If we turn {{Portal bar}} into a navbox, it will not get displayed on mobile. The current consensus is that Portal links should appear on mobile. If I understand correctly, the filter inside of MediaWiki is on the "navbox" class itself. We would have to copy the entire navbox CSS class into another class, and then maintain the two to be identical. That sounds like a lot of maintenance.
From this discussion, I don't think there's an easy visual method that distinguishes the portal box from the previous navbox and is acceptable to many editors. I will take Bahnfrend's advice and start a discussion to change MOS:ORDER. I will ping everyone on this discussion over there.
— hike395 (talk) 15:43, 18 September 2022 (UTC)[reply]

Discussion of where to place this template

[edit]

A discussion of where to place {{Portal bar}} on articles is now open at WT:MOSLAYOUT. Please feel free to join the discussion! — hike395 (talk) 19:41, 18 September 2022 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Portal_bar&oldid=1241354905"