NASA-AMMOS / NASA-AMMOS/plandev-ui
"Modified" dot is misleading when using scheduling
Nobody has claimed this yet.
- Dominant language
- Svelte
- Stars
- 42
- Forks
- 14
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 10
Description
Checked for duplicates
Yes - I've already checked
Alternatives considered
No - I haven't considered
Related problems
There are three colors of dots inside parameter fields to indicate that a parameter 1) comes from the mission model, 2) was modified by the user, or 3) comes from a preset.
When an activity is added to the timeline via a scheduling goal, Aerie considers it "modified" and applies an orange dot. The effect of this was rendering the color dot system useless (during TT-6) because users couldn't in fact tell whether they had modified something themselves.
Describe the feature request
For Clipper, it's not clear how useful "mission model default" as a category is. What seems more useful for users is: "modified in current session" so they can see if they inadvertently made a change.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the parameter-field dot rendering and the handling of activities added through scheduling goals. Review how the three dot categories are currently determined and clarify the intended Clipper behavior before changing it. Done means users can distinguish changes made in the current session from values introduced by scheduling.
Written by the indexing model from the issue text.
Assessment
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100