![]() | This page is currently inactive and is retained for
historical reference. Either the page is no longer relevant or consensus on its purpose has become unclear. To revive discussion, seek broader input via a forum such as the village pump. |
This page summarizes design work on and surrounding the portal model generated by {{ Basic portal start page}}, including design objectives, elements, and tools based on this model, which is intended as a one-page fully automated integrated design. Other designs and design templates are certainly possible and encouraged. This page however, focuses on just the one, being the current de facto standard for generating new portals and conversion of existing ones.
On the talk page, we discuss all aspects of portal design.
Below, we are concerned mostly with automation level 1 – that is, once the template is substituted on a page and saved, everything works without any further input or editing. Automation level 2 would be a program that asks for the name of the portal (or portals) to be created, or that starts a page (and title) upon the click of a redlink, and places the template and whatever else is needed, automatically. Automation level 3 would be a program that just does the job on its own, without asking (or optionally, asks for confirmation first); it would explore Wikipedia and figure out what subjects need to be covered in the portal system and make the portals for those.
Also needed is a portal configuration tool, that provides editors with an interface for easily changing a portal's various parameters section-by-section, but that's being handled on another page.
One of the two main design objectives here is to create a one-page portal, with no portal subpages. This model accomplishes that.
The other main design objective is to make a portal page that is fully automated, meaning it is complete and operational once the generating template has been substituted onto the page, using "subst:". This has yet to be fully achieved, and is covered component-by-component, below.
To help track progress, the following indicators have been used:
Automated indicates the component is fully automated.
An indicates that the component still needs design/programming work.
This has 10 core section components.
To get up and running and fully operational with an automated design as quickly as possible, work is being concentrated on the minimum required section components needed for a "complete" portal. Once this model is completed, it could be used to fill in awkward gaps in the whole collection with new portals. Of the 10 core section components, these eight are sufficiently automated:
Note that Selected images is limited in that it produces an error if there are no images on the sourcepage provided, and if there is only one image, then it's not really a slideshow (rendering the controls functionless). Needs more work (to achieve auto fill).
That leaves the following 2 sections that needs further development before "complete" portals can be created conveniently:
Both of these sections currently fill automatically only if there is an eponymously named navigation footer template, from which they extract the needed data.
Plans and progress on these features are covered in #Design objectives: automated core components, below.
Other components can be added to the model, and to specific portals, later. Speaking of which, see further below...
For conversion of existing portals, we need to go a few steps further, and automate the remaining components commonly found in portals, which are presented, along with anything new, in the #Optional & possible future automated components section below.
To simplify maintaining and improving portals, a tool (user script) is being created to make adding new sections to portals easier, as well as for managing the sections already there. It might do things like:
Research and development (mostly research at this point) is underway. See PortalTool.js
{{
Portal description}}
– add a standard
short description Automated
{{
Portals browsebar}}
– present navigation bar with links for browsing portals by subject
Automatically insert a transclusion of an excerpt from the corresponding lead article.
This is done automatically using {{ Transclude lead excerpt}}, with some arguments preset, like this:
{{Transclude lead excerpt| {{PAGENAME}} | paragraphs=1-3 | files=1,2 | more=}}
It catches most images, but misses some in infoboxes. It is sufficiently proficient to be used while it is being further refined to work even better. Report missed pictures (on the talk page) as you come across them.
Of course, the arguments can be adjusted after a portal is created.
There are two approaches here:
The first one listed is likely to replace the second one completely, because it is the basis of a new paradigm in portal design and purpose. Portals using slideshows to show content introduce a new form of browsing to wikipedia. Such portals are no longer for mere "topic tasting"; by supplying multiple excerpt slideshow frames, portals can be used for surveying an entire subject.
The paradigm shift is nearly here.
{{ Transclude excerpts as random slideshow}}
{{ Transclude files as random slideshow}}
{{ Transclude list item excerpts as random slideshow}} and {{ Transclude linked excerpts as random slideshow}}
{{ Transclude list item excerpt}} and {{ Transclude linked excerpt}}
Automatically provides "Did you know?" blurbs, in a conditional "Did you know?" section (that shows up only when there are entries to display).
Being conditional makes it suitable for automation, because we won't be generating portals with empty DYK sections.
Automate DYK item display with {{ Transclude selected recent additions}}, that pulls blurbs on specified topics from the monthly subpages of Wikipedia:Recent additions (the Did you know? archives).
The code used for this:
<!--CONDITIONAL "Did you know?" SECTION - ONLY SHOWS UP WHEN THERE ARE ENTRIES TO DISPLAY -->
{{Transclude selected recent additions | {{PAGENAME}} | months=12 | header={{Box-header color|Did you know...| mode= }}|max=6}}
Problem: Search string sometimes returns false matches. We need a way to refine this feature to minimize false matches.
There are a couple template-based potentially automatable solutions so far:
{{ Transclude files as random slideshow}}
{{PAGENAME}}
, for example.{{ Random slideshow}}
Automatically provides news content, in a conditional news item section (that shows up only when there is news to display)
Being conditional makes it suitable for automation, because we won't be generating portals with empty news sections.
So far, we have the template {{ Transclude selected current events}}, that pulls items from the daily subpages of Portal:Current events, based on a search string. To make it conditional, use the "header=" parameter.
The code used for this:
<!--CONDITIONAL NEWS SECTION - ONLY SHOWS UP WHEN THERE IS NEWS TO DISPLAY -->
{{Transclude selected current events | {{PAGENAME}} | days=30 | header={{Box-header color|In the news| mode= }}|max=6}}
News coverage is scant for many subjects, with news reports few and far between. Hence the need for a disappearing section.
New news sources are needed.
Place corresponding category tree
Uses this code:
{{#tag:categorytree|{{PAGENAME}}}}
One of the purposes of portals is to provide a bridge between the encyclopedia proper and the Wikipedia community (project space). One of the premiere knowledge oriented features of project space is the WP:REFDESK, a department where volunteers answer reader's knowledge-related questions, like they do at the reference desk in a brick and mortar library. A section on portals leading to that department provides a valuable bridge and knowledge resource applicable to most subjects.
Here's some sample wikicode:
Do you have a question about {{PAGENAME}} that you can't find the answer to?
Consider asking it at the [[Wikipedia:Reference desk|Wikipedia reference desk]].
This is the WikiProject bridge section, to provide a link to the corresponding WikiProject, if there is one.
This section can be encoded in the portal generation template to show up only if the WikiProject page exists. (See mw:ifexist.) Like this:
{{#ifexist: Wikipedia:WikiProject {{PAGENAME}}
| {{Box-header colour | Get involved}}
For editor resources and to collaborate with other editors on improving Wikipedia's {{PAGENAME}}-related articles, see [[Wikipedia:WikiProject {{PAGENAME}}|WikiProject {{PAGENAME}}]].
{{Box-footer}}
|
}}
This feature automatically places a like-named navigation template here, and strips out its border formatting so that it blends into the portal.
Unfortunately, navigation templates vary in availability (some topics have them, and the rest don't). They also vary in quality, and in completeness.
An automatic method to generate navigation templates is needed. Maybe a script could be developed to generate a navigation template from a corresponding outline or from relevant categories, or both.
Another problem is that navigation footer templates do not follow a standard naming convention, which makes it so that it often doesn't match the name generated via magic word in the portal.
{{
Wikimedia for portals}}
The following Wikimedia Foundation sister projects provide more on this subject:
Develop template to insert a section for a relevant selected item, including section title.
For example, Portal:Dogs may have a section entitle "Selected dog breed".
Can quotes be pulled in from WikiQuote?
(Pictures get pulled in from WikiCommons, so why not?)
Apply {{
User:JL-Bot/Project content
}}
to display recognized content (featured articles, good articles, featured pictures), to portals that have such items falling under its subject.
Note, that JL-Bot finds recognized content by looking for template transclusions (via What links here) and/or categories (provided as arguments by the user), and then takes the combined list of pages on those and compares it with each of the recognized content categories. The matches it places in the corresponding subsection in the Recognized content section. There doesn't appear to be a restriction on which categories or templates can be specified, or on how many of each or either can be included.
One way to tell which portals have corresponding recognized content is to have a recognized content section on every portal talk page. Then a list can be made and preparsed in AWB to show all the portals talk pages for which the recognized content section doesn't come up empty. Then you edit that list in a sandbox with search/replace, to turn the talk page titles into portal titles. Then you use AWB to install a Recognized content section on all those portals that don't already have one.
This section is for listing other portals that are subtopics of the portal.
Develop a way to automatically gather and place the names of subportals here (without icons).
Currently, this can only be done by hand, though category harvesting support may be available in the future. Though populating the categories will still likely be a manual process. Eventually, all portals should be categorized.
Develop a way to automatically gather and place the related portal names and their icons here.
So far, we have the semi-automated {{ Related portals2}}, that needs just the subject names as parameters, and does the rest automatically.
Done Automated
This column-balancing feature makes the bottom border of the bottom-most boxes of adjacent columns match up. The difference in white space at the end is distributed amongst the boxes in the column with that extra white-space.
Done Automated
{{
Box-header colour}} replaces {{
Box-header}} and {{/box-header}}
, both of which relied on subpages. {{
Box-header colour}} does not, and it allows the color to be set, and even varied (as different for different sections), on the portal base page.
All colors are supported, which by may be specified by web color name, or by hue (as a number from 0 to 359), or by hex triplet. The template automatically adjusts the specified colour to ensure sufficient contrast, per MOS:COLOUR.
The color set is for the header background color. Currently, the box background color is set automatically based on the header background color.
When no colour is specified, a "random" colour is chosen by the template, so it is thus automated. Colour-randomization could also be handled at initial portal creation, by setting |colour=
to a random number between 0 and 359 (e.g. {{subst:#invoke:random|number|359|same=yes}}
)
{{
Box-footer}} replaces {{/box-footer}}
, which was almost exactly the same thing but placed on a subpage.