The Big Picture

[jwjacobson]

This document lays out how I see the development of the app proceeding. I hope it will help to bring together and contextualize the various specific issues I've already created.

Phase 1: Basic Functionality

For now each user will start with an empty repertoire. There may be tunes of other users in the database but the user will not see them; they will only see tunes they have added themselves (i.e., they only see tunes indexed to their user_id in the association table).

Eventually there will also be a prepopulated directory of tunes (owned by admin?) that the user can browse and add to their own repertoire.

This suggests that a user creating a tune and a user adding a tune to the repertoire are two distinct actions and need two distinct views. When the user creates their own tune, it is a two-step process: first the tune object is instantiated, and second, the tune is added to the repertoire. When the user takes a tune from the public directory, there is only the second of the previous two steps, adding the tune to the repertoire.

Specifically in the case of copying a tune from the public repertoire, all of its fields need to be duplicated in the association table so that the user can edit their version of the tune without impacting the public tune, which will be read-only to users.

When a user creates a tune or takes one from the public repertoire, they will also select their knowledge of the tune (for now there will be three choices: know, learning, don't know). On the one hand this selection should be part of the same form or overall process as tune creation, but in terms of the program logic it seems it will be separate: a separate view and also maybe a separate form, though they will be presented together on the same page.

If, on adding a tune to their repertoire, a user selects "learning" or "know" for their tune knowledge, a started_learning field will be marked with a datetime.now or equivalent. This will be useful to the user: maybe they want to select tunes only from those they learned recently, or only from those they've known for a long time. started_learning will be left blank if the tune is classified "don't know" and will need to be marked if the user's tune_knowledge changes.

Once this all works the last_played field will be added to the association table, which marks when a user last played a tune. This will involve a new view, tune_play, with its own template. This template will also give the user the option of being offered a random tune from their repertoire, which they can accept or reject. If they accept the offered tune, it is assumed to have been played and will be marked accordingly.

At this point basic functionality will be complete and a user will be able to manually create and track their repertoire using the app, but it won't be much different from using a spreadsheet. The real utility of the app comes in the next phase.

Phase 2: Tune Search, or, the app finally becomes useful

Tune search will apply to both the list and play templates and will allow the filtering of displayed or offered tunes by all tune fields, both on the tune object itself and in the association table. It should be relatively effortless for the user to say, for example, "Show me all the standards I know in G sorted by how recently I've played them, starting with the most recent," or, by the same logic, to say "Offer me the tune in G that I haven't played the longest."

Once tune search is implemented the app will be functionally complete.

Phase 3: UI

This phase will focus on making the app beautiful and easy to use.

[bbelderbos]

Very useful, thanks for putting this together. We can further discuss here or in derived issues as we go. Seems the modelling with the M2M associate table supports this right? You will have to code in some permission protection stuff, but we'll get there. Any concerns or questions?

[jwjacobson]

The thing I'm having trouble wrapping my head around now is how tune_knowledge is going to work. On the one hand, from standpoint of the program logic, I'm assuming it needs to be its own view and have its own form, espeically since it will be added to the association table after the creation of the tune. From the user side, though, it should present as part of the same form as tune creation/editing and appear on the same url: it should just be one more field for the user to fill.

[bbelderbos]

We can both ways, but if you prefer the user to be able to edit it in one go you could make one view and work with two model forms (one for Tune and one for RepertoireTune), would that work for you?

[bbelderbos]

As promised here is a deferred form save example:
https://chat.openai.com/share/a467f67b-9890-4bcf-a76e-a8989a1f9711