User:Pi zero/dialog/punch list

compare gadget production gadget experimental gadget
compare receive production receive experimental receive
compare do js production do js experimental do js WN:Dialog/do/test
compare receive talk production receive talk experimental receive talk
compare wikilisp production wikilisp experimental wikilisp
compare wikilisp doc production wikilisp doc experimental wikilisp doc
  • documentation:
  • 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)