Mega-gissue: everything from TODO.md

[dreeves]

We used to keep our task list in a TODO.md file in the root directory of this repo. Now it's here, where we can clean this up and spawn gissues for anything we may still care about.

Pre-deployment UI decisions

Prioritized To-Do list for the editor/client-side graphs

• Exes and pencils like in old.beeminder.com for the [graph matrix] rows with auto-ungray (also probably exes for deleting [graph matrix] rows. or maybe '+' and '-' for that?)
• Selector for multiple overlapping node deletion buttons
• Implement a smoother editing mechanism for [red lines] with lots of breaks.
• True retroratchet when you originally made your rate way too conservative and want the [red line] to match your data
• Mini-editor for goal creation
• Replace table checkmarks with proper icons and implement auto-enable on click
• Test out how svg and png generation would work on a node.js server with jsdom?
• Don't draw the actual [BRL] left of tini. We do want to be able to scroll left of tini and add new knots and make tini be earlier. Just show the actual [BRL] starting at tini. It's also possible to have datapoints to the left of tini, which is fine.
• Day of week for "today" should account for the Beeminder deadline. For example, if it's Friday night at 8pm and I've done my pushups that were due at 7pm then from Beeminder's point of view it's now Saturday and it's an eep day again because Saturday's pushups are due in less than 24 hours. This seems counterintuitive to call it Saturday when it's clearly Friday but it turns out to be a can of worms to do anything other than treat the Beeminder deadline as the end-of-day.
• Enable field on click
• Table headers and the first row should always be visible
• Last (goal) row should always be visible or somehow highlighted
• "Schedule a break" functionality (options: insert or overwrite)
• Bug: when you drag a knot and it bumps into another knot it loses the slope it was supposed to be keeping fixed
• Show the rate units somewhere (now shown in the table header)
• Try out ways to "freeze" selection of [red lines], knots, and dots to preserve highlighting of corresponding table entries (Done: selection mechanism for knots, dots, and [red lines])
• Inverse of autoscroll so you know what part of the graph you're editing when you edit graph matrix rows (now handled through the selection interface)

Quibbly issues to try to make the overall graph aesthetics match or exceed Matplotlib:

• Show flatlined triangle datapoint on top of other points
• Watermarks quibble. Try making the vertical gridlines display on top of the watermarks like matplotlib does it? And a bit bigger puffier font might help too.
• (Done as much as I could) More on watermarks: I think the graph canvas should be divided into 4 quadrants and the watermarks should take up as much as possible of their designated quadrant as possible
• (Not sure if it's worth the effort) Frame around the graph with tickmarks only pointing inward?
• (NIX) Lower priority since the blue/green aura isn't turned on for most graphs but I really like how in matplotlib it's green where it overlaps the YBR (cuz yellow and blue make green)
• (CNR) Example of svg with artifacts (only appears in chrome; firefox and safari display it fine): svg-with-artifacts.svg

General

• Should we allow adding duplicate [red line] knots (helps with subsequent editing, so probably yes) [yes]
• Should the getRoad() function automatically eliminate duplicate knots [probably yes]

Graph related questions

• Whether to display all datapoints by default or only the last n days to help speed up graph visualization and editing [all, unless things get too laggy, but even then it's only an issue for veterans, who are forgiving/tolerant]
• Should the context graph be enabled by default [show it only if N months of data, N=3 or 12; PS: no, bad, anti-magic]
• Should the context graph show a rectangle with the current y axis zoom [no]
• Should the first [red line] knot (tini/vini) be editable? [yes?]
• Default Zoom and Zoom All buttons. Are both needed? Better names? [either rename “default zoom” to “reset zoom” and ditch “zoom all” (hitting minus a bunch of times does that) or even ditch both]
• Should we keep/ditch zoom by scroll? [ditch?]

Features related to the graph matrix (table view):

• Should the table be displayed in reverse by default? [no?]
• Should there be an option to reverse the table? [no?]
• Should auto table scroll enabled by default? [yes?]
• Should there be an option to toggle auto scroll? [no, anti-settings]
• Should table update on drag be enabled by default (disabling it helps with speed)? [yes?]
• Should there be an option to toggle table update on drag? [no]

To-Do List

1. Issue: When editing table entries, which one of the remaining two parameters should be updated? How should precision issues be handled, particularly since dates are quantizied to days? This is in fact what the "fix ---" choices are determining quite nicely in my opinion. My preference: When editing values and slopes, keep the date fixed, when editing dates, keep the slope or value fixed based on the "fix slopes" option. This makes much more sense from a [red line] adjustment point of view. It is also compatible with visual graph editing. Alternatively, we could have an option for each [red line] segment indicating which two the user is interested in keeping, which would make all these choices inter-mixable based on the user's preference but that might be too complex. Perhaps the graph should keep the two "fix" options, and the table should allow choosing which two are editable?
   Dreev: I'd love for this to work at least as well as the basic original [commitment] dial under the graph on old.beeminder.com -- where you could pick which one-of-three was inferred from the other two but also you could click on the grayed-out inferred field and it would magically un-gray itself and pick one of the other fields to be inferred.

2. omg i'm a genius: forget these "keep slopes/intervals fixed" checkboxes, which i'm finding super unintuitive for some reason, and instead drag either the nodes (it would let you drag either vertically or horizontally, but just one or the other) or the edges. i think that makes it super intuitive that if you don't want to mess up the slopes then you drag the segment itself. the vertical lines can be just for display, not clickable
   
   Uluc: I don't quite agree with this. There is utility in being able to move a "knot" (as I call them) without changing the slope of the preceding segment. Also, if I start dragging a [red line] segment itself, there is ambiguity as to whether I will modify the dates or values associated with either the previous or the next knot. I quite like the current set of possibilities and I think feedback from actual use cases and as many active users as possible would be needed to make a good decision here.

3. We have https://doc.bmndr.com/dial from years ago, may or may not still be anything of value there

4. Use asof instead of the latest datapoint for today

Kenn and Danny discussing extensions to the road data structure

• Moved to https://github.com/beeminder/beeminder/issues/750

Probably no longer relevant

• Put PNG paths into the output JSON
• Review and finalize PNG URL locations
• Rename PNG files to temporary files while generating new ones as in beebrain.py

DONE ITEMS

• Checking [red line] compliance with the pink region
• Show the [red line] matrix and have it update in real time as you drag things around
• A way to add and remove segments
• Some other way to drag [red line] segments around, conducive to the common use cases of scheduling breaks, ratcheting, etc?
• Write functions to convert unixtime<->daystamps
• Drop the scroll-wheel zoom in favor of the style where you draw a box to zoom and a single button to zoom all the way back out
• (uluc: I thought about that as well. Also, having a separate axis for the time range where you can select a date range would be useful. We can work on those once the feature gets integrated, I think.)
• DONE but double-clicking now selects the table entry for editing: Drop the double-clicking to edit. Instead highlight in the matrix whatever segment you click on or drag on on the graph. Then it's easy to always use the matrix to edit values directly.
• Then double-clicking can be strictly for adding nodes
• DONE (also implemented redo): Minimizing UI elements is nice. Maybe we can ditch "reset edits" now that you can hit "undo" until it's grayed out. (Er, tiny feature request: gray out the undo button when you reach the end of the undo stack)
• I think there should be a way to zoom all the way out to see both past and future
• It should be possible to edit the start date/val from the graph matrix
• Date picker or at least allow manual editing of dates
• There will be huge value in also seeing the datapoints on this graph. You usually need to know what you've done so far to decide how to pick slopes.
• Tentative idea: two zoom buttons: "default zoom" (what the current zoom-to-fit does) and "zoom out" (which zooms out to fit everything, past and future)
• Alt idea: small plus and minus for zooming like google maps which everyone knows and so minimizes UI clutter since we don't even need the word "zoom" in that case
• The date picker is off by one from the date field in western time zones. Issue when parsing a date in western timezones Pikaday/Pikaday#138 (comment)
• Tiny feature request: visually indicate the good side of the [red line] by shading the whole thing yellow. Also helps pave the way for yellow brick halfplane (YBHP).
• The final knot should be visually distinct, like a bull's eye perhaps, or just don't show the YBR beyond that point.
• Bug: Akrasia horizon should be shown on top of yellow shading for good side of the [red line]
• Bee: keeping the current x-axis zoom seems good, but i guess i sort of expected the y-axis zoom to update.
• Dreev: let's call the zoom-out button good enough for now. bee hadn't noticed that initially.

Verbata: meta-gissue, mega-gissue, task list, to-do list,