Emma Meersman

Entry 0 -- March 27.md

@@ -0,0 +1 @@
+This is the 0th notebook entry, stay tuned for more exciting entries in upcoming weeks.

Entry 1 -- April 3.md

@@ -2,33 +2,49 @@
 
 ## Last week's critique
 
-**TODO:** Fill in this part with a summary and reflection on the critque you
-received for last week's work. Answer questions such as:  How, specifically, did
-the feedback help improve the project? Did the feedback point out or offer
-something you hadn't considered? Did it help you make a design decision? Was it 
-helpful in addressing the most pressing issues in your project? How will you
-incorporate the feedback into your work? Will you change something about the 
-design, implementation, or evaluation as a result?
+I receieved a lot of useful notes from the critique last week. For starters, I got some feedback on the scope of the project. Rebekah cautioned me about trying to do a lot of different things in the project and mentioned that I should wait to implement a database interface or a UI. This didn't change much for my overall plans because I already knew that I needed to prioritize the tasting notes language format in the DSL about tasting notes. However, the fact that she mentioned that made me realize that I had started thinking a lot about the UI and database interface in my head. The critique was the type of reminder that I needed to re-focus on the important parts of the project and direct all of my attention towards the language. 
+
+A lot of the critique was focused on the specific language I will use to describe wines and the amount of freedom I plan to grant users of the DSL. I hadn't made any concrete decisions on linguistic user freedom at the time of the critique, so this gave me a lot of food for thought. She discussed limiting the language of the users in order to make the "wine cellar" database searchable. One suggestion that she had was to couple a limited set of searchable keywords with an optional expanded description. One example that she used was ("raspberries", "like in my grandfather's garden"). I think that this suggestion will really improve the project, since it's a good way to make the database more searchable while still giving the user the freedom of expression that they should have in tasting notes. 
+
+I had to think a lot more about the syntax of the language this week, and the critique gave me a lot of places to start thinking. I wasn't thinking about how to make the database searchable. One thing I'm still wrestling with is how much I want to focus on making different queries to the database (i.e. searching by specific flavor tasting notes) versus just having the database as a basic storage mechanism (queries might have to be very specific for a particular wine instead of more general searches). This is something I would love to get feedback on and would impact how much time I spend trying to create a finite set of flavor/aroma keywords. 
+
 
 ## Description
 
-**TODO:** Fill in this part with information about your work this week:
-important design decisions, changes to previous decisions, open questions,
-exciting milestones, preliminary results, etc. Feel free to include images
-(e.g., a sketch of the design or a screenshot of a running program), links to
-code, and any other resources that you think will help clearly convey your
-design process.
+I have made a substantial amount of design decisions for my project this week. All of these decisions were so substantial that I have not actually done any coding for the project yet. I plan to start this coding very early in the coming week, but there were a lot of things I needed to think about before I could actually start writing. For the record, I kept notes while working over the course of the week and am summarizing those notes and that progress in this notebook at the end of the week. That explains why this section of the notebook will read more as a weekly reflection, since I know everything I did this past week. 
+
+My critique last week suggested thinking of a list of what I want users of my language to be able to express about a given wine. My goals for the week were to find common attributes among styles of wine tasting notes and to come up with a basic language for wine that took the best features from these formats. I focused on how to make these attributes as flexible as possible to appeal to a wide user base. I began the week by searching through many different tasting notes and extracting the common themes among them. [This Google Doc](https://docs.google.com/a/g.hmc.edu/document/d/1XCLj4SaLaCd-cl_7Xwdeo2VM-2kYo6yXD4Uw0Fq0sPw/edit?usp=sharing) is a summary of that research. It contains links to various articles on tasting notes as well as the relevant tasting attributes and descriptions mentioned in each of those articles. 
+
+I wasn't especially surprised by the wine attributes that I found in the articles, since I have some amount of experience in what people look for when drinking a wine. I started to get an idea of the general attributes I wanted to represent with my language, but I still had the more thorny problem of how to encode individual flavors. I was debating whether to let users pick from a specific set of tastes and then add description. I could also let users write paragraphs about their tastes or aromas, but this would be impossible to compare to other note formats unless I wanted to get into NLP (I don't, and this will come up later). I currently have a primary solution that I plan to describe later, but I would love feedback on how feasible that representation will be.
+
+I looked into a lot of tasting note formats and compiled the examples into a different [Google Sheet](https://docs.google.com/a/g.hmc.edu/spreadsheets/d/1YixnUrSxKshJENVIG6wQ9mP44irSelkOzrnIm6kUH3s/edit?usp=sharing). I was curious how premade tasting notes sheets were set up, since I've rarely written wine notes for myself. I tried reviewing wines using some of the worksheets for tasting notes and found things that I liked and didn't like about each of the formats. Sometimes I felt too constrained and sometimes I felt like I did not have enough guidance or inspiration for the notes. This motivated me to settle for a structure somewhere in the middle of that spectrum, something that would allow users to write general impressions for categories like Color/Appearance and Overall Impression. However, I decided to break Aroma/Flavor down into subcategories so that users can identify individual flavors and write notes on them but not output a frustrating (programmatically) block of text.
+
+At this point in the week, I knew I had to start thinking more about the technical end of the problem. I had a list of wine APIs and was very aware that I needed to find one where the tasting notes would somewhat match up to my preliminary format. Cue instant problems. No matter how much I searched, the most helpful tasting notes I could find for wine searching APIs consisted of a block of text in a review as well as a numerical score. Thus, if I wanted to compare a personal tasting note in my language to something more professional, I would only be able to match the two overall scores and then access a paragraph of a wine review. 
+
+As I mentioned before, I think that it would be possible to do some NLP on the block of text in a review to extract the desired features. However, most of the reviews are not long enough to extract a lot of information ([vintank's API](http://developer.cruvee.com/search-api/sample-wine-response-in-json/) provided the most helpful reviews in the description of a response). It would be hard to get a good comparison between personal tasting notes and professional opinions. Also, I would prefer to focus on different technical goals for the project than learning about NLP. I am more technically interested in the language design as well as the prospect of building a visual tool with this DSL. 
+
+At this point, I had a decision to make. It seemed like my initial idea of comparing personal and professional notes was not very feasible. Note that this revalation occurred fairly late in the week, so I'm still wrestling with a few of these decisions. I think I'll continue a lot of this in the Questions section, so I'm going to give a brief overview of my decisions here. At this point, I want to turn my DSL into more of a personal visualization tool for wine tasting notes. I could still keep the "wine cellar" aspect of the project and let users write their own wine tasting notes. A program in the language would be a set of tasting notes, and the user would be able to create visualizations from these tasting notes. I have a sketch of a sample program [here](https://goo.gl/photos/Kqqp9qn346wKMWQR8). For example, a user could list flavors that they detect in the wine and the strength of each of those flavors. This information could get compiled into a pie chart describing the taste of the wine. Users could even compare different wines in their own personal cellar by this method, something that would be helped by the visualization. I have a lot of questions for the project at this point, so I'll take it into the next section. Overall, I came up with a tasting notes format this week that I think can be used in a lot of different ways. Since I have this format and I'm happy with the user flexibility, I feel as though I have accomplished some good goals in the past week.
+
 
 ## Questions
 
 **What is the most pressing issue for your project? What design decision do
 you need to make, what implementation issue are you trying to solve, or how
 are you evaluating your design and implementation?**
 
+I think it's pretty obvious, but the most pressing issue for my project is what I want to do with the tasting notes. Would the visualization of a wine based on the notes be a good application? I think it would help the user see their opinions on a wine in a different format. Would it be all right if the users can't compare their opinions with something more professional? Again, I think that I want to keep the primary structure of users writing tasting notes that get put in their own personal "wine cellar." If the notes in the cellar could be compared, would this also be appealing to users? I need to make sure that this design decision would be enough of a DSL and still feasible given the time constraints of the project. Again, I plan to start coding for the project at the very beginning of the upcoming week. 
+
 **What questions do you have for your critique partners? How can they best help
 you?**
 
+I have two primary areas in which I want feedback. First is the format of my tasting notes. I linked to an image above which is a sketch of my note format, but [here](https://goo.gl/photos/Kqqp9qn346wKMWQR8) is the image again. A sample program is written on the left side of the paper. I think that, to start, a program would just be a file where the different tasting notes are separated by key headers. My questions are: is this a good format for tasting notes? I don't expect specific feedback on the intricacies of wine tasting, but is it a good idea to structure the notes this way? Should I keep the fields that have numbers? Should I add more numbers (the ability to score each attribute) and determine the overall score of the wine at the end? Currently, I'm letting users arbitrarily assign a score at the end but this could be changed. I also structured aroma/flavor attributes in the format of (attribute, score, modifier), where the attribute is a single arbitrary word to name the flavor/aroma, the score is the strength of the attribute, and the modifier is an optional word such as "aroma" "finish" or "taste" to specify where that attribute was detected. I might also expand this to include Rebekah's suggestion of more specific attributes, so an optional "expanded definition" where the user could get more specific on the nature of the flavor. Would this be feasible for the program?
+
+The second thing I want feeback for is all of the questions in the previous section. I'm worried that I don't have a completely concrete project direction at this point. I'm happy to do the visualization project, but would this be enough of a DSL? Do you think it would be useful for users? Would it be beneficial to let users compare multiple different wine visualizations? If I do this, when should I generate the graphs and how should I store wines into the database? By that, I mean should I make a tasting note and focus on immediately generating a visualization, or should I store it into a database and generate a visualization after I access it in the database? Actually, I probably should just focus on things that don't deal with databases and think about how to make a visualization from a single program. Would this be a good direction for the project? If so I think my next steps are: write the tasting notes format, generate a visualization, then add the ability to generate multiple visualizations. Are there alternative next steps or directions I could do with that project?
+
+One final question I have: if I end up doing the visualizations, any suggestions for a language I could use? I know Scala has limited tools for it, but if I wanted to make the visualizations more complex, I would think about using another language in conjunction with Scala. Suggestions? I've done d3/SVG for web visualizations before, but I think I'd be looking for something else. I haven't looked into this at all yet, so I'm also going to do research on this in the very near future.
+
+
 **How much time did you spend on the project this week? If you're working in a
 team, how did you share the labor?**
 
-
+Not including the time I spent at a wine bar doing research, I spent around 10 hours on the project this week. Most of it was spent compiling tasting notes formats and refining my own tasting notes design. The rest of the week was spent frantically searching through APIs, getting disappointed that none had well-formatted tasting notes, and trying to think of new directions for my project.