Sometimes, you gotta look at the big picture

In the beginning, all I wanted was a widget that would allow me to add, edit, and delete entries in a table.  This seemed simple enough:

The icons seemed pretty self explanatory: plus was to create a new entry in the table; pencil allowed the user to modify an entry (after selecting one) and X was for deletion.  In the cases where the table would not have very many entries, this seemed like a pretty logical way to get things done.  (Of course there are a couple of use cases such as multiple add that this does not address, which has come up, but that is a separate topic).  I even did a couple of quick user reviews of this widget and those queried felt that the widget was pretty intuitive.

Life seemed pretty good until I actually used the widget.  When I had decided to use this type of widget, I had not considered the context in which the widget would be placed.  This lead to some amount of unexpected ambiguity.  Enter the bigger picture:

Notice how the checkboxes now seem ambiguous?  When I select those checkboxes, does it mean that I want to select those times for the schedule (the bigger picture), or does it mean that I want to perform some actions on the table that have "nothing" to do with the schedule itself?   I can say, with a little bit of reasoning, that the checkboxes are for management of the table and that all items in the table are times that will be used in the schedule.  However, this answer doesn't simply jump out, and it definitely makes the user think more than he should have to.

I'm sure some simple outlining of the table with its actions could help a little bit:  

But I don't think this solves all of the problem.  I haven't come up with a better solution yet, but the takeaway from this is: Look at the big picture when you design common controls.  There may be interactions that you don't even notice that will affect the usability of that component.