Closed cnfairall closed 1 month ago
GregM1992
commented
2 months ago this was the initial erd but i changed the fact that bandshows are a many to many. the reason they are no longer like that is because it would require every band to have a profile to create be on the show. show i think that shows are now going to just be independent to the specific band
GregM1992
commented
2 months ago
This is a basic wireframe, gonna update it soon.
cnfairall
commented
2 months ago Thought: One option: if someone is in > 1 band availability for each band would be different therefore they create a new availability with each band joined ex. if I join band A, my free times are Tues PM, Fri PM, Sun AM say Sun AM is selected as practice time for band A now if I join band B, my avail is only Tues and Fri AM. therefore, should ability to set user availability only exist after they have joined a band?-- so that each avail is tied to a band so, if a user can have a collection of availabilities, each of them would have a user Id and a band Id, essentially becoming a join table -- I know this was something you were trying to avoid with shows and bands.
Other option: Better to have one availability for each user that is updated every time a band event is scheduled. In that case, ERD should have userId inside Availability object, instead of avail Id inside of User.
So obviously I answered my own question but I needed to make sure I was planning correctly.
cnfairall
commented
2 months ago also since with the MTM with users and bands, we can nest bands ICollection inside of User, and users IC inside of Band; so we don't need the members property. We can access the band members by band.users
cnfairall
commented
2 months ago https://www.figma.com/board/Dasju0NLEhSVUYSxLw6lyv/Shredule?node-id=0-1&t=h8MiY0NJQ4c3RSIW-1 some functions here, not all yet
GregM1992
commented
2 months ago So I figure its up to the user to make sure theyre not double booking themselves. im thinking as it starts off (before the adding of any sort of calendar api) since its just going to list events that you have the availability wont be updated based off of events since the availability is a weekly thing. its not the availability for each individual week with dates attached
cnfairall
commented
2 months ago when a user creates a band, they should be made the leader band should have leaderId leaderId == userId captured when user posts
also thinking that viewing whole band availability would only be a useful feature for band leader, so that would only be visible to user who is band leader and like wise all band action buttons would only be visible to leader
so I think we need to change the band model to include leaderId
cnfairall
commented
2 months ago New user flow
Please add to/edit with corrections, clarifications :) ERD for entities: band user availability -- object comprised of time blocks as true/false, so a collection of weekly-repeating times schedule -- one to many relationship with shows, practices -- basically contains collections of events with unique datetimes, not a collection of universally available, weekly-repeating times show practice
user flow questions: Q: assuming the first step is registering self as a user-- do you have to enter or select a band in the register form? or can you register as a bandless user and then handle band relationship later? similarly, do you create an empty schedule for a band that is filled when you add events, or does creating an event also create a schedule, etc.
A: each user registers independently without a band. each user can create a band and when creating a band they create a password for that band.
Q: how does a user join a band? do they select from a drop down menu? is a band added to the user, or is a user added to band? In either case, does the new user do that themself?
A: when looking to join a band they would search for the band? or select from a list? most likely the former. and then the user is prompted to input the password. this allows them to join that band. Users would be added to the band.
Q: is there a way to prevent multiple users from creating the same band, or is it assumed that the band will designate one person to do it?
A: its assumed that the band will designate one person to do the initial creation of the band. Seeing as how there are instances when multiple bands have the same name.
Q: what pages do we need? register, user profile, band profile, availability form, band schedule, pages for shows or practices? A: Im going to create a rough draft of the FE pages today I think. along with creating a repo and the initial setup.
Q: when is "group availability" computed? is the flow like, a person joins and creates their availability. every time a new member is added, a function is called to get all instances of universal availability. this creates the band
schedule(ah but as per above that is not what a schedule is, maybe call this band availability?)? Then those times would be used to select times for events? there would need to be a function to translate "Monday night" to a literal date and time, at least for shows -- I assume that would be a calendar api?A: So this is kind of in the "figuring it out" part. I think that the "group availability" would not be a class in itself but more so "created" when creating a practice or a show. Im thinking that when creating either one the form would reference all availabilities at that time (since each users availability can change at anytime) and then show a "recommended" week and then one could choose to create a practice/show on those days. Im unsure if i want to allow the creation of these on days that are not available (superseding the recommended availability of the band as a whole)
Q: OR all the band members' individual availabilities exist. Someone -- any band member or band leader? -- needs to post a show or practice. We assume practice is probably going to be at the same time/s every week -- so we don't want the band to do a form for each instance.
A: again kind of still in the figuring it out part (im open to suggestions) Im thinking that (assuming every member is updating their availability) you can have a recurring schedule that is made every week. Reference the second part of the question for more input.
Q: In the case of shows, are we considering use case of, we've been offered a show, I need to use the app to see if people are available, i.e. shows have fixed dates, or are we ONLY considering that the band is picking a date for a show that works for everyone?
A: This is where im considering the option to supersede the "band availability" in my experience when a show is confirmed the band members would request off at their jobs to play the show. it often is the goal of bands so maybe the show option doesnt even reference the "band availability" and exists independently of it.
Q: something to consider is storing the group availability as an object, maybe the band model, since that will be used over and over to select times for events. or maybe not necessary as practice will be set only occasionally, and only shows will have to be posted for each instance. Just wondering/trying to visualize.
A: i think i answered this in a prev question but since availabilities can change (my schedule changes everyweek) it will be reference only.
Q: My main blocker is reconciling time blocks vs datetimes, but maybe the interaction of those is unknown at this time. On that note -- maybe we determine feasibility of calendar api and decide whether to integrate? Of course there's, no for mvp, add it later, but it would seem so foundational as to require complete overhaul of all the mvp code :/
A: you and me both, as it stands i was thinking just having a literal list of practices and shows with dates attached to them. not necessarily in a calendar style ( that would be the eventual goal) just having a simple representation of a working product is the goal so far.
Let's make a list of mvp functions
😃