The Furnace 5/1/23 (3h)

[richardbirkin]

Due to the train strikes we met at the other end of town to The Alex, at The Furnace. A fine establishment, sadly lacking in Pentrich brews but owned and populated by Shiny, which makes up for that.

SLC For Labels

Our next sprint will be dedicated to making a prototype of TrackShift for Record Labels. Following a qualitative survey of labels before Christmas, a pattern is that small labels need to combine and understand their data in order to pay artists the right amount.

We're going to start with Bandcamp Sales Reports, since we have those (mine and my band's).

A simple pivot to artists and products will suffice.

On the left you can see a sketch of Artists with their Totals. A breakdown by Product can be accessed via an accordion.

We spent a while looking at one of my Bandcamp Sales Reports trying to understand the maths in there, but quickly decided against it as we'd had two pints by that point and our brains were already fried from a day of work and parenting.

I had a look the next morning and, yes, there are lots of calculations in there, but the column we need for SLC is net amount

On the right-hand page I wrote all of the things that we talked about that are beyond the scope of an SLC prototype. For example, artist/label % splits, profit/loss, all historical sales reports combined. Also - TRUST.

The point in writing these down was to capture the "and then we can..." idea storm that happens when we talk about TrackShift. But, for now, we need only work on the things for SLC.

Once we can show what it can do, we can find out what people would like it to do next and, importantly, develop a trust that although we are small and in prototype stage, we can be trusted with user's data.

Artist v Label

Keeping it simple with Bandcamp Sales Reports:

If a user uploads a statement with 1 Artist in it then they are an Artist.
If a user uploads a statement with >1 Artist in it then they are a Label.

We also know that this is a Bandcamp statement from the hash of the header row.

Statement Cannot Be Processed

The the upload cannot be processed, we need to communicate:

• we have the file
• something unexpected was found in it that caused the processing to fail
• we're on it
• we'll e-mail you when it has been processed

For alpha users:

• try to get the statement first
• test it
• when we're confident it works tell them to upload it and feedback on what they see.

Update - I'm not sure that will be possible as initial requests for statements have met with trust/security issues. We should test with my statements, and then get labels to try it online where a privacy policy is clearly viewable.

Future Future

Bandcamp API - would be great if a user could link their TrackShift and Bandcamp accounts so that they don't even need to upload a statement.

Crawling - not really how we want to do things.

No graphs until someone really wants one.

TrackShift should = antidote to graphs.

Basic Styling

We also looked at some styling work that I've been doing over Christmas. Tidying up the interface and making it slightly interactive with hover states and drag/drop interface highlighting.

We messed with some auto-upload triggering when the file is dropped, but decided against doing dev in the pub!

Next Steps

#51 <- do this.

Commit styling work as described above.

[g105b]

An idea I had when reading through this is that if the software hits a snag and doesn't know how to process an uploaded file, it should do the following:

1. Tell the user that the uploaded file didn't process automatically
2. Explain that there's need for the developers to look at the file
3. Ask permission to "unlock" the file to us, otherwise delete the file

The upload process is all encrypted by default, but not encrypted at rest, so technically we'd be able to load up users' files by accessing the server directly, but until we implement end-to-end encryption this extra permission step would act as an NDA, and just like with an NDA, there's nothing stopping you breaking it, apart from that you would be breaking the valuable trust of the relationship.