이러한 위시리스트 요청을 하게 된 계기는 무엇이었나요?
JMP "흐름"을 구축하는 더욱 상호 작용적인 방법을 보고 싶습니다.
어떤 개선을 원하시나요?
저는 이 제안에 대해 약간 갈등을 느낍니다. JMP가 하는 일(데이터 가져오기, 데이터 수정, 플랫폼에서 데이터 분석, 추가 분석 수행, 계속 진행...)과 JMP가 지향하는 방향(향상된 로그, Workflow Builder)에 약간 어긋나기 때문입니다. 하지만 저는 여전히 이것이 JMP 사용자에게 도움이 될 수 있는 것이라고 생각합니다. Workflow Builder의 진화 또는 Workflow Designer로서의 추가 기능으로 볼 수도 있습니다.
저는 이와 비슷한 것이 이미 제안되었을 것이라고 생각합니다(그리고 저는 개발자들과 이에 대해 논의했을 수도 있고 어느 시점에 고려되었을 수도 있고, 더 이상 기억나지 않습니다)... 하지만 JMP에 플랫폼을 추가하면 JMP 플랫폼을 캔버스로 끌어서 놓아 분석 흐름을 구축할 수 있습니다. 저는 JMP가 캔버스 외부에서 이에 필요한 대부분의 기능을 이미 갖추고 있다고 생각합니다. 플랫폼 아이콘, 훌륭한 플랫폼 런처가 있으며 플랫폼 결과는 스크립트에 저장됩니다. 워크플로도 있지만 JMP에서 작업하는 동안 빌드되며, 이 플랫폼에서 작업하게 됩니다(또는 워크플로가 이러한 유형의 그래픽 뷰를 빌드할 수 있을 것입니다). 워크플로도 단계별로 진행되지만 그렇지 않더라도 병렬로 진행되는 것으로 시각화할 수 있습니다.
내가 말하는 바를 아래에 작은 예로 들어보겠습니다.
데이터 테이블을 열고, 몇 개의 요약 표를 만들고, 각 표에서 그래프를 하나씩 만든 다음, 이를 대시보드로 결합하는 작업 흐름이 있습니다.
여기에는 첫 번째 테이블에서 기본적으로 두 개의 별도 경로가 있으며, 두 경로 모두 요약 + 그래프 빌더를 만들고 그래프 빌더와 함께 대시보드로 다시 결합합니다.
"열기" 동작을 캔버스에 드롭하면 좋을 텐데, 그러면 Open()과 같은 파일 선택기를 열고, 그 다음 요약을 캔버스에 드롭합니다. Open에서 해당 요약으로 줄을 드래그하면 요약 플랫폼이 시작되고, 이를 채울 수 있습니다. 결국 시각적으로 다음과 같은 것을 볼 수 있습니다.
또는
사용자가 더블클릭(또는 마우스 오른쪽 클릭 후 편집 선택)하면 플랫폼을 수정할 수 있습니다(플랫폼 재시작). 물론 이는 그 후 단계를 망칠 가능성이 있지만 어느 정도 검증될 가능성이 큽니다.
사용자는 또한 입력과 출력을 갖는 스크립팅 블록을 가질 수 있습니다. 입력은 다른 블록에서 가져온 값에 따라 생성됩니다(상수를 어떻게 처리해야 할지 잘 모르겠고, 아마도 "상수" 블록이 있을 것입니다).
왜 이 아이디어가 중요한가요?
많은 (로우코드 및 노코드) 애플리케이션이 이런 유형의 드래그 앤 드롭 옵션을 제공합니다(또는 이것이 유일한 옵션일 수도 있음). JMP를 사용하면 이런 유형의 시각적 워크플로를 갖는 데 필요한 대부분의 기능이 이미 있다고 생각합니다(플랫폼은 이미 테이블에 의존하고 있으며, 이를 실행하기 위한 스크립트를 생성할 수 있습니다(적어도 대부분은 가능합니다)).
