GUI propagating consider and replaced by tags: Difference between revisions

From GO Wiki
Jump to navigation Jump to search
(New page: ==23rd February 2008:== Jen: I have been thinking through how best to fix this problem and have sent the following summary to the OBO-Edit list requesting feedback: Hi, I have been th...)
 
No edit summary
Line 6: Line 6:
I have been thinking through how best to fix this problem and have sent the following summary to the OBO-Edit list requesting feedback:
I have been thinking through how best to fix this problem and have sent the following summary to the OBO-Edit list requesting feedback:


Hi,
Hi,
 
I have been thinking about the options for a problem with replaced_by tags in OBO-Edit. I have some thoughts and I wondered if you could let me know what you think?
I have been thinking about the options for a problem with replaced_by tags in  
 
OBO-Edit. I have some thoughts and I wondered if you could let me know what you think?
The problem to solve:
 
The problem to solve:
When we obsolete a term that is mentioned in replaced_by tags of another obsolete term, we need to somehow update those old replaced_by tags to point to the terms listed as replaced_by under the newly obsoleted term. (When I say replaced_by I mean to imply replaced_by and consider tags.)
 
When we obsolete a term that is mentioned in replaced_by tags of another  
Options to solve this problem:
obsolete term, we need to somehow update those old replaced_by tags to point  
 
to the terms listed as replaced_by under the newly obsoleted term. (When  
1) Trigger something when the newer term is obsoleted.
I say replaced_by I mean to imply replaced_by and consider tags.)  
This wouldn't work as the new replaced by tags have not yet been added to the newly obsoleted term, so there is nothing to transfer.
 
Options to solve this problem:
2) Trigger something when a replaced_by tag is added to the newly obsoleted term.
This would work for the first replaced_by tag. However, any subsequent additions of replaced_by tags would not be propagated to the previously obsoleted term as the first replacement would remove the link between the previously obsoleted term and the newly obsoleted term.
1) Trigger something when the newer term is obsoleted.
 
This wouldn't work as the new replaced by tags have not yet been added to the  
3) Make a full set of propagations when the user saves the file. This would work as long a the user knows to add all all the replaced_by tags in one set before saving. I think this may lead to loss of information, as it is a very subtle thing to have to teach new users, and a pain to remember. However, it is actually what I always assumed OBO-Edit did, so I would consider this as a viable and intuitive option.
newly obsoleted term, so there is nothing to transfer.
 
4) Add an 'update replaced_by tags' menu item or button. It would be yet another control to have to teach people about, but at least it would do what it said, and do it when it was wanted. I also think this is a viable option. It would really mean that when we obsolete a term and add the replaced_by tags we just have to remember to trigger this control, and tell OBO-Edit that we are finished the obsoletion, and that it can now do a tidy-up step. This would be a relatively straight-forward control to set up. It could be set up to make itself obvious (perhaps change colour) as soon as an obsoletion occurs, as a reminder to the user.
2) Trigger something when a replaced_by tag is added to the newly obsoleted term.
 
This would work for the first replaced_by tag. However, any subsequent additions  
5) Make a new 'obsoletion panel' where you add the replaced_by tags before you obsolete the term. Would be yet another panel, and probably overkill, but it is an option. Construction would be simpler and quicker if it was based on the parent editor.
of replaced_by tags would not be propagated to the previously obsoleted term as
 
the first replacement would remove the link between the previously obsoleted  
I wondered if any of those would strike you as more intuitive than the others, or if you already had any different notion of what you would expect?
term and the newly obsoleted term.
 
Thanks,
3) Make a full set of propagations when the user saves the file. This would work  
 
as long a the user knows to add all all the replaced_by tags in one set before
Jen
saving. I think this may lead to loss of information, as it is a very subtle  
thing to have to teach new users, and a pain to remember. However, it is actually  
what I always assumed OBO-Edit did, so I would consider this as a viable and  
intuitive option.
4) Add an 'update replaced_by tags' menu item or button. It would be yet another  
control to have to teach people about, but at least it would do what it said, and
do it when it was wanted. I also think this is a viable option. It would really  
mean that when we obsolete a term and add the replaced_by tags we just have to  
remember to trigger this control, and tell OBO-Edit that we are finished the  
obsoletion, and that it can now do a tidy-up step. This would be a relatively  
straight-forward control to set up. It could be set up to make itself obvious  
(perhaps change colour) as soon as an obsoletion occurs, as a reminder to the user.
5) Make a new 'obsoletion panel' where you add the replaced_by tags before you  
obsolete the term. Would be yet another panel, and probably overkill, but it is  
an option. Construction would be simpler and quicker if it was based on the parent editor.
I wondered if any of those would strike you as more intuitive than the others,
or if you already had any different notion of what you would expect?
Thanks,  
Jen

Revision as of 07:54, 23 February 2009

23rd February 2008:

Jen:

I have been thinking through how best to fix this problem and have sent the following summary to the OBO-Edit list requesting feedback:

Hi,

I have been thinking about the options for a problem with replaced_by tags in 
OBO-Edit. I have some thoughts and I wondered if you could let me know what you think?

The problem to solve:

When we obsolete a term that is mentioned in replaced_by tags of another 
obsolete term, we need to somehow update those old replaced_by tags to point 
to the terms listed as replaced_by under the newly obsoleted term. (When 
I say replaced_by I mean to imply replaced_by and consider tags.) 

Options to solve this problem:

1) Trigger something when the newer term is obsoleted.
This wouldn't work as the new replaced by tags have not yet been added to the 
newly obsoleted term, so there is nothing to transfer.

2) Trigger something when a replaced_by tag is added to the newly obsoleted term.
This would work for the first replaced_by tag. However, any subsequent additions 
of replaced_by tags would not be propagated to the previously obsoleted term as
the first replacement would remove the link between the previously obsoleted 
term and the newly obsoleted term.

3) Make a full set of propagations when the user saves the file. This would work 
as long a the user knows to add all all the replaced_by tags in one set before
saving. I think this may lead to loss of information, as it is a very subtle 
thing to have to teach new users, and a pain to remember. However, it is actually 
what I always assumed OBO-Edit did, so I would consider this as a viable and 
intuitive option.  

4) Add an 'update replaced_by tags' menu item or button. It would be yet another 
control to have to teach people about, but at least it would do what it said, and
do it when it was wanted. I also think this is a viable option. It would really 
mean that when we obsolete a term and add the replaced_by tags we just have to 
remember to trigger this control, and tell OBO-Edit that we are finished the 
obsoletion, and that it can now do a tidy-up step. This would be a relatively 
straight-forward control to set up. It could be set up to make itself obvious 
(perhaps change colour) as soon as an obsoletion occurs, as a reminder to the user.

5) Make a new 'obsoletion panel' where you add the replaced_by tags before you 
obsolete the term. Would be yet another panel, and probably overkill, but it is 
an option. Construction would be simpler and quicker if it was based on the parent editor.

I wondered if any of those would strike you as more intuitive than the others,
or if you already had any different notion of what you would expect?

Thanks, 

Jen