user interface review proposal

[Jeff Fortin]

Hello folks,

I am hobbyist user interface designer (usability nazi) and I would like to make a big review of gourmet's UI.

Possibly by doing a screencast showing everything that I find really weird and unintuitive in the UI, or stuff that goes against the HIG ( http://developer.gnome.org/projects/gup/hig/draft_hig_new) if applicable. It would be faster and more efficient than writing yet another long winded article.

Would you guys be interested?

Jeff

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel

[Brian Ackermann]

I think its a good idea...Personally, I STINK at UI stuff, so I'd just enjoy sitting and listening to someone who more or less knows what an interface SHOULD do.  I would benefit from it, personally, anyhow!

Brian Ackermann

Kiddo wrote:

Hello folks,

I am hobbyist user interface designer (usability nazi) and I would like to make a big review of gourmet's UI.

Possibly by doing a screencast showing everything that I find really weird and unintuitive in the UI, or stuff that goes against the HIG ( http://developer.gnome.org/projects/gup/hig/draft_hig_new) if applicable. It would be faster and more efficient than writing yet another long winded article.

Would you guys be interested?

Jeff

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel
  

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel

[Thomas Mills Hinkle]

Any contribution to the project is always welcome. My gut is that a screencast showing what's wrong with the interface, for all good intentions, might end up being more demoralizing than helpful. However, making a good list of problems to fix and proposing concrete solutions would be pretty helpful, and we might be able to fix them in a quick way.

Also, thinking of ways to help people get involved in the actual coding might help some of the problems you discover actually get fixed. Python's an easy beginner's language -- I'd be open to proposals for how we lower the barrier to getting involved working on the source code itself.

So, short version -- yes, anything would be useful and welcome.

Long version, I see three kinds of possible contributions, which vary in usefulness:

1. A general review/screencast, as you propose -- I think this would be the least useful since it doesn't necessarily list the specific problems in a way that makes them easy to fix, but it would lay the groundwork for someone else to go through and create specific proposals and bug reports (but who would do that?).

2. Bug reports.This is the most useful: figure out how to go from a general impression ("this is confusing") to a clear description of a problem with a clear proposal for a fix or, even better, patches!

3. Big picture solutions/design proposals. These could be submitted as feature requests if they're relatively specific, or they could be discussed on the mailing list (especially if they're debatable/general proposals, rather than clear fixes).

Regarding #3, there are several problems that to me have no obvious solution, and I'd love to hear ideas for solving them. Among them are:

* Is there a reasonable way to handle ingredient keys? Assume that users want to be able to:
      A) have ingredients that are the same combine on their shopping list, regardless of how those ingredients are described in the recipe
      B) Get nutritional information about recipes by linking ingredients in recipes to USDA info.
      C) Have a display of ingredients when they look at recipes to cook from that looks like what they're used to?

  What Gourmet currently does it my best approximation to solving this problem in a clear, non-intrusive way. I know it works better than  
  other software I've tried, but it's still complex and potentially confusing.

* Is there a way to let people input of "or" style ingredients? The problem is to go smoothly between our natural language representations ("1 pound cheddar or jack cheese") and something the computer can understand for purposes of compiling shopping lists, nutritional info, etc.
 
* What's the nicest way to handle nutritional information? Remember the complexity of dealing with different units, densities, etc.

* What would an ideal interface for the generic web importer look like? (the current one was created as a functional, better-than-nothing solution. I use it all the time and it works, but it still doesn't strike me as a proper solution).

Tom
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel

[Jeff Fortin]

2007/7/17, Thomas Mills Hinkle <tmhinkle@...>:

Any contribution to the project is always welcome. My gut is that a screencast showing what's wrong with the interface, for all good intentions, might end up being more demoralizing than helpful. However, making a good list of problems to fix and proposing concrete solutions would be pretty helpful, and we might be able to fix them in a quick way.

Don't worry, I actually installed 0.13 today. I don't remember gourmet looking so good before, I assume you guys changed some UI parts already since 0.8, am I wrong? :) my review might be a lot lighter than I thought. Not sure. I'll try using it today and see what I stumble upon.

Also, thinking of ways to help people get involved in the actual coding might help some of the problems you discover actually get fixed. Python's an easy beginner's language -- I'd be open to proposals for how we lower the barrier to getting involved working on the source code itself.

If it's a very small cosmetic fix (like misaligned text or bad spacing), I can most likely make a patch (hey I indeed just realized that gourmet is written in python. That's nice!). I do kind of suck at coding though :) my only knowledge of python comes from Specto.

2. Bug reports.This is the most useful: figure out how to go from a general impression ("this is confusing") to a clear description of a problem with a clear proposal for a fix or, even better, patches!

I will note down issues I find along the way in order to make a "not boring unprepared screencast", they will also serve for bug reports (I'll have to make the big effort of using sourceforge's terrible bug tracker ;)

3. Big picture solutions/design proposals. These could be submitted as feature requests if they're relatively specific, or they could be discussed on the mailing list (especially if they're debatable/general proposals, rather than clear fixes).

Of course. UI design is not an exact science. We're not called UI nazis for nothing! :)

Regarding #3, there are several problems that to me have no obvious solution, and I'd love to hear ideas for solving them. Among them are:

* Is there a reasonable way to handle ingredient keys? Assume that users want to be able to:
      A) have ingredients that are the same combine on their shopping list, regardless of how those ingredients are described in the recipe
      B) Get nutritional information about recipes by linking ingredients in recipes to USDA info.
      C) Have a display of ingredients when they look at recipes to cook from that looks like what they're used to?

  What Gourmet currently does it my best approximation to solving this problem in a clear, non-intrusive way. I know it works better than  
  other software I've tried, but it's still complex and potentially confusing.

* Is there a way to let people input of "or" style ingredients? The problem is to go smoothly between our natural language representations ("1 pound cheddar or jack cheese") and something the computer can understand for purposes of compiling shopping lists, nutritional info, etc.
 
* What's the nicest way to handle nutritional information? Remember the complexity of dealing with different units, densities, etc.

* What would an ideal interface for the generic web importer look like? (the current one was created as a functional, better-than-nothing solution. I use it all the time and it works, but it still doesn't strike me as a proper solution).

I will have to think hard about all that :)
By the way, how can I run gourmet CVS without installing it? (I don't want to do a sudo setup.py install)

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel

[Thomas Mills Hinkle]

By the way, how can I run gourmet CVS without installing it? (I don't want to do a sudo setup.py install)

There should be but there wasn't. I just committed a script in src/ called gourmet_in_place. Just run that and you should be able to run the Gourmet in place.

Tom

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel

[Jeff Fortin]

I just committed a script in src/ called gourmet_in_place. Just run that and you should be able to run the Gourmet in place.

Thanks. I get a traceback trying to run it in place however, not sure if I did it right:


jeff@khloe:~/trunks/gourmet/src$ ./gourmet_in_place
['/home/jeff/trunks/gourmet/src/foo', '/home/jeff/trunks/gourmet/src', '/usr/lib/python25.zip', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages/Numeric', '/usr/lib/python2.5/site-packages/PIL', '/usr/lib/python2.5/site-packages/gst- 0.10', '/var/lib/python-support/python2.5', '/usr/lib/python2.5/site-packages/gtk-2.0', '/var/lib/python-support/python2.5/gtk-2.0', '/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode']
Traceback (most recent call last):
  File "./gourmet_in_place", line 41, in <module>
    import gourmet.GourmetRecipeManager
  File "/home/jeff/trunks/gourmet/src/foo/gourmet/GourmetRecipeManager.py", line 5, in <module>
    import keyEditor, valueEditor, batchEditor
  File "/home/jeff/trunks/gourmet/src/foo/gourmet/keyEditor.py", line 10, in <module>
    import nutrition.nutritionDruid as nutritionDruid
  File "/home/jeff/trunks/gourmet/src/foo/gourmet/nutrition/nutritionDruid.py", line 8, in <module>
    from nutritionInfoEditor import NutritionInfoIndex,MockObject
ImportError: No module named nutritionInfoEditor

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel

[Jeff Fortin]

I just finished my basic generic review in a OGG Theora video screencast (1024x768, 50 MiB). I apologise in advance for my crappy microphone and my strange accent :)

You can download it on my slow (and unstable) home server here: http://open-source.ecchi.ca/projets/gourmet/gourmet-ui-review.ogg

The parent folder also contains glade files that I modified from CVS, they are mainly fixing cosmetic issues, not real usability "problems". They are a lot cleaner both for the user and the guy who has to mess with glade files though :)

A (huge) patch for that is here: http://open-source.ecchi.ca/projets/gourmet/gourmet-cvs-glade.patch

I restrained myself from changing/removing items that I really felt were "sensitive" (subject to debate), as I did not want to break the thing either. Please be aware that I did not test this in the real world as I cannot run gourmet in place (at the moment of writing this); as far as I know, cutting and pasting items in Glade2 most likely (hopefully?) did not affect widget IDs and signals so (fingers crossed) it should run.

Oh, and I did not speak on Tom's "big picture solutions" questions yet, as they will require me to think a lot more than what I did so far :)

I hope it helps.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel

[Thomas Mills Hinkle-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

On 7/17/07, Kiddo <nekohayo@...> wrote:

I just finished my basic generic review in a OGG Theora video screencast (1024x768, 50 MiB). I apologise in advance for my crappy microphone and my strange accent :)

You can download it on my slow (and unstable) home server here: http://open-source.ecchi.ca/projets/gourmet/gourmet-ui-review.ogg

The parent folder also contains glade files that I modified from CVS, they are mainly fixing cosmetic issues, not real usability "problems". They are a lot cleaner both for the user and the guy who has to mess with glade files though :)

Hmm -- I can't get the video file to play with totem, mplayer, or vlc. All three poop out after trying to load it. Errors below.

Has anyone else gotten this to play?

Tom

VLC

VLC media player 0.8.6 Janus
X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  141 (XVideo)
  Minor opcode of failed request:  19 ()
  Serial number of failed request:  82
  Current serial number in output stream:  83

Mplayer

Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
[theora @ 0x8939638]Missing extradata!
Could not open codec.
VDecoder init failed :(
Opening video decoder: [theora] Theora/VP3
VDec: vo config request - 1024 x 768 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.33 :1 - prescaling to correct movie aspect.
VO: [xv] 1024x768 => 1024x768 Planar YV12
Selected video codec: [theora] vfm: theora (Theora (free, reworked VP3))
==========================================================================
==========================================================================
Forced audio codec: mad
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 22050 Hz, 2 ch, s16le, 45.3 kbit/6.42% (ratio: 5666->88200)
Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis decoder)
==========================================================================
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
X11 error: BadAlloc (insufficient resources for operation)?,?% 0 0


MPlayer interrupted by signal 6 in module: vo_check_events
- MPlayer crashed. This shouldn't happen.
  It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
  gcc version. If you think it's MPlayer's fault, please read
  DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
  won't help unless you provide this information when reporting a possible bug.


Totem

xine: found demuxer plugin: OGG demux plugin
video discontinuity #1, type is 0, disc_off 0
waiting for audio discontinuity #1
audio discontinuity #1, type is 0, disc_off 0
waiting for in_discontinuity update #1
vpts adjusted with prebuffer to 54288
demux_ogg: Theorastreamsupport is highly alpha at the moment
load_plugins: plugin theora will be used for video streamtype 3e.
load_plugins: plugin vorbis will be used for audio streamtype 09.
audio_alsa_out: audio rate : 22050 requested, 48000 provided by device/sec
audio_alsa_out:open pause_resume=0
output sample rate 48000
will resample audio from 22050 to 48000
xine_play
libtheora:Received an bad packet
diff=1 (pts=1, last_pts=0)
video discontinuity #2, type is 2, disc_off 1
waiting for audio discontinuity #2
audio discontinuity #2, type is 2, disc_off 1
waiting for in_discontinuity update #2
libtheora:Received an bad packet
video jump
audio jump, diff=0
The program 'totem' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 87 error_code 11 request_code 141 minor_code 19)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)





-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel

[Jeff Fortin]

Hmm -- I can't get the video file to play with totem, mplayer, or vlc. All three poop out after trying to load it. Errors below.

I am assuming you have an Intel video chip like on some of my computers. It seems they don't want to play high res videos (If somebody knows why, I would be interested in knowing). In the meantime, I resized the video to a smaller resolution which plays fine on my intel chip.

http://open-source.ecchi.ca/projets/gourmet/gourmet-ui-review-684x512.ogg

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel

[Thomas Mills Hinkle]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Forgot to CC the list -- here this is again...

On 7/19/07, Kiddo <nekohayo@...> wrote:

Hmm -- I can't get the video file to play with totem, mplayer, or vlc. All three poop out after trying to load it. Errors below.

I am assuming you have an Intel video chip like on some of my computers. It seems they don't want to play high res videos (If somebody knows why, I would be interested in knowing). In the meantime, I resized the video to a smaller resolution which plays fine on my intel chip.

http://open-source.ecchi.ca/projets/gourmet/gourmet-ui-review-684x512.ogg

The low-res screencast works. Thanks for all your work on this!

I started going through the patch, but it's not at all obvious from reading it what the changes are (thanks to glade's design) and at least in some cases I wasn't sure I agreed with changes, so I want to look at them closely. At the bottom of this message I have my response to those bits of the patch I got through -- however, it occurred to me it would be much easier if you just wrote me what you changed in each file -- then I can apply or reject changes in a more sane way.

Here's a list of the individual issues as listed:

Combo Box Alignment in Search - I agree this is a bit odd. I tracked down and fixed the bug, oddly in the midst of my code that makes combo boxes work with the keyboard.

Toolbox Size/Separator Shift -- Patch accepted for separator shift. We need someone to work on the icons. I believe that svg is not the preferred method, though, as simply scaling icons does not create good-looking small icons (details visible in toolbar-size resolution should be eliminated in menu-sized icons, etc.). I am not an artist, so I'll count on the goodwill of others to fix these up (just as I counted on the goodwill of others to create them in the first place!).

Website dialog should include supported website list -- I think this would be overwhelming. Presumably if you're opening the "import website" dialog, it's because you already have a website you want to import it -- whether it works automatically or needs tweaking is immaterial. I could see adding a link in the dialog saying something like "see websites with support for automatic processing" or something less clunky sounding -- this would bring up a full list, generated real-time based on the website plugins in the current version.

In index view, ellipsize websites rather than wrapping them -- fixed on my development machine, to be committed soon.

Regarding discussion of the source vs. website distinction, I think we could actually eliminate the websites from the index view altogether by default -- that's what I do on my set up anyway. The distinction, however, is useful, at least for me -- I like to sort by source, which may be a person, a website, or a book -- and I don't want all the detailed info of the exact URL screwing up my sort. I've changed the default settings to eliminate the website field as well as others that many users likely don't care about: Servings, Preparation Time, Cooking Time. This should make for a less cluttered index view by default. Existing users will have their preferences maintained, so they won't see the change.

The ghost-window problem: has to do with Gourmet's workaround for remembering the positions of windows. There's no "right" way to do this within gtk -- the assumption is that window managers should handle this long term or something like that. I like the idea that windows open up where I had them last. Should be an individual bug report. (Note - this behavior is disabled on windows, I believe, since there were more serious bugs with how gtk remembered/restored window position on that platform).

Search Results Line - There are two uses to this part of the page. One, it gives you a keyboard shortcut to focus the results -- this is helpful for non-mouse-centric users. Two, it shows the number of results, which is helpful if you have a large number of recipes.

Shopping List - I'm not sure you've understood the purpose of the "pantry". It's not intuitive, but it's extremely useful -- it's one of the features I find the most useful in day-to-day use, since it solves the problem of how to create shopping lists given the fact that I usually have quite a number of the ingredients already and don't need to buy them. I'd be interested in seeing a redesign of the window without the resizeable panes, as these are deprecated as you've pointed out. However, I'm pretty committed to the side-by-side stuff-to-buy / stuff-not-to-buy view.


Patch:

app.glade - patch accepted -- changes seem reasonable.

timerDialog.glade - patch rejected. The clutter you removed has a purpose -- when there is a note on the timer, it is included in that label. This is the most common way I expect the timer to be used -- you click on "20 minutes" somewhere in a recipes instructions, and it comes up with the sentence in question in the dialog so you know what it's talking about. When the timer goes off, you know which timer went off because there is a note there telling you what it was for (you can create the same effect by typing a "note" in a hand-made timer.

converter.glade - patch rejected. I at least prefer the old design to the new. If others agree your design is better, that's fine. But I think the extra space and the big "to" and "from" labels makes things clearer. (For what it's worth, this wasn't my design -- this was redone by another usability helper-outer).

Below are files changed where I haven't taken the time to see what the changes are -- please let me know what's changed in each so I can look at it more carefully:

generic_importer.glade
nutritionDruid.glade
preferenceDialog.glade
recSelector.glade
recipeMerger.glade
valueEditor.glade

Tom
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel

[Jeff Fortin]

I started going through the patch, but it's not at all obvious from reading it what the changes are (thanks to glade's design) and at least in some cases I wasn't sure I agreed with changes, so I want to look at them closely. At the bottom of this message I have my response to those bits of the patch I got through -- however, it occurred to me it would be much easier if you just wrote me what you changed in each file -- then I can apply or reject changes in a more sane way.

Yeah, since I moved elements around in glade, the result is pretty much unreadable by naked eyes, it's more like a "try it on" patch I guess :)
Commenting everything might be out of my ability (as the patch is a result of moving things around and deleting LOTS of widgets and weird spacing), but if I can get the time, I might attach some explanation comments or two :|

Combo Box Alignment in Search - I agree this is a bit odd. I tracked down and fixed the bug, oddly in the midst of my code that makes combo boxes work with the keyboard.

Great :)

Toolbox Size/Separator Shift -- Patch accepted for separator shift. We need someone to work on the icons. I believe that svg is not the preferred method, though, as simply scaling icons does not create good-looking small icons (details visible in toolbar-size resolution should be eliminated in menu-sized icons, etc.). I am not an artist, so I'll count on the goodwill of others to fix these up (just as I counted on the goodwill of others to create them in the first place!).

I could give a try at recreating those icons in tango style with inkscape, providing an SVG with various pixel perfect versions as well (I will have to learn how to do that). Adding that to my (long) todo list.

Website dialog should include supported website list -- I think this would be overwhelming. Presumably if you're opening the "import website" dialog, it's because you already have a website you want to import it -- whether it works automatically or needs tweaking is immaterial. I could see adding a link in the dialog saying something like "see websites with support for automatic processing" or something less clunky sounding -- this would bring up a full list, generated real-time based on the website plugins in the current version.

I completely agree, your implementation would be better than hardcoding/writing the website list like I initially thought, and it would be indeed cleaner to hide it in an info/help button :)

In index view, ellipsize websites rather than wrapping them -- fixed on my development machine, to be committed soon.

Cool

Regarding discussion of the source vs. website distinction, I think we could actually eliminate the websites from the index view altogether by default -- that's what I do on my set up anyway. The distinction, however, is useful, at least for me -- I like to sort by source, which may be a person, a website, or a book -- and I don't want all the detailed info of the exact URL screwing up my sort. I've changed the default settings to eliminate the website field as well as others that many users likely don't care about: Servings, Preparation Time, Cooking Time. This should make for a less cluttered index view by default. Existing users will have their preferences maintained, so they won't see the change.

I felt that the default view was quite cluttered, but was not sure and refrained from starting a debate on that :)

The ghost-window problem: has to do with Gourmet's workaround for remembering the positions of windows. There's no "right" way to do this within gtk -- the assumption is that window managers should handle this long term or something like that. I like the idea that windows open up where I had them last. Should be an individual bug report. (Note - this behavior is disabled on windows, I believe, since there were more serious bugs with how gtk remembered/restored window position on that platform).

For the positioning problems, I believe I have experienced that and fixed it in Specto. If you take a look at some of the code, you might find something suiting gourmet (I have not checked if you used the same trick or not):
http://specto.googlecode.com/svn/trunk/spectlib/notifier.py (search for the function restore_size_and_position)
http://specto.googlecode.com/svn/trunk/spectlib/main.py (look at lines 519 and 520: the window is moved before being shown, so the user doesn't see any "jumping" window).

I hope that can help.

Search Results Line - There are two uses to this part of the page. One, it gives you a keyboard shortcut to focus the results -- this is helpful for non-mouse-centric users. Two, it shows the number of results, which is helpful if you have a large number of recipes.

Maybe I'm talking nonsense as I know (py)gtk very little, but can't a keyboard shortcut be attached to the treeview directly? Also, I'm not entirely sure why knowing the number of results is helpful when you have a large number of recipes. I mean if you are filtering, the results gradually fade out until you only have a handful of them left, I'm don't quite understand how the number affects that. I guess I will have to try for myself with a large number of recipes.

Shopping List - I'm not sure you've understood the purpose of the "pantry". It's not intuitive, but it's extremely useful -- it's one of the features I find the most useful in day-to-day use, since it solves the problem of how to create shopping lists given the fact that I usually have quite a number of the ingredients already and don't need to buy them. I'd be interested in seeing a redesign of the window without the resizeable panes, as these are deprecated as you've pointed out. However, I'm pretty committed to the side-by-side stuff-to-buy / stuff-not-to-buy view.

Um but my idea was to combine the pantry with the "to buy" items in a single treeview with multiple columns (item name, in stock, needed, to buy). Does it break the concept of the current pantry?

Here are some comments for my patch. Whenever you see spacing changes, that's because you put some crazy spacings everywhere on a per-widget basis, which ends up creating a gui that feels very... "hardcoded" if you see what I mean. What I did is generally remove those spacings everywhere and let the *table* or vbox/hbox widgets handle the spacing between child widgets. That way it is easier to maintain and everything is spaced with the same 3px increments (I usually use 6px and 12px).

Some spacing rules are here: http://developer.gnome.org/projects/gup/hig/draft_hig_new/design-window.html#window-layout-spacing

...but they do not explain how to do it "cleanly" in glade, which would be, I guess, leaving spacing to vbox/hboxes to handle instead of individual widgets (kind of like using CSS instead of HTML formatting).

Actually, my comments may not be very informative, you might want to compare glade files by opening them up side by side in glade instead, it is more obvious. So here I go:

generic_importer.glade

Fixed spacings according to HIG and to make the glade file simpler.

nutritionDruid.glade

Fixed the spacings, removed useless alignements/borders that looked weird inside the gtk notebook 

preferenceDialog.glade

 Fixed spacings, removed scrolled areas (preferences should not scroll, or you have something really weird going on) and kill those weird borders at the same time. Your prefs dialog now doesn't need to have a manual size set since you don't have scrolling stuff anymore, it will size up automatically.

recSelector.glade

Just the usual spacing cleanup, although here I would add that there is some very weird widget that I see in pretty much all of the other windows too, and would like to discuss its use. The gtk toolbar widget in the middle of a dialog window. I think you should just use hboxes, not toolbar widgets, because... well... it's not really a toolbar, and the borders of the toolbar widget look really out of place in the middle of a dialog, methinks.

recipeMerger.glade

Simple spacing fixes

valueEditor.glade

Yes, you guessed it: spacing fixes! On that note, I think you committed only part of the changes I did in app.glade, that means removing the separator and all that jazz, without committing the spacing fixes. I think those are important (well, pretty much my entire patch is consisting of removing 3-5 levels of piled up widgets and making the spacing simpler/more efficient), is there a reason for holding them back?



Oh and I still can't get gourmet_in_place to work. I get this error now with a vanilla cvs head:

jeff@kaname:~/trunks/gourmet$ ./src/gourmet_in_place
['/home/jeff/trunks/gourmet/foo', '/home/jeff/trunks/gourmet/src', '/usr/lib/python25.zip', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages/Numeric', '/usr/lib/python2.5/site-packages/gst- 0.10', '/var/lib/python-support/python2.5', '/usr/lib/python2.5/site-packages/gtk-2.0', '/var/lib/python-support/python2.5/gtk-2.0']
Traceback (most recent call last):
  File "./src/gourmet_in_place", line 20, in <module>
    from gourmet.OptionParser import *
ImportError: No module named gourmet.OptionParser

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel

[Thomas Mills Hinkle-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

On 7/19/07, Kiddo <nekohayo@...> wrote:

I started going through the patch, but it's not at all obvious from reading it what the changes are (thanks to glade's design) and at least in some cases I wasn't sure I agreed with changes, so I want to look at them closely. At the bottom of this message I have my response to those bits of the patch I got through -- however, it occurred to me it would be much easier if you just wrote me what you changed in each file -- then I can apply or reject changes in a more sane way.

Yeah, since I moved elements around in glade, the result is pretty much unreadable by naked eyes, it's more like a "try it on" patch I guess :)
Commenting everything might be out of my ability (as the patch is a result of moving things around and deleting LOTS of widgets and weird spacing), but if I can get the time, I might attach some explanation comments or two :|

<snip>

Toolbox Size/Separator Shift -- Patch accepted for separator shift. We need someone to work on the icons. I believe that svg is not the preferred method, though, as simply scaling icons does not create good-looking small icons (details visible in toolbar-size resolution should be eliminated in menu-sized icons, etc.). I am not an artist, so I'll count on the goodwill of others to fix these up (just as I counted on the goodwill of others to create them in the first place!).

I could give a try at recreating those icons in tango style with inkscape, providing an SVG with various pixel perfect versions as well (I will have to learn how to do that). Adding that to my (long) todo list.

 Sounds great.

Website dialog should include supported website list -- I think this would be overwhelming. Presumably if you're opening the "import website" dialog, it's because you already have a website you want to import it -- whether it works automatically or needs tweaking is immaterial. I could see adding a link in the dialog saying something like "see websites with support for automatic processing" or something less clunky sounding -- this would bring up a full list, generated real-time based on the website plugins in the current version.

I completely agree, your implementation would be better than hardcoding/writing the website list like I initially thought, and it would be indeed cleaner to hide it in an info/help button :)

Cool.

<snip>

The ghost-window problem: has to do with Gourmet's workaround for remembering the positions of windows. There's no "right" way to do this within gtk -- the assumption is that window managers should handle this long term or something like that. I like the idea that windows open up where I had them last. Should be an individual bug report. (Note - this behavior is disabled on windows, I believe, since there were more serious bugs with how gtk remembered/restored window position on that platform).

For the positioning problems, I believe I have experienced that and fixed it in Specto. If you take a look at some of the code, you might find something suiting gourmet (I have not checked if you used the same trick or not):
http://specto.googlecode.com/svn/trunk/spectlib/notifier.py (search for the function restore_size_and_position)
http://specto.googlecode.com/svn/trunk/spectlib/main.py (look at lines 519 and 520: the window is moved before being shown, so the user doesn't see any "jumping" window).

I hope that can help.

Excellent -- will add taking a look at that to my todo list.

Search Results Line - There are two uses to this part of the page. One, it gives you a keyboard shortcut to focus the results -- this is helpful for non-mouse-centric users. Two, it shows the number of results, which is helpful if you have a large number of recipes.

Maybe I'm talking nonsense as I know (py)gtk very little, but can't a keyboard shortcut be attached to the treeview directly? Also, I'm not entirely sure why knowing the number of results is helpful when you have a large number of recipes. I mean if you are filtering, the results gradually fade out until you only have a handful of them left, I'm don't quite understand how the number affects that. I guess I will have to try for myself with a large number of recipes.

The recipes are paged to avoid performance problems. If you have, say 300 results, you look at only 10 at a time by default (the idea being we want to encourage users to add more search terms rather than page through the results). It's important to know whether there are 300 results or 30 -- 30 would be worth paging through; 300 would not.

Shopping List - I'm not sure you've understood the purpose of the "pantry". It's not intuitive, but it's extremely useful -- it's one of the features I find the most useful in day-to-day use, since it solves the problem of how to create shopping lists given the fact that I usually have quite a number of the ingredients already and don't need to buy them. I'd be interested in seeing a redesign of the window without the resizeable panes, as these are deprecated as you've pointed out. However, I'm pretty committed to the side-by-side stuff-to-buy / stuff-not-to-buy view.

Um but my idea was to combine the pantry with the "to buy" items in a single treeview with multiple columns (item name, in stock, needed, to buy). Does it break the concept of the current pantry?

Ok -- I get that better now. It doesn't break the concept, but I'm still not sure I like it. I like the ease of dragging between the two lists right now, and I like being able to eyeball the two -- i.e. "this is the stuff I have to buy" and then "this is the stuff I supposedly have".

A checkbox would make scanning hard, since it's not instantly obvious scanning down a treeview which items are checked and which aren't (you have to scan down and then left-to-right).

I could see using a strikethrough or font change to signal which items were going onto the shopping list and which weren't. The strikethrough approach would be the most obvious (since the user instantly gets that "water" has been crossed off the list), but striked-through text is hard to read. I think I'd have to implement this in order to see if it was in fact easier or harder to use than the current system.

Here are some comments for my patch. Whenever you see spacing changes, that's because you put some crazy spacings everywhere on a per-widget basis, which ends up creating a gui that feels very... "hardcoded" if you see what I mean. What I did is generally remove those spacings everywhere and let the *table* or vbox/hbox widgets handle the spacing between child widgets. That way it is easier to maintain and everything is spaced with the same 3px increments (I usually use 6px and 12px).

Some spacing rules are here: http://developer.gnome.org/projects/gup/hig/draft_hig_new/design-window.html#window-layout-spacing

...but they do not explain how to do it "cleanly" in glade, which would be, I guess, leaving spacing to vbox/hboxes to handle instead of individual widgets (kind of like using CSS instead of HTML formatting).

Yeah, I more often feel like I'm fighting with glade than using it correctly. The ugly HTML metaphor is apt -- it's often hard to get things to space out properly and I often ended up resorting to individual alignments to do the job. 

Actually, my comments may not be very informative, you might want to compare glade files by opening them up side by side in glade instead, it is more obvious.

So here I go:

generic_importer.glade

Fixed spacings according to HIG and to make the glade file simpler.

Ok -- applying patch.

nutritionDruid.glade

Fixed the spacings, removed useless alignements/borders that looked weird inside the gtk notebook 

Hmm -- in some cases the spacing of the new file seems a bit worse -- namely, the treeviews which show search results end up in a smaller space. I'm applying the majority anyway because overall the fixes seem better than the regressions, and I'll trust you that you've simplified the internals so future fixes will be easier.

preferenceDialog.glade

 Fixed spacings, removed scrolled areas (preferences should not scroll, or you have something really weird going on) and kill those weird borders at the same time. Your prefs dialog now doesn't need to have a manual size set since you don't have scrolling stuff anymore, it will size up automatically.

Hmm -- I think the scrolling may be necessary on 800x600 resolution. The scrollbars shouldn't show up unless they're needed and there's no shadow, so it shouldn't make any difference. Hell, I wish windows all had scrolled windows embedded as a last resort. The hope is they never show up, but in case the screen is smaller or whatever, the scroll area saves you. I can't count the number of times I've had a GNOME dialog accidentally get too big to fit on the screen.

I also liked the bolded "title" telling you which tab your on -- I find I tend to  want a bolded element at the top of a window telling me what I'm looking at. This seems to echo standard practice -- a quick look at evolution (the first application I could think of that was guaranteed to have a big preferences window) followed this convention.

recSelector.glade

Just the usual spacing cleanup, although here I would add that there is some very weird widget that I see in pretty much all of the other windows too, and would like to discuss its use. The gtk toolbar widget in the middle of a dialog window. I think you should just use hboxes, not toolbar widgets, because... well... it's not really a toolbar, and the borders of the toolbar widget look really out of place in the middle of a dialog, methinks.

Don't know what the toolbar is doing there -- definitely should be changed to a regular old hbox. Wish glade made this easier. I've applied the other changes.

recipeMerger.glade

Simple spacing fixes

Ok, applied.

valueEditor.glade

Yes, you guessed it: spacing fixes!

 Accepted.

On that note, I think you committed only part of the changes I did in app.glade, that means removing the separator and all that jazz, without committing the spacing fixes. I think those are important (well, pretty much my entire patch is consisting of removing 3-5 levels of piled up widgets and making the spacing simpler/more efficient), is there a reason for holding them back?

Take a look at the latest commit -- I believe it should have your changes.

Oh and I still can't get gourmet_in_place to work. I get this error now with a vanilla cvs head:

Yeah -- it was a quick hack -- not quite complete yet.  It will take a little more work to actually work.

Tom

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Grecipe-manager-devel mailing list
Grecipe-manager-devel@...
https://lists.sourceforge.net/lists/listinfo/grecipe-manager-devel