Requirement list
So, what can we deduce from those UX sketches? Here are a few things that jump out at me. Can you think of others?
We’ll need to perform all the basic CRUD operations on the underlying data. That’s a given in most applications, but the UX can vary widely. In this application, the end user will be performing the operations, so we know we’ll need to allow for that.
We’ll need to reformat the Ingredient data for display. But because of the separate Add/Edit UI, we don’t need to extrapolate structured data from free-form text. (Whew!)
We’ll need to search the data based on values provided by the user at runtime.
On Your Own
This is just an early proof of concept, so of course we’re not really worried about making the code as robust and re-usable as we would for a production application. That said, it’s probably a good idea to spend some time thinking about likely changes in scope or functionality that would invalidate our basic architectural and platform decisions.
One thing I can think of is that we might want to link the Ingredient data to the USDA nutritional database. (If you want to know about that resource, you can find it at ndb.nal.usda.gov.) Can you think of any other areas where we’re vulnerable enough to change to worry at this point?