Category Archives: Process

Choosing Patterns for use in Recipe Finder

So I have done some perusing of sites that outline key User Interface patterns and I wanted to talk about them in coordination with my Recipe Finder project.

15 Common Component Patterns

  • Add Another – I really like this pattern for what it can bring me with the ingredients list. I want to implement a way in which the ingredients can individually add in the amount, type and measure into an ingredient, but there needs to be a simple way to add and remove ingredients. This pattern could provide that.
  • Add/Manage Tags – I like this pattern so that it is easy for users to tag their recipes for search capabilities. I also know this pattern is implemented in Boostrap which I may choose to customize that portion into my project.
  • Add/Edit or Select from Existing – this pattern is interesting and could prove useful on things like the units of measurement. So there would be a selection drop down for unit of measure, but if you don’t see it in the list, you could add your own measurement into it.

10 UI Design Patterns You Should Be Paying Attention To

  • Progressive Disclosure – this is one of my favorite patterns and can be very useful for Responsive Web Design, so that users can only fill in the vital parts of a recipe, but can always add extra information if need be later, or twirl down a drop down to enter information like summary, yield, or tags as extra information that may not be used in the essentials of a program.
  • Clear Primary Actions – I really like the idea of using color to display to the user if their form is ready to be submitted (all required fields filled in). Also for users that cannot use color (color blindness) I would like to display some sort of text along with it to clearly show someone their form is ready for submission.
  • Required Field Marker – just like the previous pattern, this one is clearly needed to display which fields are required to be submitted.
  • Hover Controls – this can be useful, however since it will be a mobile app, probably use clicks or touch events over hover. But this can also be useful for Responsive Web Design, saving real estate where needed.

15 UI Design Patterns Web Designers Should Keep Handy

  • Page Grids – I definitely want to use grids, to make it easy to clearly separate sections of my site and making it easy to move grids vertically when vertical space is only space available for display.
  • Modular Tabs – I definitely like this pattern for my project simply to make it clear what section the user is in. Create Recipe  *  My Recipes  *  Friends Recipes * Public Recipes
    are all likely candidates for menu options to allow people to know what section they are in.
  • Pagination – this might also be a Bootstrap candidate. However I do think on pages that list multiple recipes or images of recipes, pagination could make it easy for a user to traverse a lot of recipes at once.

 

Decisions for Starting Point

Since I knew I would have a lot of hurdles on this project I made a conscious decision to start with the books source code for chapter 7. This chapter starts on a User Interface for status objects and comes complete with a lot of the login and checks surrounding login for various pages. This allowed me to view how to construct a node/express/mongodb/backbone project. The only downfall was trying to make sense of the code from the spot in which I decided to pick it up. This did lead to some debugging needed when I ran into misunderstandings about the code. However, I was able to get through those and it now sets me up well to move forward developing the ui elements needed for my project.

Debugging, debugging, debugging

So the last week of work on the project has been very telling experience for me developing with node/express/mongodb/backbone. These technologies are so close in proximity since they are all javascript, but all have their own languages and syntax for doing several things. It should go without saying that the errors I made were still mostly human error on my part, but the error messages lead me down the wrong path. The many working files I was tearing through caused me to look at files where the origin of the problem did not reside. So here are the issues I ran into the most:

  1. incorrect syntax of my mongoose schema
  2. incorrect naming of object references in backbone
  3. incorrect updating of post command to write to the database

The first issue of incorrect syntax was probably the easiest to solve, and did not take long to look up in my reference books or online in the mongoose documentation. I pretty much had it figured out the first night, and working inside Chrome and the control panel gave me easy clues to solve the problems at hand.

The second issue of object references took a little longer to find, but it circulated around the following line of code:

account.status.push(status);
account.activity.push(status);

These lines of code take the status (which I will rename to recipe) and activity and push new statuses into them, so that they can display. However in trying to rename to recipe the first time I mistakenly named one reference with the word “recipes” which did take a while to track down. One reason for the inability to track this down was the error message kept leading me to this this piece of code:

$.post('/accounts/me/status', {
        status: statusText
      }, function(data) {
        statusCollection.add(new Status({status:statusText}));      
});

I have condensed this code to what was originally in the book, however I attempted to add in my attributes, which ended up being also my final problem – however this current issue kept circling me around this code instead of the latter piece of code, which ended up being the main problem – a typo.

For my final problem, I was hoping to achieve the following object when things were being recalled from the database:

onStatusCollectionReset: [{"fn":"recipe1","instructions":"instruction1","yield":"4",
"duration":"10mins","photo":"./","video":"./","summary":"summary1",
"published":"Better Homes","tag":"numerous|tags",
"_id":"516c8929f7920cd02400000a","nutrition":[],"author":[],"secretIngredients":[],
"ingredients":[]}]

Unfortunately, my code was only returning the empty arrays for those items in which I wanted multiple strings attached to it.

onStatusCollectionReset: [{"_id":"516c8929f7920cd02400000a","nutrition":[],
"author":[],"secretIngredients":[], "ingredients":[]}]

So after much mashing of teeth, I did manage to corner the problem. Basically, it was clear that the database was not publishing my items, because no items were getting retrieved. And it was saying there was something wrong with the post, which lead me to the last code sample, as I previously mentioned. But what the error did not tell me was to look at the post inside the app.js file that held the entire project (because the error occurred when the data was being retrieved, not when the data was lacking its writing to the database). In any case, here is the code that needed to be changed:

app.post('/accounts/:id/status', function(req, res) {
  var accountId = req.params.id == 'me'
                     ? req.session.accountId
                     : req.params.id;

  models.Account.findById(accountId, function(account) {
    status = {
      name: account.name,
      fn: req.param('fn', ''),
      instructions: req.param('instructions', ''),
      yield: req.param('yield', ''),
      duration: req.param('duration', ''),
      photo: req.param('photo', ''),
      video: req.param('video', ''),
      summary: req.param('summary', ''),
      published: req.param('published', ''),
      tag: req.param('tag', ""),
    };

The original code only had

app.post('/accounts/:id/status', function(req, res) {
  var accountId = req.params.id == 'me'
                     ? req.session.accountId
                     : req.params.id;

  models.Account.findById(accountId, function(account) {
    status = {
      name: account.name,
      status: req.param('status', ''),

    };

Because the object and the attribute were both named status, it did make it difficult to figure out where all of the references were pointing to, but in the end it did get figured out.

Node JS Internet Service Providers

So I am shopping around for a place to put my project when all is said and done. So far I have liked Nodejisu (https://www.nodejitsu.com/) and Heroku (http://www.heroku.com/) the best. The latter seems to have a pretty good pricing structure at $3 for a node of computing power and a month free to test it out while I am building the early stages of my project. The former seems to have a lot of tutorials on how to set it up, one of which is listed below:
http://www.youtube.com/watch?v=PACwQ632jIE

Basically at this point I am leaning toward nodejisu because it is free for the first month, however I know for one worker dyno, Heroku is also free, so I may be able to try it out too, but I have to better understand how much of my project will use the worker dyno vs. node in nodejisu computing power units. But I do welcome ideas from other and their experiences.

Recipe Finder Schema

So in order to build a single recipe we need to come up with several classes and properties that will make up the structure of my database. Most of my decisions concerning the format of the schema were named to follow the microformat outlined on the following page:
http://microformats.org/wiki/hrecipe
I have decided to come up with 4 key classifications to deliver this project. Three of them come under building recipes, namely Recipe, Ingredient and Nutrition. The final classification is for an Account because I would like to immediately tie in recipes to users in order to bind them as ownership for a user. I believe ownership, editing, and enhancing other user’s recipes can be a cornerstone to the success of this project. Some of the extra properties, or those items not in the microformat, highlighted below will display this option of editing existing recipes. In any case, here are the properties I have decided to use for the project:

Nutrition

  • value: number value of nutrition item.
  • unit: type of value – ounces, teaspoons, ect.
  • nutrition: nutrition information.

Ingredient

  • value: number value of ingredient.
  • unit: type of value – ounces, teaspoons, ect.
  • ingredient: name of ingredient.

Recipe

  • fn: name of recipe.
  • ingredients: an array of ingredients to be used in the recipe.
  • secretIngredients: an array of ingredients to be marked as secret. This extra feature enables a user to mark certain ingredients as secret or marked for special display.
  • addedIngredients: This property may be used for adding items to an existing recipe or one owned by a different account user. (This property may necessitate another classification of Borrowed Recipe).
  • removedIngredients: like the last property, you can also mark ingredients to take them off a particular recipe.
  • instructions: details about constructing the recipe.
  • additionalInstructions: adding the ability to edit instructions for a particular recipe. For example – skip 400 degrees, cook at 450 degrees for 5 minutes faster cooking time.
  • yield: marks the amount of servings created by a recipe.
  • duration: time for recipe from start to finish.
  • prepDuration: time for preparation of recipe (marinate overnight).
  • photo: image link of recipe.
  • video: video link for recipe (bring out the inner Julia Child).
  • summary: quick description of recipe.
  • author: link to an Account to bind ownership.
  • published: original source of recipe.
  • nutrition: array of nutritional elements making up the nutrition information.
  • tag: tagging a recipe with other keywords for searching capabilities.
  • rating:not quite sure where I will take the rating, thumbs up thumbs down, 1-5, ect. I do like the Facebook approach of keeping ratings simple as possible. It promotes more voting interaction. However, I don’t want to copy cat Facebook too much. Possibly also similar to Stack Overflow where you can also record negative feedback is interesting.

Account

  • email: a unique email account that cannot be duplicated in the database.
  • password: a password chosen by the user.
  • name:
  • first: first name of the account’s owner.
  • last: last name of the account’s owner.
  • photoUrl: a photo of the user.
  • biography: any other cooking related accolades a user wants to associate with their account.
  • recipes: array of recipes that belong to the account.
  • borrowedRecipes: array of recipes the user has altered.

 

Node JS and Accessories

I am working through Node JS tutorials and books. I have a lot more to look through but this post should prove an early explanation for my tooling decisions.
First Node JS: I originally chose to use Node because I wanted to streamline the code that I had to learn. I am looking to learn more JavaScript, and node would certainly put me more in the drivers seat of understanding how to code JavaScript. In addition, I am hoping to streamline the passing of data objects. Using the same type of code, should prove to be an easy smooth process of passing objects from a database, through to the front end of a site with JSON objects. So far, my research has been able to support my original thoughts on this.

NPM: The Node Packaging Manager is very impressive. Almost too impressive, being able to search thousands of third party applications is daunting, but powerful. Most of the packages that are in the tutorials I have researched include jade and Express. In addition another tutorial showed how to search for facebook applications – interesting how many fb applications were out in the public domain for NPM. Very powerful, but for the purposes of this project I will most likely be using Express to make creating REST applications with Node easier.

Express: As previously stated, Express makes things easier to get this project into a RESTful state. So I will most likely be using this package to simplify this part of the process.

Database access with Node: So far I am choosing Mongo DB, because it looks to be easy to implement, but I still have some more research to put forth with this project. I would like to compare the simplicity of Couch DB to Mongo, but I am interested at the moment for using one of those two.

Service Provider: I have found a few tutorials talking about Heroku Cloud Services, but in the lead at the moment is Nodejitsu. Mostly because I have had prior fellow employees suggest that provider, but I still need to find out which provider may be best for my needs with this project.

Node JS, Express, Mongo DB

I have been taking some tutorials on the following three technologies. The main tutorial I am checking out is:

http://coenraets.org/blog/2012/10/creating-a-rest-api-using-node-js-express-and-mongodb/

What I see so far is very good. I am looking for a setup that is clean to work with objects similar in nature from db to front end. So far, mongoDB gives me this ability with its use of BSON objects.

In addition, I have found Express a very nice package for creating REST applications with node js. I still want to finish some other tutorials, but most likely will start building my front end interface and test building an application with these technologies.