RECIPE challenge - NOT A TOY. Comments appreciated

RECIPE challenge - NOT A TOY. Comments appreciated
0

#1

This is a version 1.0 beta application. Comments, especially concerning bugs, would be greatly appreciated. The basic idea is described in the help screen - “introduction”.

https://s3.amazonaws.com/sabrawer-fcc-recipe-project/Recipe-B.html

This application is almost ready for prime time. It uses local storage. I will port it to a server after I finish the back-end challenges. It is actually a simple, special-purpose PIM. Run locally, it’s already a perfectly good and useful application.

Note: Because of browser security restrictions, it is not possible to upload photos from a local machine into the application to create a new “photo recipe” (see help-introduction). For testing, one could use a URL for a web image.

This runs perfectly in Safari. I have not tried any other browsers. Note that it is resizable from 300 to 700 px (min,max sizes are configurable). It uses React for virtually everything, but does not use JSX and does not use React classes. However, the javascript is completely object-oriented, ,with some reusable classes. I have not yet ported it to SCSS. I will do that when I clean up the code, finish the Help screens, and improve documentation, all prior to submission. Right now I am looking to clean up any bugs or awkwardness.

Thank you in advance.

Steve


#2

Functionality-wise I can say that looks good and it seems to be working fine on Chrome. =)

I must say though, that I’m not really a huge fan of the design and the somewhat bloated UI (especially the menu options). :confused:
IMO, from a UX point of view it feels as if instead of separate menu entries for each variation of recipe (create link, book, photo, etc.) it would probably make more sense to have a general “Create Recipe” entry only with options on the creation popup itself.

But yeah, that’s just MY opinion - maybe I’m weirder / and more stupid than the average person :slight_smile:


#3

Very neat idea. Works well in Chrome, but why some fields are “no edit”?
As kimkwanka mentioned above, the design could use improvement. I’m guessing you are working on functionality first.


#4

Thanks for the comments. It would be much more helpful if they were more specific (and less emotional), especially if they suggest radical design modifications.

Let me be specific. As you might have guessed, this is an application meant to be used by people who are non-technical (see later). Since ultimately there could be hundreds of recipes stored in 4 rather different formats, it is important to keep tight control over certain quantities in order to keep things consistent and to support search. The recipe name (or title) is obviously one of these. By having the name assigned only in a pop-up gives it focus and importance. Not crucial, but psychologically helpful. The keywords must be fixed and cannot be modified, so these can only be selected from a list. They are fixed forever. The only free-entry field common to all recipes is the comments field, which is totally free-form.

The “link” field is not mouse-active because it is difficult to edit a mouse-active field without clicking on it. So I have a “follow link” menu choice. The photos are photos and so the field is obviously non-text-editable. Until this becomes a full-blown web app, where photos can be uploaded, there is a pop-up for entering links to photos (when the application is used locally).

The book names also must be controlled. It would be difficult to search by book if, each time a book is entered in a free-form text field, the spelling or name is slightly different (M. Heatter, book of desserts, Maide H,new book of deserts (sic), etc). It would be difficult to search on. So this must be controlled as well.

People who do a lot of cooking frequently have a very “special” relationship with their recipes, which actually does involve the physical storage format. “Oh yes, I made recipe X over 2 years ago and it was good, I copied it from a magazine I found while waiting at the DMV. Let me look through this drawer full of papers to see if I can find it.” I kid you not.

The app gives 4 very different ways of storing information, or of referencing information stored elsewhere. To someone using the app, these correspond to very different ways of storing and accessing information PHYSICALLY. Photos might be in an app in a phone and/or notebook computer, links might be bookmarked in a phone or notebook or desktop, books will have physical bookmarks and notes, hard-copy recipes will be in a loose-leaf binder or file folder. Because of this, the app is a kind of PIM.

It is possible that some people don’t have cookbooks and only go online. Others may have lots of books, and don’t go online. Others may see recipes in newspapers and magazines and photograph them or copy them by hand. These physical procedures are conceptually distinct even in a “unified” app, so these four recipe “templates” are kept quite different from each other.

So the design is fixed. I would like to know how you think the design should be modified. If you think there should be just one create-recipe button, it would be helpful if you could outline how that would simplify things. I see that way of doing things as potentially confusing. As it is, the different functionalities required by the different templates are compartmentalized. My feeling is that, at first glance it seems a little complicated to developers (not to users, BTW), but in use this is really simple.

This is hardly menu bloat, unless you are used to web applications with a few nav buttons and a few photos and some text. If you want to see bloat, look at Logic Pro, Word, Phototshop, Apple’s web site, etc. That’s bloat!


#5

The link https://s3.amazonaws.com/sabrawer-fcc-recipe-project/Recipe-B.html fails. :confused:


#6

Good grief - the link worked fine yesterday (witness the two other comments). THANKS VERY MUCH for the heads-up.

Maybe AWS is down again?


#7

WAIT WAIT. IT WORKS FINE. You have an extra “16” on the end of your URL. Take off the 16 and it is up and running.


#8

I’m not a designer, so I won’t comment on your design, just some tips:

Use sites like http://paletton.com, http://www.lolcolors.com/ or https://coolors.co to select color scheme (remember rule of thumb: three colors plus white; and no, not just some random colors).
Read this: https://medium.com/@erikdkennedy/7-rules-for-creating-gorgeous-ui-part-1-559d4e805cda

Now my experience as a user:

First I’d like to point out that people generally don’t read instructions. Usual workflow is: try stuff -> call support -> return the product.

  • As @kimkwanka mentioned your menus are too bloated. The whole user experience is very unintuitive and confusing.
  • Your menu items are styled as buttons. When I click a button I’m not expecting additional menu. So I clicked ‘New’ and now I have to choose. But I just want to add recipe!!! I suggest that your app automatically selects type of recipe depending on filled-in fields.
  • If I’m adding Book Recipe there is menu Select Book, but if there is no Book I want, I have to close the window and look for a menu to add a book. Why? And where? Why is it under Manage, together with reset?
  • Display button is better to implement as a separate search field and radio buttons.
  • When I want to close edited recipe I get a prompt window with a bunch of text and two buttons Close and Cancel and there is no intuitive way to know right away which one to click. Why there can’t be Close and Save? Read this: https://uxplanet.org/primary-secondary-action-buttons-c16df9b36150

Ask someone non-technical to try your app and observe his/her reaction. I’m sure you’ll be surprised.


#9

These are great comments. I appreciate them and thank you for taking the time. I have actually thought about these issues, and so I will give my thoughts in more detail.

Regarding the “new” button, I could add an arrow (“new->” or “new>”) to lessen the disappointment. But I want to make sure I understand the “new recipe” procedure being suggested and what the consequences are, as this seems to be a major criticism. It is suggested that the button (or whatever) says “new menu” (or just “new”). After clicking I now have (say) a very general popup with fields for the following: a book, a link to an online recipe, links to photos (to upload when this is in a server), ingredients, instructions, and the common fields (name, comments, keyWords).

Say the user wants to create the simplest recipe - containing a link to an online recipe - and so fills in the link field. She (say) enters the link text, and somehow types something in the instructions or ingredients field (say because she thinks adding more salt is important, which belongs in comments, but she is confused), and clicks an OK button. Now (per your suggestion) the program is deciding what type of recipe to select from the filled in fields. Since both fields cannot exist in a single recipe (the text recipe has no need of a link field, the link recipe has no need for an ingredients field), an error message has to appear. I am now up to two clicks, some extraneous typing, an error screen and no new recipe has yet appeared. And this is a simple example! I can think of much more confusing and complicated situations from a naive user. Why, the naive (but logical) user may ask, do I have an ingredients field if all I want is to add a link to an online recipe, a couple of comments, a couple of keywords, and goodbye.

Say the “new” menu pops up a check list, where the user checks off what fields they want. Let’s say the user actually realizes that a link recipe does not need ingredients etc, and that the name, comments, keywords fields are common. (BTW, if you think about it, this will NOT be obvious to someone who does not read instructions.) Anyway, then the user must first click “new”, then click a checkbox for link (after finding it in a list), then click OK - three clicks as opposed to two. For a text field, 5 clicks are required. Besides the fact that this is already a lot of reading (reading checkbox labels), I think this would become seriously aggravating to a user after a while, and the current scheme of four choices (and two clicks) would be a relief.

Anyhow, the complaint is that the “new” menu leads to another (awful) menu with 4 choices. But in these comments, it leads to either a very complex screen or a popup with check boxes. Where’s the clarity?

I’m just trying to envision the process here. Maybe you had something more streamlined in mind. Believe me, I’m open to suggestions, but I am a detail person. Anyhow, is this better than selecting from four simple templates? Aren’t people used to templates, from word processors or spreadsheets?

You may be right that the user experience may not be good. I have had several people look at the app so far and have received no complaints. They saw the issues right away. Perhaps a naive user will be easier to satisfy than an experienced one.

May I suggest that people who use recipes to cook (as opposed to people who have memorized recipes, or simply throw stuff in a pot) are very much used to reading instructions. It is impossible to use a recipe without reading instructions.

My observations of people who read help screens and people who don’t read (please don’t take this personally - it is just an observation) - developers in particular are notorious for not reading any instructions, thereby wasting both time and money on what is essentially either an ego trip, laziness or the consequences of dyslexia (I have observed all of these, sometimes in the same person). Imagine learning something real simple like SQL, say, by sitting down and typing!

I agree that the close/cancel problem may be confusing.

Your comment about the book recipe is apt, and I worried about it quite a bit. The problem is that books are common to many recipes. I think this is an issue with no real resolution. A very organized person, like my wife, has an existing set of cookbooks, and will enter the books initially (or at least her favorites, initially) before embarking on adding recipes from the books. For her, this structure is logical. In addition , if you’re entering a book recipe, it makes sense that you have added the book first. Therefore, an “enter book” selection from an individual recipe screen (rather than from the main screen) might be confusing or illogical. On the other hand, a less organized person may want that. I think I’ll await comments from my beta users.

Re comments on the “display” button, the choices are are a logical group. If I separate out “search” I have yet another button.

Again, thank you. It’s great to make all this explicit.


#10

Hey @sabrawer, sorry for only being able to reply now, but cohorts kept me busy :slight_smile:

Giving critique without sounding harsh and taking feedback without it getting somewhat personal are really hard. So I want to say that I feel sorry, if something I wrote or will write, comes off as a bit brutal. But the matter of fact is, that you asked for feedback and only an honest answer will be helpful to you in the long run.

A potential way of solving the “create recipe” problem would be to have something like a dropdown menu, where you can select the type of recipe. Based on the selection show the required fields for that type of recipe. It would probably be a good idea to keep the “common” fields’ values like the name even if the user chooses a different type, since they might just have used the wrong type in the beginning and it would be somewhat frustrating to have to reenter those values again.
This way you have one place to create recipes, regardless of their type. UX is not about getting rid of options / required fields, but presenting them in a condensed and digestible (pun intended ;D) manner.

Additionally, I would highly suggest to only keep the “Save”, “Delete” and the “Close” buttons. Selecting keywords could be done through simple toggles on the form itself for example and since you have a “Save” button, not being able to say change the name directly in the field feels unnecessarily complicated.

It’s true that your app’s menus aren’t “bloated” compared to the programs you mentioned, but those programs have a ton more functionality they have to make accessible. I mean you still got a valid point there, as even in those professional softwares UX could be improved quite a lot, but that shouldn’t be an excuse to not improve your app’s UX.

You should really try to not take the feedback too personal though, since people are just offering their feedback as a means to help you improve your app. I know that it can be super hard to get critique on your “baby” but try to take the points made as objective as possible.

I can feel that you are very passionate about this project and I admire that a lot, so don’t let the critique get to you and keep on refining your app :slight_smile:

EDIT:
Here is a quick mockup I slapped together for you:
Link to Mockup

Don’t mind the styling, it’s just there to showcase how you could get rid of a lot of the current bloat. (try switching the “type” and you’ll see the fields changing accordingly)
The “new” button is a toggle atm and “save”, “delete” and “cancel” button are just there for show but you should get the general idea.


#11

Thank you for these more detailed comments. You certainly went to a great deal of trouble and your mockup is very interesting and very useful. I appreciate it very much. This is really extraordinary.

I like your keyword idea, though I’m not sure that showing ALL possible keywords on ALL recipes, where an individual recipe might need only one or two keywords, is better than a popup selection. In addition, an individual recipe may be viewed many times, and having all the keywords there all the time may become annoying, especially as they won’t be changed much, if at all. (In other words, they might be “too editable” in this toggle form.) In addition, the number of keywords might increase in the future (several people who tried out the application suggested a much larger number of keywords), and that would certainly fill up the screen unnecessarily. The keywords are only used for searching, but the comment and name fields are also used for searching, so it is a tradeoff.

The book field CANNOT be editable, for reasons I explained previously, so the select-book menu item cannot be removed. Neither can the photo drop-down, which will eventually migrate to an upload-photo interface.

I don’t see how your top-level “new” interface solves the “bloat” problem. I have a clean top-level interface (it seems clean to me) with a mere four buttons. You have an interface that would (presumably) also have these four buttons and in addition four check boxes always on display. It still requires two clicks to get to an actual recipe, but now there is a lot more stuff on the top-level. So it comes down to this - do we want a button and an on-demand drop-down, or a button (you have a “new” button) and always-visible checkboxes.

There is another user-issue that is relevant here. There will be two stages in using the application. The first stage is entering recipes. Your approach is certainly simpler. But the second stage is when the user will be actually using the recipes to cook, and making only occasional additions . In this stage, the “new” button will not be used much, so having those four additional checkboxes always there is a kind of “bloat” in itself and, IMHO, is less appealing visually (again, subjective). So, like many things, it is a tradeoff.

Furthermore (there is always a “furthermore”!), I’m envisioning the full four buttons along with the checkboxes. The checkboxes only work with the “new” button, so there is an asymmetry which may be confusing. One can always have a graphic outlining the organization, but now we are getting too complicated.

Whether or not the name field should be a separate popup or be editable is another of those “how will it be in actual use” problems. I agree that, the way it is now, it seems awkward. I used this application quite a bit while developing, and I did have the name field editable originally. I just didn’t like the “flow” of the thing. I found that it was TOO easy to modify. This is hard to explain. Its just that, in practice, it didn’t work well for me (again, subjective). Imagine a word processor with an editable file name field always on display, where people could edit the file name any and all the time by just typing, with no drop-down, and the document would be saved under the new file name when the document is saved. It would be a mess in actual use, and seriously error-prone, although it might be difficult to explain why. So I will leave the enter-name drop-down for now and solicit feedback from users.

The one thing I really don’t like - and maybe this is where some comments are really coming from - is having the non-editable fields as textareas. I thought of changing these to some other type of display, but I do like the uniformity and simplicity (anyway I think it’s simple) of the current individual-recipe screen. But maybe that will change in the future.

Thank you again for all the work you did on these comments. To be honest, I had not thought of these approaches, but in the end they have confirmed for me that my existing approach, while definitely not perfect, is reasonable enough for an initial version. But this discussion has been VERY useful for refining the way I approach user interfaces in general in the future, as thrashing out these details is, in the end, crucial.


#12

Glad I could provide you with “pair of fresh eyes” on your app and its UX. Like you said, discussion like these are always helpful, even if they just reaffirm your initial thoughts :slight_smile:

You are totally right that for just viewing the recipe, the overload of information is still there. But I honestly only showed the “edit”/“create” view of the recipe in my mockup. In a fleshed out app I would have a more simple view, where basically nothing would be editable by default.
Like you said, showing all of the keywords would make no sense. It would be more than enough to only show the actually picked ones in this view, but show the whole list in “edit”/“create”.

One could do this in 2 ways: Per element or per recipe.

Per recipe would be easy, since all you’d need was a button “Edit Recipe” which is only shown if you are viewing a recipe that was created beforehand to go into the “edit” mode. A slightly more elegant version would be for the elements to all be editable separately.
This pen shows what that “per element” editing could look like. But instead of having a delete button like in this pen, picture a small “pen” or “edit” button, to make that element editable. (In my pen, the elements are actually always editable, but look like regular text unless you mouseover - this is NOT what I suggest for you. Instead I want to direct your focus only on the little buttons showing on mouseover which could be used for entering edit mode on that element.)

I can understand your reasoning behind making stuff not easily editable, but am still not quite convinced. You say you cannot have a “create book” inside the “create recipe”. Still you have basically the same thing, just under the “manage” button. This makes it only more complicated to get there, doesn’t hinder the user messing with the stuff though. Putting that button right to where you’d chose your book, would just make it easier to access (and “ease the flow” in my opinion) when a user needs to add a book.
If you really wanted to avoid the user altering that “sensitive” data at all, you’d have to add something like “roles” where only certain users are even allowed to add books for example.
The same with links and photos. I understand that you want to intentionally disrupt the flow but making those editable “per element” like outlined before, would still allow for just that (flow disruption) but would keep the actions near the locations where they are actually needed.

I don’t understand what you mean with four buttons in the interface. The only thing the mockup currently lacks is a “help” button. All the creation options got consolidated into the “new recipe interface”. So is the “manage” button and its options. (You could argue that “reset to original” is missing, but I would put that button near the “add book” button too, also hidden away until in “edit mode” for that element “book”.) The display button’s functionality got split into the checkboxes and search field. Leaving only the “help” button missing.

You are completely right that a single button on left feels quite asymmetric and to be fair, I didn’t bother too much with correct placement of the buttons (those on the “create new recipe” too) yet since I just wanted to give you a general idea on what could be done with the interface. In a fleshed out app it would likely either just sit centered or be in the top row, of the recipe list, right below the checkboxes.

Aaaaanyways, take from that what you will, in the end it is and always will be your app. Not only do tastes differ but even UX can be quite subjective. What makes sense for one person doesn’t necessarily make sense for another - that’s just how it is. There is certain trends, but not all apps adhere to them for good reason. So take everything I said with a grain of salt but be open for suggestions.

“Talking” with you made me realize yet again, how complex UX really is and that a Skype call or even a chat would likely be more suited for those kinds of discussion. :smiley: It is fun nonetheless :slight_smile:


#13

Thank you once again for these insights. These are all very good ideas. I think now I will let some users play with this, and I will listen carefully to the responses. I tend to be fairly dogmatic - once I make up my mind, it’a hard to change except by a mathematical proof or irrefutable facts. But a lot of this is subjective, so one gets married to ones ideas. (One also burns out a little.) I think this discussion will make me much more receptive to comments, and will give me detailed and explicit alternatives which I can discuss with users. I am definitely willing to change the app- just not right this moment.

I see this rolling out in stages. Because of the photo upload problem, it can’t be commercial until I make it a real web application with a way to store the photos. (Or I will turn it into an iphone app - another possibility - or just a desktop/laptop app using python.) So my users will have to be friends and acquaintances and will have to use local storage, which can be dangerous. I won’t make it a web app until I finish the back-end part of FCC - hopefully in a few months.

In any event, I have to keep in mind that this is homework - the recipe challenge. For this assignment, I wanted to do something more complex and reasonably usable in practice, using a pure OO approach and creating as much as possible reusable classes for the UI and other objects, and also using React and SCSS, but not JSX or jQuery. (I’ve done a lot of OO in the past. I wanted to see how much was involved for web apps.) In this I think I did reasonably well, and learned a huge amount in the process. I did way more than the challenge called for, but on purpose. Also this app is completely scalable, both horizontally AND vertically, from window widths between 300 and 700 px. (Everything derives from the window width.) That also was a goal.

I would like to see some of your FCC challenges or web sites you have developed. Can you send me (via this forum) some links. Is there some way we could chat privately rather than through the forum?

I am now going on to data visualization and the back end, then come back to the Rogue dungeon game if I feel like it (this app took a lot out of me - I need to just learn stuff for a week or two.) I don’t think the Rogue dungeon game will do much for me, but I could be wrong.


#14

Hi, got the link working now. I can see you have put a lot of effort into the different options for the user. I won’t add to the user interface comments. A lot has been said already so I will save repeating that but I agree it needs some work.
I was looking at the React tools to see how you did things in the back-end and am surprised to see no components? As every div has got a key, I guess you have generated the whole thing in one component?
I don’t know. Can you explain a bit. I can’t see the pre-compiled code when it hosted on s3.
Any reason why you didn’t use JSX?


#15

I’m not sure what your question is. To see how I use React, go to
https://powerful-ravine-22665.herokuapp.com/index,
click on “javascript tutorials” then “Introduction to Raw React”. In a very straightforward way (I think), this PDF will walk you through using React with Javascript classes, and without React components or JSX.


#16

addendum - it might be helpful if you could reference a particular place in that PDF and ask a question about that.

I didn’t use JSX because (1) it’s syntactic sugar and (2) I don’t like preprocessors and (3) in my way of doing things, I can use all of Javascript without restrictions.

It just seems easier to me!


#17

I thought one of the benefits of React components is speed. In this app its not really a problem but in a large app, who knows?
I will research the topic. I’ve never seen Raw React and there is nothing in that document to explain why you would use it over “normal” React.
I get it is your preference to not use pre-processors but what about SASS, LESS for CSS?
Jade, Pug for HTML? CoffeeScript, TypeScript for JS? Are you avoiding all these too?
They are all designed so you can write more efficient readable code.
If your code is on GitHub or somewhere, perhaps I could get a better idea?


#18

OK, I should explain.

My personal philosophy in the world of programming is this: Don’t do me any favors!!

In practice, this means that, in a job situation, I will use whatever package or idiom is required, but absent that (and especially for my own projects) I like to stick with the basics. For me, basics means significant functionality. In web development environment this translates to (for me) Javascript (including SVG, etc), CSS, d3js, (raw) React. (The term “raw react” is mine - I’ve never seen it anywhere.)

This means (for me) less memorization, fewer additional syntaxes, less confusion, fewer (online) manuals. In addition, a new package means new bugs over which I have no control.

Unless this is a job or interview situation, I stick with what I think of as the basics. It’s personal. I’m a committed OOP programmer. It’s in my bones. The way I use React is how I decided it merges well with an OOP approach. It’s probably not for everyone (or possibly not anyone).

I am not a wonderful programmer. I’m certainly not bragging about my programming prowess or insights. (The persons who did d3js or React can program rings around me.) I just get the job done.

But if you like, in the link in the previous reply click on “Small Javascript Projects”, then choose one. Then look at the code in the browser. For my most recent project - a library with lots of documentation and examples and one in which I use React effectively - click on “Javascript Resize Framework” and then “Resizing Framework”. This will give you an insight into how I look at things (if that interests you). I suspect you will be better off not bothering.