Bounds for interactivity
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 554
- Forks
- 30
- Avg merge
- 17h 27m
- Merged PRs (30d)
- 8
Description
This issue is a discussion ground for what we think of regarding interactivity to sharpen our thoughts before we begin to design it. Interactivity is a spectrum and we are not aiming at the freedom D3 brings - but where are we aiming then?
I have strong feelings around the proper "grammar" api when it comes to interactivity but I'm not sure ggsql is for that (it does require an element of interpreted programming language to really work). As I write this I think for ggsql there are 3 main interactive areas to address which will cover the magic 80% of use cases (or more):
- Filtering
- Hovering tooltips
- Zoom and pan
These are all in the bucket of cookie-cutter interactivity that I dread but realistically it is perhaps what we should aim for
Contributor guide
No contributing guide indexed for this repository
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
No files, tests, or entry points are named. Start by reading the issue discussion and clarify which interactivity area—filtering, hover tooltips, or zoom and pan—is in scope, then define the intended bounds and acceptance criteria before implementation begins.
Written by the indexing model from the issue text.
Assessment
- Domain
- data-visualization
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100