search

xy008areshsu / FoodAwesome

0 stars 0 forks source link

Technical Scoping #3

Open xy008areshsu opened 7 years ago

xy008areshsu commented 7 years ago
  1. Read heavy or write heavy? The problem with UBER is a simultaneous update in real time. At this point, we don't need real time update.
xy008areshsu commented 7 years ago

During peak (lunch or dinner time), it should be both read and write heavy. Eater look for food, and once placed an order, a new session should be created and tracked in real time. The cook prepares food, and update in our app the current status of the order in real time. After the order is delivered, this session is complete and should be stored in our DB.

xy008areshsu commented 7 years ago

2 ASK and bid feature: Schedule ahead of time if the food is not available. When there is no available cook who is able to make a particular food the eater asked for. It will be listed in our "ASK" board. Next time when the cook find something that he can make, he can take that 'offer', and this item will be removed from the 'ASK' board. The 'BID' board is essentially all available foods that at least one cook can make right now, not necessarily those cook should be online and available at the moment. Technical scoping: UX design, search engine design, ask price and bid price (similar to stock market).

xy008areshsu commented 7 years ago
  1. Connect Offline: We can connect offline to people to serve certain requests (e.g., kungpao chicken no one can cook at the moment but we do know who can, so we send recipe to people we know) When no one online can make a particular food, we will send email, txt message, fb messenger etc. to notify those who can. Once the first one who can make the food and is also nearby accepted the order, we will notify the eater. Technical stuff: dispatch and notify system.
xy008areshsu commented 7 years ago
  1. Delivery: partnership with uber
  2. Recommendation: in case you don't know what you want..the app can make recommendation (like Netflix or Amazon)