User:Pi zero/dialog/punch list

From Wikinews, the free news source you can write!
Jump to navigation Jump to search
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)