Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Find a way to fix documentation duplication #23

Closed
eozd opened this issue Sep 20, 2019 · 4 comments · Fixed by #735
Closed

Find a way to fix documentation duplication #23

eozd opened this issue Sep 20, 2019 · 4 comments · Fixed by #735
Assignees
Labels
Documentation Improvements or additions to documentation New Feature New feature

Comments

@eozd
Copy link
Contributor

eozd commented Sep 20, 2019

Feature Description

Our current documentation is split into three pieces:

  1. function docs
  2. matlabbatch docs
  3. user manual

We maintain these three pieces by literally copy-pasting the documentation. Since this is very inefficient and error-prone, a better way to handle this process is required.

@eozd eozd added Documentation Improvements or additions to documentation New Feature New feature TODO labels Sep 20, 2019
@eozd eozd modified the milestones: v4.2.1, v4.3.0 Sep 20, 2019
@irojkov-ph irojkov-ph modified the milestones: v4.3.0, v4.4.0, v5.0.0 Apr 1, 2020
@irojkov-ph
Copy link
Contributor

Sam's handover comment:

Documentation wise, due the nature of the matlabbatch structure that is used for the GUI, I can see a possibility for using this to keep a single source of truth for docs. A script would take the cfg, and traverse through each batch value and output some sort of markup depending on if it's type, e.g. branch, entry, const etc. This could be latex or html, or markdown. The major drawback being that this would mean the cfg help texts were gospel and whatever was there should be shown in the docs, which makes extending with mathematical notation or finer details tricky.

@irojkov-ph irojkov-ph modified the milestones: v5.0.0, v5.1.0 Sep 9, 2020
@teddychao teddychao self-assigned this Mar 22, 2021
@teddychao teddychao removed this from the v5.1.0 milestone Jun 7, 2021
@teddychao teddychao removed the TODO label Jun 7, 2021
@dominikbach
Copy link
Contributor

@teddychao it seems this is solved now?

@dominikbach
Copy link
Contributor

dominikbach commented May 12, 2024

Suggestion for improved documentation management:

Function help texts

Definite reference are the function help texts. This is how Matlab works in general, and it is easy for users to access them. In addition, we could/should build a complete online reference from the help texts, see #642 . This would require the following steps:

  1. Improve function help texts (Dominik).
  2. Create online reference (similar to https://bachlab.github.io/vrthreat/reference/index.html).

Matlabbatch GUI

GUI can use function help texts whereever possible. pspm_help could serve to parse the help texts and make them accessible to the matlabbatch GUI. Where additional information is needed, this can be managed in (and pulled from) a markdown file. This would require the following steps:

  1. Improve pspm_help such that arguments is a struct variable where field names correspond to argument names (this should be flattened, i.e. options.overwrite and datafile would be on the same level).
  2. Write a test that simply verifies error-free parsing of all pspm function help texts (to avoid accidentally breaking the structure of a help text, which would otherwise go unnoticed in the test suite).
  3. Implement these arguments in GUI (Dominik).
  4. Manage additional help texts (Dominik).
  5. Create pspm_cfg_selector_... functions for common GUI elements (datafile, overwrite, ...) similar to pspm_cfg_channel_selector.
  6. Combine these help texts into a matlabbatch reference document.

PDF manual

Split background information from GUI reference for better management.

@teddychao
Copy link
Contributor

My comments are as following,

  1. I really agree with Create online reference (similar to https://bachlab.github.io/vrthreat/reference/index.html). I think PsPM users will tend to use the online document rather than the PDF version if both are available since they can navigate between pages using browser with less clicks. The online version can also be easier to maintain with R markdown.
  2. We were looking at a method to upload PsPM code help text to document (either PDF/Lyx files or other format). I am unsure if the method has been identified now. I think this would (1) avoid potential conflicts or confusion between the code help text and PDF/Lyx files; (2) get real-time updates from the backend so users can find the latest information; (3) can get cross-reference so users will find the related information with a simple click. I am happy to look into if a method has not been determined.
  3. For Matlab-batch GUI, I agree with the comments. I think putting options.overwrite and datafile in the same level will reduce coding complexity, and the exported struct variables will be sorted well. I do not remember the explicit rules I set for writing those help text and reading to .mat files. I will have a look and see if I can make a list, if this is useful.
  4. I think "Create pspm_cfg_selector_... functions for common GUI elements" is a very sensible task. It can improve code robustness and make the GUI more consistent. I am happy to start when I should focus on it.
  5. For the "Split background information", my understanding is it wants to build a new document for the background information? I can do it if my understanding is correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation Improvements or additions to documentation New Feature New feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants