scarletphoenix

In my mental model of an offline app, I expect instant responses. However, I know to the complexities of apps, the diverse wants of a big, diverse user base that it can be hard/impossible for an app to be well-architected enough to achieve this ideal.

Failover is hard, and there generally aren't hard rules for what to do if data isn't available or how to communicate to a user in a specific offline situation on how the current state of an offline app affects what they see -- and even when they would care or what they could do about it when they do care

Thanks for showing this off!

I played through the daily puzzle:

1. It was really hard in dark mode to see what I was doing

2. Scanning was almost impossible without clicking and seeing the runs -- so it was mostly fully pencil mark and find pairs and triples.

Overall, unique, but I think some further constraints or human-setters (as you mentioned) could lead to more intuitive or clever paths to a solution.

(Perhaps instead of lines, shade the cells in the runs to avoid clutter with borders and writing over numbers)

Some day in the near future, the marketing department will wonder why so many people were curious about all of their products after browsing Organic Ground Beef[0]

[0]: https://github.com/cmoog/traderjoes/blob/ea2da58a84d3a04e28f...

I set both of these to false, and I was able to copy a command from a README file on GitHub still (after reopening tab)

I like the simplicity, thanks!

I created a test group with 3 users and 3 expenses with different payers and payees. After the first reimbursement, the remaining 2 balances were not equal: -0.70 vs. 0.69. After the second, the final balances are: -0.01 0.00 0.00

Some nice to haves: - When creating expenses, a select all functionality/default all for "paid for" - Group status on the /groups page