That is a great detailed reasoning, ThiloteE, at least in my reading. Thank you.
Your first point merger of
new article and
new entry is one point that I would definitively support. Though, as a footnote to this, is (something I mentioned ages ago, I think, on github) that if we remember something, would be ideal to also use remembering for “recommending” entry types, rather than hard coding these. But, ok, this is not the main issue of this conversation.
ad 2: I am not convinced by separating
new entry and
import by ID. When I search for literature within JabRef’s UI of external sources, then I do so in lieu of importing or constructing some entry by ID. But how about others? Do users often search externally without importing?
ad 3: This is key: simplify. If my prior ad 2 is accepted, then actually offering one view to search and add/configure an entry might be an interesting perspective. So, this could imply integrating the functions of
web search and
select new entry including
import by ID.
And this all assumes that users actually want to have two search fields, one for local search and one for external search. From a user perspective, might it be even more simple/straight forward to think of one “universal search” bar? JabRef has already a wonderful search bar. I could imagine a user logic by which I search both local and external sources simultaneously, and get offered to import an external entry (or merge). Though the latter would involve a rethinking of the external window by which external entries are represented. A compromise might also be: if my local search leads to nothing, JabRef might offer to me to switch to Web search instead.