User Interface improvements

[ockham]

Converted from SourceForge issue 1280930, submitted by SourceForge user jjongsma on 2005-09-02 19:20:23 UTC.

Absolutely wonderful program. A little non-intuitive
to use in some spots though. A couple problems I'm
having using the interface:

1. When a recipe is selected in index view, if I then
   try to double-click it to open it, it doesn't open - it
   turns into a text entry combo box. Double clicks
   should be consistent regardless of whether it was
   previously selected.

2. I would say don't even allow editing of recipe
   information in the index view. That's what the edit
   screen is for. It's non-intuitive, and removing that
   would solve Schema.org metadata for HTML exporter #1.

3. Same in the ingredient view. Use the ingredient
   editor to edit ingredients; don't edit them in the
   index view. Selecting an ingredient should just
   highlight the item and populate the ingredient editor
   below with its details.

4. Along the same lines of the last three - I would
   suggest splitting up view/edit functionality as a
   principle throughout the application. It would make
   the interface much more intuitive. For example, the
   recipe card view preferably shouldn't have tabs that
   allow you edit the recipe on it - the view and edit
   windows should be separate concepts. And the edit
   window should use the standard Apply / OK / Cancel
   buttons at the bottom rather than a "Save" in the toolbar.

5. The context menu disappears immediately when you
   release the right mouse button in the recipe index view.

6. I can't find a way to delete a bad ingredient in the
   key editor.

All in all a fantastically useful program though.
Especially love the unit conversions - lots of my
cookbooks are foreign and use weights for a lot of
things rather than volumes, so the unit/density
calculator is perfect.

[ockham]

Submitted by SourceForge user thomas_hinkle on 2006-05-20 18:00:51 UTC.

Logged In: YES
user_id=1030390

Editing has been disabled in the main recipe view. It
remains enabled in the ingredient view because the user
doesn't have another good reason to be clicking on
ingredients (the way they do for recipes).

[ockham]

Submitted by SourceForge user thomas_hinkle on 2006-01-02 14:40:58 UTC.

Logged In: YES
user_id=1030390

Just a note to say that after watching my mother (a pretty
advanced mac user) try to use the program for a while, I'm
convinced that editing should be disabled in the recipe list
view and will do that for the next version. Thanks for the
suggestion.

[ockham]

Submitted by SourceForge user jjongsma on 2005-09-04 02:16:22 UTC.

Logged In: YES
user_id=728145

Yeah, much of it is probably just user preference. I just
remember thinking "hmm, that's a little different" a lot
during my first experience with it... nothing big, mind you,
just little things like I mentioned.

I can definitely see why you like the index view from a
power user perspective, it just seems like an unexpected
feature to me. I don't like unexpected features because it
often results in me doing things I don't want to do - like
accidentally selecting a field and changing the category
without realizing what just happened, etc. Is it possible
to make it a preference - "Allow editing in index view"?

Re: edit/view separation - it just seems like 95% of the
time I don't need editing functionality for a specific
recipe, so it would make the interface much cleaner to have
one very simple recipe view window, and one more complex
notebook-interface editor window with the toolbar, etc. I
noticed in your interview that you use Gourmet mainly for
ingredient shopping lists, etc - maybe that accounts for
some of our difference in preference on this point... I like
to use it as my read-only cookbook 90% of the time, not as a
recipe editor. In those situations, all I want to do is 1)
search for a recipe, 2) display a recipe, 3) possibly do
unit conversions.

I've joined the list now and I do a bit of Python
development, so I'd be happy to participate in any
discussions and contribute where I can / when I have time.

For #6, I'm talking about the Tools / Ingredient Key Editor
dialog.

[ockham]

Submitted by SourceForge user thomas_hinkle on 2005-09-02 19:43:49 UTC.

Logged In: YES
user_id=1030390

Thanks for your suggestions/feedback.

Number 5 is obviously a straightahead bug -- perhaps you
could file a separate report so I remember to get to it
directly.

I'm not sure what you mean by #6 -- it may also be a
straightahead bug but I'll need some more clarification.
Again, it might be worth a separate bug report.

#s 1-4 are a bigger discussion -- I'd like to think about it
more and perhaps throw it to the mailing list or other
forums to see if I could get feedback from other users.

Here are my initial thoughts.

I like being able to edit elements of the recipe from the
index view. Often as I'm glancing at it, I'll notice a
missing e.g. category and want to fix it quickly. Waiting
the 2-3 seconds for the recipe card to show up, then
selecting "Details", then editing, seems too laborious.
Clicking on that cell of the column is much easier.

Another way of saying this is that I'm not sure I do want to
separate display from editing because the two concepts are
often linked -- for revising or updating, editing should be
as closely tied to display as possible, I think.

That said, I've also noticed the confusion about double
clicking. If you double click off to the left, you will get
a recipe card open. If you double click on a cell, you will
edit that cell. One reason this doesn't bother me as much is
that I'm a keyboard user at heart.

As to the recipe card -- the current "tabbed" recipe card
interface implements the separation you recommend using the
notebook interface. if I understand you correctly, you think
it would be better to have e.g. a separate dialog for
editing, is that right? It would certainly be easy enough to
do -- my only concern would be 1. creating excess windows
and 2. creating a second "object" for a single recipe might
be confusing. As it currently exists, I try to stick
closely to the idea that you have a searchable collection of
recipes which you can then click on to get individual
recipes, each in their own windows. Whether drawing on the
recipe-box/recipe-card metaphor or the
web-browser-search-and-open-links experience, the one-to-one
recipe-to-window correspondence seems pretty important to me.