← 3c PAL


Content:

  • docx files that are detailed and can be realistically maintained (some of the official demos are outdated).
  • videos are nice, but they get outdated quickly and are impossible to update.
  • the new user gets totally lost in the complexity of the UI dialogs; the demos need to be accurate and focus on minimal demo app complexity (its not about creating realistic apps; its about helping newcomers know how to use the product)
  • demos should start out with a race to the finish; then go back and embellish; then repeat this process. this is how to learn…. not a drawn-out example (the longer it is, the more likely the student will hit a roadblock).
    • if possible, first provide a full setup (this is one the best aspects of the Palantir demos; they often do this). test and verify. then student attempts to modify.
  • the student documents their demos (like I did), and then goes back later and tries to modify things (but keeps a carefully organized set of versions in case things go wrong)
  • Organizing docx files into a conceptual hierarchy.
  • Numbered headings, steps, etc.

  • Core concept diagrams (what we are doing in this demo).

  • Document in docx (MS.Word) files. These are detailed and can be realistically maintained (the official demos seem to not be updated often; videos are nice, but they get outdated quickly and are impossible to update). My personal opinion (and the future direction of my own demos) is that demo documentation should rely more on describing how to work with AI to do hands-on step-by-step demos (not describing the actual details).
    drones

  • Use AI (internal PAL AIP/FDE) as much as possible (avoid docs and tutorials if possible; I first started to do demos based on AIP/FDE chats in demo D8).
    drones


26.0720 (v1 26.0720)