User:Pi zero/dialog/punch list
Jump to navigation
Jump to search
- documentation:
- 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 — 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
- 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)