Added AttributeSelectorScreen and another placeholder Screen for exam…

[pablisch]

…ple use.

The main thing is the routes (screens) mechanism being in place. I have included a placeholder for the AttributeSelectorScreen and another purely for example placeholder which makes usage clearer to me as I learn about React Native for the first time.

I have included a link button, again for example, but it does a good job of highlighting the styling issues between ios and android.

[siqbal181]

@pablisch I think we might need to think about PRs with acceptance criteria in accordance to design docs or something of the sort. Especially as people are working somewhat ad-hoc on the tickets, it already is a bit difficult for me to visualise what part of the project the ticket is referring to (definitely not a fault thing, just more of a planning consideration!).. I can understand it by looking more deeper in the code. But some more strict criteria for each ticket, with a link to the ticket and a mock-up of what the outcome should be per ticket is the ideal scenario. What do you think?

[pablisch]

@siqbal181 Yes, I agree. I think there is a strong element of the project running before it can walk and I am happy to change direction in that respect. I think in part it is a part of the remote, very part-time nature of the project. Design-wise, I think acceptance should be structural rather than visual as the structure and how it looks seem like different issues but this is up for debate. This ticket is perhaps an odd one in as much as it felt like something had to be in place but most of the code is placeholder and example. It was designed to help but is possibly more confusing.

Ideally, I feel that we would perhaps just stop any ideas of coding until design and planning was properly in place and I think there is a strong argument for that. Get together and agree user stories, user journeys, a feature map, a complete, if provisional, design scheme and yes, acceptance criteria would arise from that. It is a big change in direction but really, a proper way to go about things. Without that, things will remain a little, or a lot, ad hoc.

I did a bit of this today which you might have caught on Discord, but I would happily go properly down that route. It feels like the proper way to do things.

Also, always good to review a PR with the coder to get an understanding of 'why' without any struggle 🙂.

Thoughts on a halt and doing proper planning first?

[siqbal181]

@siqbal181 Yes, I agree. I think there is a strong element of the project running before it can walk and I am happy to change direction in that respect. I think in part it is a part of the remote, very part-time nature of the project. Design-wise, I think acceptance should be structural rather than visual as the structure and how it looks seem like different issues but this is up for debate. This ticket is perhaps an odd one in as much as it felt like something had to be in place but most of the code is placeholder and example. It was designed to help but is possibly more confusing.

Ideally, I feel that we would perhaps just stop any ideas of coding until design and planning was properly in place and I think there is a strong argument for that. Get together and agree user stories, user journeys, a feature map, a complete, if provisional, design scheme and yes, acceptance criteria would arise from that. It is a big change in direction but really, a proper way to go about things. Without that, things will remain a little, or a lot, ad hoc.

I did a bit of this today which you might have caught on Discord, but I would happily go properly down that route. It feels like the proper way to do things.

Also, always good to review a PR with the coder to get an understanding of 'why' without any struggle 🙂.

Thoughts on a halt and doing proper planning first?

Agree! Think the excaliidraw you did and pasted on discord is great. In my head each of those separate screens should be a sprint in itself and everyone should work on making that specific part work (or maybe 2 screens if one is too much of a blocker) so for example

1. Properly flesh out the login screen: Uses cases, tests, design criteria, acceptance - then break out those into ticket
2. properly flesh out the main screen: same as above.

Then break out a some deeper mock ups with labelling of what things should do so people can easily pick up and visualise what to do (to a degree) in addition to following AC

[pablisch]

Agree! Think the excaliidraw you did and pasted on discord is great. In my head each of those separate screens should be a sprint in itself and everyone should work on making that specific part work (or maybe 2 screens if one is too much of a blocker) so for example

1. Properly flesh out the login screen: Uses cases, tests, design criteria, acceptance - then break out those into ticket
2. properly flesh out the main screen: same as above.

Then break out a some deeper mock ups with labelling of what things should do so people can easily pick up and visualise what to do (to a degree) in addition to following AC

Except for thinking about the Cafe Model and fixing down what we are using for auth, the main page IS the first sprint and I think it is enough. The key change would be stepping back and doing proper planning first. I felt there was a sense of urgency to get going and it could be really tricky organising everyone's time to get the planning done but I am up for trying. Think back to Makers projects, it took a day or so to get a pretty dodgy plan together. We could plan properly one sprint at a time but we would still need a coherent overview of the wider project.

I will bring this up tomorrow but feel free to drop messages in if you're not going to be there. I think this is very valid.

[pablisch]

I have removed all excess code which was meant to be helpful example code but seemed to just confuse matters. There is a single screen route to a placeholder for the screen with clear instructions it is to be replaced when ready.