Wikipedia:WikiProject Portals/Design

For a simple overview, see Wikipedia:WikiProject Portals/Components.

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:

Y Automated indicates the component is fully automated.

An N indicates that the component still needs design/programming work.

Approach

Develop simple "complete portal" model

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:

1. Introduction section

2. Categories section

3. Associated Wikimedia section

4. Need help?

5. Get involved

6. Selected images (works correctly only if there are at least 2 images on the sourcepage)

7. In the news

8. Did you know

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:

9. Selected articles

10. Topics

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...

Develop an extended portal model to encompass existing portals

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.

• Selected item
• Transclude lists?
• Selected quotes
• Anniversaries (On this day)
• Recognized content
• Related portals

Going beyond the template: building a portal tool

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:

• Add a new section
• Add a source to a "selected" section
• Add an article to a "selected" section
• Add a picture to a "Random slideshow" section
• Reach automated level 2, by creating the page specified, if one doesn't already exist
• Etc.

Research and development (mostly research at this point) is underway. See PortalTool.js

Design objectives: automated core components

{{Portal description}} – add a standard short description Y Automated

{{Portals browsebar}} – present navigation bar with links for browsing portals by subject Y Automated   It looks like this:

(Add random portal link to browsebar) N pending

Introduction Y Automated

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.

Selected general articles N Semi-automated

There are two approaches here:

1. Excerpt slideshow (subject surveying)

2. Present one excerpt per page purge (topic tasting)

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.

Excerpt slideshow approach ("Selected articles")

The paradigm shift is nearly here.

{{Transclude excerpts as random slideshow}}

This template accepts pagenames as arguments and doesn't quite enable the paradigm shift. The individual page names need to be fed to it as arguments (via typing or copying/pasting, which are slow), and it is limited to displaying only 50 pagenames per slideshow. (More than 50 page names can be specified, but only a random subset of 50 will actually be displayed in the slideshow.)

{{Transclude files as random slideshow}}

This template is awesome, for showing pictures, as it accepts multiple source page names. This is what we need for text excerpts. Using one for pictures and another for exceprts, these would facilitate the paradigm shift. Either or both of the following could be used to display excerpts from multiple source pages:

{{Transclude list item excerpts as random slideshow}} and {{Transclude linked excerpts as random slideshow}}

These two new (as of July 2018) templates could bring about the paradigm shift, because they accept source pagenames (and sections) rather than article titles as arguments. This makes them far easier to implement, as source pages across subjects generally follow naming patterns and are therefore subject to automation. They are still limited to 50 excerpts per slideshow. All this makes them survey tools.

Topic tasting approach ("Selected article")

{{Transclude list item excerpt}} and {{Transclude linked excerpt}}

These two templates show one excerpt per page purge. But, they are easy to implement and automatable because they accept source pagenames (and sections) rather than article titles as arguments. This makes the old-style of portal somewhat automatable. (The "standard" names won't match all the time, but enough to speed up portal creation considerably).

One nice feature about these is that their wikicode is virtually identical to that of the two planned templates mentioned above. Only their titles will differ. Which means, when the time comes, they will be able to be swapped out very easily with the slideshow versions by a simple search/replace operation.

Did you know? Y Automated
N needs improvement

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.

Selected images N Semi-automated

There are a couple template-based potentially automatable solutions so far:

{{Transclude files as random slideshow}}

This one is pretty close to automated because it accepts source page names (where it gathers the filenames from) rather than the filenames themselves. For sets of subjects that have filenames stored in standard-named locations, this could work without editor input, if the locations were some variation of {{PAGENAME}}, for example.

{{Random slideshow}}

This is the older method, which requires filenames as arguments, and it could possibly be auomated, if a bot were developed to populate it with filenames. Programming the gathering of filenames is problematic, due to lack of standard structure in the naming of the pages or categories where the filenames are stored or presented.

In the news Y Automated
N needs improvement

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.

Categories Y Automated

Place corresponding category tree

Uses this code: {{#tag:categorytree|{{PAGENAME}}}}

Need help? Y Automated

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]].

Get involved Y Automated

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}}
 |
}}

Topics Y Automated
N needs improvement (depends upon availability of navbox 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.

Associated Wikimedia Y Automated

Provide links to the portal's subject in sister projects using {{Wikimedia for portals}}

It looks like this:

The following Wikimedia Foundation sister projects provide more on this subject:

• 

  Commons
  Free media repository

• 

  Wikibooks
  Free textbooks and manuals

• 

  Wikidata
  Free knowledge base

• 

  Wikinews
  Free-content news

• 

  Wikiquote
  Collection of quotations

• 

  Wikisource
  Free-content library

• 

  Wikiversity
  Free learning tools

• 

  Wiktionary
  Dictionary and thesaurus

Portals footer bar (directly above) Y Automated

Optional & possible future automated components

• Selected item
• Transclude lists?
• Selected quotes
• Anniversaries (On this day)
• Recognized content
• Subportals
• Related portals

Selected item N Semi-automated

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".

Selected quotes N pending

Can quotes be pulled in from WikiQuote?

(Pictures get pulled in from WikiCommons, so why not?)

Recognized content N Pending

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.

The hard part is how to standardize or otherwise automate the selection of categories and templates to use. Not all portals have corresponding WikiProject templates. And their corresponding navigation templates do not have standard naming conventions. We are trying to get away with not having to enter these by hand. Categories are segmented, with no easy way of gathering all relevant categories (that I know of).

Subportals N Pending

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.

Related portals N Semi-automated

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.

Design objectives, by layout component

Flex columns

 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.

Box-header colour

 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

{{Box-footer}} replaces {{/box-footer}}, which was almost exactly the same thing but placed on a subpage.