User:Pi zero/dialog/punch list


 * documentation:
 * Categories.
 * Attribution (consult Neutrality).


 * streamline handling of missing images in galleries; see Total lunar eclipse occurs in July 2018.


 * alternative verb to calculate action of a form without actually altering the page (and without requiring authentication).


 * visibility of collapsibles isn't part of saved state.


 * advice exception tables
 * items list documentation: internals, examples, documentation of subtemplates
 * for each exception, one wants to know what is excepted, how, why, when, and by whom
 * one wants to know these things when facing that specific decision, and when considering the general rule
 * get and set &mdash; get is presumably a simple exercise in evalx, but set may involve both a form for the action and a preview screen to commit the entry and perhaps something after that


 * context-sensitive presentation of controls
 * The basic model here is that, on a page where assistance is to be offered, a template is called that provides context-sensitive service.
 * The template is told to apply a particular set of candidate services.
 * Each service has, conceptually, three parts:
 * Furthest downstream is what it does if selected. Some sort of offering of a service, presumably.
 * Prior to that is some sort of predicate used to determine whether the service should be offered.
 * Furthest upstream is a list of things the predicate needs to know in order to make its decision.
 * Design questions:
 * What should be done if the information needed by a predicate is not available?
 * What kinds of information should a predicate be able to request?
 * The three most basic items of information that might be provided are: the name of the target page; the content of the target page; and the list of user groups to which the current user belongs. Interestingly, the first of these is already available before any check-for-services button is clicked.  The second and third are not available until the check-for-services button is clicked.
 * Although further information might be requested, doing so could greatly complicate things, so it might make sense for the providing of such information to be done by a service provided when appropriate. The central mechanism might take care of feeding the information back into the facility, though.


 * structural markup-edit
 * navigate parse tree of page
 * nagivate up and down through template calls
 * follow parameter values up and down through template calls


 * plan imagemap
 * User:Pi zero/Archives
 * regional map
 * corrections
 * curation


 * add a meta-examination facility for extracting info about the state saved on the top(?) of the stack
 * other state-change buttons
 * w-izing tool
 * possible additional functions
 * page by revid
 * move
 * protect
 * sight
 * delete


 * technical challenge for wizards
 * when looking at a page, figure out where a particular visible feature is defined (coping with conditional transclusion)


 * principles for low-level tool design
 * avoid complicated prevention measures


 * principles for wizard design
 * The know-how must be represented in a form that can be added to by the community.
 * The technical operations must be represented in a form that's human-readable, so somebody can manually fix things if they go wrong.
 * In general, one wants to have a set of subtasks, with some needing to be done before others, and with some being optional, and a way to keep track of which have been done.


 * multiple uses for identification of article authors
 * when IP tries to submit for review, only allow if created by IP
 * perhaps warn if submitted for review by non-author
 * during review, offer info to reviewer about author(s)
 * when committing review, notify author(s)


 * Special:PrefixIndex/User:Pi zero/dialog/