Open jchartrand opened 7 years ago
SusanBrown
commented
7 years ago Decision: Start with the current API which will support initial search on a term, and see how it works.
@jefferya will supply @jchartrand with curl commands and URL to move ahead with.
jefferya
commented
7 years ago CWRC API for search (test server) - more info (https://github.com/cwrc/cwrc_entities#search) :
lynx 'http://cwrc-dev-05.srv.ualberta.ca/islandora/cwrc_entities/v1/search/person?query=austen&limit=100&page=0'Response:
{
"responseHeader": {
"status": 0,
"QTime": 30,
"params": {
"facet.limit": "1100",
"q": "(cwrc_entity_person_preferredForm_et:(austen) OR cwrc_entity_person_variantForm_et:(austen))",
"facet.field": [
"cwrc_facet_date_is_subject_temporal_s",
"cwrc_facet_date_10_ms",
"cwrc_facet_date_100_ms",
"cwrc_facet_date_ms"
],
"json.nl": "map",
"start": "0",
"facet.mincount": "1",
"fq": [
"RELS_EXT_hasModel_uri_ms:info\\:fedora\\/cwrc\\:person\\-entityCModel",
"-RELS_EXT_isConstituentOf_uri_mt:*",
"RELS_EXT_isViewableByUser_literal_ms:\"anonymous\" OR RELS_EXT_isViewableByRole_literal_ms:\"anonymous user\" OR ((*:* -RELS_EXT_isViewableByUser_literal_ms:[* TO *]) AND (*:* -RELS_EXT_isViewableByRole_literal_ms:[* TO *]))"
],
"rows": "100",
"facet": "true",
"version": "1.2",
"wt": "json"
}
},
"response": {
"numFound": 14,
"start": 0,
"objects": [
{
"solr_doc": [],
"PID": "cwrc:07f61614-8f91-4ad0-8f27-5c11aebc2ddd",
"object_url": "islandora/object/cwrc:07f61614-8f91-4ad0-8f27-5c11aebc2ddd",
"content_models": ["info:fedora/cwrc:person-entityCModel"],
"datastreams": [
"RELS-EXT",
"PERSON",
"DC",
"WORKFLOW"
],
"object_label": "Austen Kark",
"thumbnail_url": "sites/all/modules/islandora_solr_search/images/defaultimg.png",
"object_url_params": [],
"thumbnail_url_params": []
},
{
"solr_doc": [],
"PID": "cwrc:b6137900-94d1-4ef2-a2aa-a79fc14258c3",
"object_url": "islandora/object/cwrc:b6137900-94d1-4ef2-a2aa-a79fc14258c3",
"content_models": ["info:fedora/cwrc:person-entityCModel"],
"datastreams": [
"RELS-EXT",
"PERSON",
"DC",
"WORKFLOW"
],
"object_label": "James Austen",
"thumbnail_url": "sites/all/modules/islandora_solr_search/images/defaultimg.png",
"object_url_params": [],
"thumbnail_url_params": []
},
{
"solr_doc": [],
"PID": "cwrc:36e3378b-b078-412a-a465-0afeb53f55c7",
"object_url": "islandora/object/cwrc:36e3378b-b078-412a-a465-0afeb53f55c7",
"content_models": ["info:fedora/cwrc:person-entityCModel"],
"datastreams": [
"RELS-EXT",
"PERSON",
"DC",
"WORKFLOW"
],
"object_label": "Jane Austen",
"thumbnail_url": "sites/all/modules/islandora_solr_search/images/defaultimg.png",
"object_url_params": [],
"thumbnail_url_params": []
},
{
"solr_doc": [],
"PID": "cwrc:149d5a74-1d05-47ec-acc5-ebd2e0237df3",
"object_url": "islandora/object/cwrc:149d5a74-1d05-47ec-acc5-ebd2e0237df3",
"content_models": ["info:fedora/cwrc:person-entityCModel"],
"datastreams": [
"RELS-EXT",
"PERSON",
"DC",
"WORKFLOW"
],
"object_label": "Katherine Austen",
"thumbnail_url": "sites/all/modules/islandora_solr_search/images/defaultimg.png",
"object_url_params": [],
"thumbnail_url_params": []
},
{
"solr_doc": [],
"PID": "cwrc:5ac3aa1e-c612-4827-b7fa-6449a0b24520",
"object_url": "islandora/object/cwrc:5ac3aa1e-c612-4827-b7fa-6449a0b24520",
"content_models": ["info:fedora/cwrc:person-entityCModel"],
"datastreams": [
"RELS-EXT",
"PERSON",
"DC",
"WORKFLOW"
],
"object_label": "Charles Austen",
"thumbnail_url": "sites/all/modules/islandora_solr_search/images/defaultimg.png",
"object_url_params": [],
"thumbnail_url_params": []
},
{
"solr_doc": [],
"PID": "cwrc:5662d5b4-8e13-47c1-a123-77a739e69e5d",
"object_url": "islandora/object/cwrc:5662d5b4-8e13-47c1-a123-77a739e69e5d",
"content_models": ["info:fedora/cwrc:person-entityCModel"],
"datastreams": [
"RELS-EXT",
"PERSON",
"DC",
"WORKFLOW"
],
"object_label": "Thomas Austen",
"thumbnail_url": "sites/all/modules/islandora_solr_search/images/defaultimg.png",
"object_url_params": [],
"thumbnail_url_params": []
},
{
"solr_doc": [],
"PID": "cwrc:beb13ef0-0fca-4c86-a5da-e37a16d2fe3a",
"object_url": "islandora/object/cwrc:beb13ef0-0fca-4c86-a5da-e37a16d2fe3a",
"content_models": ["info:fedora/cwrc:person-entityCModel"],
"datastreams": [
"RELS-EXT",
"PERSON",
"DC",
"WORKFLOW"
],
"object_label": "George Austen",
"thumbnail_url": "sites/all/modules/islandora_solr_search/images/defaultimg.png",
"object_url_params": [],
"thumbnail_url_params": []
},
{
"solr_doc": [],
"PID": "cwrc:6219d4ce-b57b-4f6f-a519-c530417907f5",
"object_url": "islandora/object/cwrc:6219d4ce-b57b-4f6f-a519-c530417907f5",
"content_models": ["info:fedora/cwrc:person-entityCModel"],
"datastreams": [
"RELS-EXT",
"PERSON",
"DC",
"WORKFLOW"
],
"object_label": "Anna, Lady Austen",
"thumbnail_url": "sites/all/modules/islandora_solr_search/images/defaultimg.png",
"object_url_params": [],
"thumbnail_url_params": []
},
{
"solr_doc": [],
"PID": "cwrc:2126614f-c32c-46ca-a9fc-0d698ab688aa",
"object_url": "islandora/object/cwrc:2126614f-c32c-46ca-a9fc-0d698ab688aa",
"content_models": ["info:fedora/cwrc:person-entityCModel"],
"datastreams": [
"RELS-EXT",
"PERSON",
"DC",
"WORKFLOW"
],
"object_label": "Austen Chamberlain",
"thumbnail_url": "sites/all/modules/islandora_solr_search/images/defaultimg.png",
"object_url_params": [],
"thumbnail_url_params": []
},
{
"solr_doc": [],
"PID": "cwrc:5347fc48-3a63-437d-8f3e-ebffc82f67c7",
"object_url": "islandora/object/cwrc:5347fc48-3a63-437d-8f3e-ebffc82f67c7",
"content_models": ["info:fedora/cwrc:person-entityCModel"],
"datastreams": [
"RELS-EXT",
"PERSON",
"DC",
"WORKFLOW"
],
"object_label": "Edward Austen Knight",
"thumbnail_url": "sites/all/modules/islandora_solr_search/images/defaultimg.png",
"object_url_params": [],
"thumbnail_url_params": []
},
{
"solr_doc": [],
"PID": "cwrc:e70f1820-57c8-415d-b73d-523984ba539a",
"object_url": "islandora/object/cwrc:e70f1820-57c8-415d-b73d-523984ba539a",
"content_models": ["info:fedora/cwrc:person-entityCModel"],
"datastreams": [
"RELS-EXT",
"PERSON",
"DC",
"WORKFLOW"
],
"object_label": "William Austen-Leigh",
"thumbnail_url": "sites/all/modules/islandora_solr_search/images/defaultimg.png",
"object_url_params": [],
"thumbnail_url_params": []
},
{
"solr_doc": [],
"PID": "cwrc:723329d5-e696-4a81-aa66-6b9f642cf0fd",
"object_url": "islandora/object/cwrc:723329d5-e696-4a81-aa66-6b9f642cf0fd",
"content_models": ["info:fedora/cwrc:person-entityCModel"],
"datastreams": [
"RELS-EXT",
"PERSON",
"DC",
"WORKFLOW"
],
"object_label": "Cassandra Leigh Austen",
"thumbnail_url": "sites/all/modules/islandora_solr_search/images/defaultimg.png",
"object_url_params": [],
"thumbnail_url_params": []
},
{
"solr_doc": [],
"PID": "cwrc:21acf44b-10c0-4f3b-be2e-92b6369193e5",
"object_url": "islandora/object/cwrc:21acf44b-10c0-4f3b-be2e-92b6369193e5",
"content_models": ["info:fedora/cwrc:person-entityCModel"],
"datastreams": [
"RELS-EXT",
"PERSON",
"DC",
"WORKFLOW"
],
"object_label": "Richard Arthur Austen-Leigh",
"thumbnail_url": "sites/all/modules/islandora_solr_search/images/defaultimg.png",
"object_url_params": [],
"thumbnail_url_params": []
},
{
"solr_doc": [],
"PID": "cwrc:bfba9fc7-2562-4d2c-b003-6a8a39e02279",
"object_url": "islandora/object/cwrc:bfba9fc7-2562-4d2c-b003-6a8a39e02279",
"content_models": ["info:fedora/cwrc:person-entityCModel"],
"datastreams": [
"RELS-EXT",
"PERSON",
"WORKFLOW",
"DC"
],
"object_label": "Austen, Jane",
"thumbnail_url": "sites/all/modules/islandora_solr_search/images/defaultimg.png",
"object_url_params": [],
"thumbnail_url_params": []
}
]
},
"facet_counts": {
"facet_queries": [],
"facet_fields": {
"cwrc_facet_date_is_subject_temporal_s": {"": 14},
"cwrc_facet_date_10_ms": {
"1770 TO 1779": 1,
"1780 TO 1789": 1,
"1790 TO 1799": 1,
"1800 TO 1809": 1,
"1810 TO 1819": 1
},
"cwrc_facet_date_100_ms": {
"1700 TO 1799": 1,
"1800 TO 1899": 1
},
"cwrc_facet_date_ms": []
},
"facet_dates": [],
"facet_ranges": []
}
}@jchartrand @ilovan
Above is an example of the current API search request and response. Note, other Solr fields can be added or subtracted from the response.
The main parts are the "PID" and "object_label" fields in the response.
Questions: [ ] should the API support pagination? [ ] should the contents of the info box be returned in the response [ ] is there a better label than the Fedora Object label
jchartrand
commented
7 years ago So I would specify which solr fields should be included in a given result, using a request param? Or would you set the returned field set in a configuration file on the server, and it would affect all responses - i.e., the same solr fields would be returned for all queries? Either way is fine with me. In other words, I have no need to vary what fields are returned per query. So long as the fields are always the same. But, it’s probably worth asking: Mihaela, what would you like shown for each search result?
more below…
On Aug 25, 2017, at 5:51 PM, Jeffery Antoniuk notifications@github.com wrote:
@jchartrand https://github.com/jchartrand @ilovan https://github.com/ilovan Above is an example of the current API search request and response. Note, other Solr fields can be added or subtracted from the response.
The main parts are the "PID" and "object_label" fields in the response.
Questions: [ ] should the API support pagination?
Mihaela? How many results should be shown at one time, and should we support paging, or ask the user to refine their query if they can’t find their entity in the first set of results?
[ ] should the contents of the info box be returned in the response
I’m not sure what the info box is? Maybe this is a question for Mihaela?
[ ] is there a better label than the Fedora Object label
Another one for Mihaela?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cwrc/CWRC-PublicEntityDialogs/issues/4#issuecomment-325042244, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhZXa8olNu1v54NuyKOEl1kVNDVBFIEks5sb0HUgaJpZM4PAc-t.
ilovan
commented
7 years ago Re:
Re
Can we support infinite scrolling? It strikes me as a better option than pagination. Not sure how users could refine their search; the lookup would search the names fields in th entity record.
Decision: leave refinement for later
Re
The Info box, or the disambiguation box, would allow users to select the right entity when multiple entites have the same Standard name and or Fedora Label name). This would be available if we go with layout 2 or 3 for the returned results (see image above)
@SusanBrown , can you make a selection? What alyout do you think would work best? I am leaning towards result layout 2 with disambiguation pop-up b.
SusanBrown
commented
7 years ago This all looks good. Let's go with version 2. Logos should be at the right margin of the box. Ideally have the popup work from a mouse hover rather than a click. Agree that progressive loading would be better than pagination. I hear from Mihaela that the lookups in the github cwrc-writer are looking good--sounds like you've got info from external sources like VIAF loading nicely when one clicks on the links.
jchartrand
commented
7 years ago I'm pretty sure, however, that I can use a bootstrap 'popover' on top of the modal. The only downside is that the popover likely can't be structured or styled as much as a modal could. If, however, all we are showing in the popover is textual information, it might be fine. I mention all this just as a forewarning.
Triggering the popover from a mouseover should be fine.
Other entity sources (besides CWRC, and notably VIAF) don't return the information you've listed, at least not in their initial search results. We'd have to make a separate call to VIAF each time someone clicked on the question mark (or moused over the result). Which is fine when clicking on the question mark, and is what the old CWRC entity lookups did. But, the separate calls might make things appear a bit sluggish depending on how the given entity source feels that day. VIAF, for example, sometimes seems to feel blue (and therefore sluggish). Again, just a forewarning, and I don't really see anyway around it. But, if we make a call per mouseover, that might get trickier (I'd have to add a pause on the mouseover before making the http calls so it wouldn't fire calls willy nilly as the user moused around).
Infinite scrolling is of course do-able, but: a) is more work b) might not fill well with multiple result sets like ours where we have a collapsible panel for each entity source:
Would the infinite scrolling work within each panel?
This article also talks about why infinite scrolling can be unnecessary, distracting, etc:
https://www.smashingmagazine.com/2013/05/infinite-scrolling-lets-get-to-the-bottom-of-this/
Even standard paging will add a fair bit more work. The alternative is to stick at 5 or 10 or whatever number of results per entity source. And let the end user refine their query with extra keywords if they don't see the result they wan't.
I am happy to implement either (paging or infinite scroll) because it's likely interesting, but I feel obliged to point out that it will be more work.
SusanBrown
commented
7 years ago A popover sounds ok: let’s try it and see if styling is an issue.
Can you set it up so that the popover with the web info for the entity appears directly for sources such as VIAF that don’t return it with the first set of query results? CWRC entity pages are currently horrifically slow so we would do well to have an interim popover in that case, but for (all?) other sources it may be best to go straight to the fuller information set?
Pagination/Scrolling: Let’s say 20 results for now. I say that many because VIAF in particular seems to be really odd in its matches and often the right result is quite far down the list. Let’s see how that works and come back to the pagination/scrolling question if it’s a usability problem.
On Sep 7, 2017, at 1:19 PM, James Chartrand notifications@github.com wrote:
Your mockup suggests (I think) that a second 'info' dialog should be opened on top of the first entity lookup dialog. We use bootstrap modals for our dialogs, and bootstrap doesn't recommend opening multiple modals at once. Although people do still open multiple bootstrap modals, it seems asking for trouble down the road to disregard the bootstrap documentation. I'm pretty sure, however, that I can use a bootstrap 'popover' on top of the modal. The only downside is that the popover likely can't be structured or styled as much as a modal could. If, however, all we are showing in the popover is textual information, it might be fine. I mention all this just as a forewarning.
Other entity sources (besides CWRC, and notably VIAF) don't return the information you've listed, at least not in their initial search results. We'd have to make a separate call to VIAF each time someone clicked on the question mark. Which is fine, and is what the old CWRC entity lookups did. But, the separate calls might make things appear a bit sluggish depending on how the given entity source feels that day. VIAF, for example, sometimes seems to feel blue (and therefore sluggish). Again, just a forewarning, and I don't really see anyway around it.
Infinite scrolling is of course do-able, but: a) is more work b) might not fill well with multiple result sets like ours where we have a collapsible panel for each entity source:
https://user-images.githubusercontent.com/547165/30175677-88540150-93cd-11e7-84e4-f831bd320108.png Would the infinite scrolling work within each panel?
This article also talks about why infinite scrolling can be unnecessary, distracting, etc:
https://www.smashingmagazine.com/2013/05/infinite-scrolling-lets-get-to-the-bottom-of-this/ https://www.smashingmagazine.com/2013/05/infinite-scrolling-lets-get-to-the-bottom-of-this/ Even standard paging will add a fair bit more work. The alternative is to stick at 5 or 10 or whatever number of results per entity source. And let the end user refine their query with extra keywords if they don't see the result they wan't.
I am happy to implement either (paging or infinite scroll) because it's likely interesting, but I feel obliged to point out that it will be more work.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cwrc/CWRC-PublicEntityDialogs/issues/4#issuecomment-327865841, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhUoPbNWMsAKV4c11Wy9c9qyh2mNBioks5sgCUigaJpZM4PAc-t.
jchartrand
commented
7 years ago On Sep 7, 2017, at 1:46 PM, SusanBrown notifications@github.com wrote:
A popover sounds ok: let’s try it and see if styling is an issue.
Can you set it up so that the popover with the web info for the entity appears directly for sources such as VIAF that don’t return it with the first set of query results?
Sorry, I don’t understand what you mean by ‘the popover with the web info for the entity appears directly’? More specifically, what do you mean by ‘appears directly’?
CWRC entity pages are currently horrifically slow so we would do well to have an interim popover in that case, but for (all?) other sources it may be best to go straight to the fuller information set?
I don’t understand this either.
- Pagination/Scrolling: Let’s say 20 results for now. I say that many because VIAF in particular seems to be really odd in its matches and often the right result is quite far down the list. Let’s see how that works and come back to the pagination/scrolling question if it’s a usability problem.
Ok, and should the full 20 be shown in each entity panel, i.e., each entity source would show twenty results? that might make the page a bit long, but it would be scrollable. Alternatively, there could be scrolling within each entity panel.
A related question: should all entity panels be expanded by default?
On Sep 7, 2017, at 1:19 PM, James Chartrand notifications@github.com wrote:
Your mockup suggests (I think) that a second 'info' dialog should be opened on top of the first entity lookup dialog. We use bootstrap modals for our dialogs, and bootstrap doesn't recommend opening multiple modals at once. Although people do still open multiple bootstrap modals, it seems asking for trouble down the road to disregard the bootstrap documentation. I'm pretty sure, however, that I can use a bootstrap 'popover' on top of the modal. The only downside is that the popover likely can't be structured or styled as much as a modal could. If, however, all we are showing in the popover is textual information, it might be fine. I mention all this just as a forewarning.
Other entity sources (besides CWRC, and notably VIAF) don't return the information you've listed, at least not in their initial search results. We'd have to make a separate call to VIAF each time someone clicked on the question mark. Which is fine, and is what the old CWRC entity lookups did. But, the separate calls might make things appear a bit sluggish depending on how the given entity source feels that day. VIAF, for example, sometimes seems to feel blue (and therefore sluggish). Again, just a forewarning, and I don't really see anyway around it.
Infinite scrolling is of course do-able, but: a) is more work b) might not fill well with multiple result sets like ours where we have a collapsible panel for each entity source:
https://user-images.githubusercontent.com/547165/30175677-88540150-93cd-11e7-84e4-f831bd320108.png Would the infinite scrolling work within each panel?
This article also talks about why infinite scrolling can be unnecessary, distracting, etc:
https://www.smashingmagazine.com/2013/05/infinite-scrolling-lets-get-to-the-bottom-of-this/ https://www.smashingmagazine.com/2013/05/infinite-scrolling-lets-get-to-the-bottom-of-this/ Even standard paging will add a fair bit more work. The alternative is to stick at 5 or 10 or whatever number of results per entity source. And let the end user refine their query with extra keywords if they don't see the result they wan't.
I am happy to implement either (paging or infinite scroll) because it's likely interesting, but I feel obliged to point out that it will be more work.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cwrc/CWRC-PublicEntityDialogs/issues/4#issuecomment-327865841, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhUoPbNWMsAKV4c11Wy9c9qyh2mNBioks5sgCUigaJpZM4PAc-t.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cwrc/CWRC-PublicEntityDialogs/issues/4#issuecomment-327873218, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhZXWJiAhF_bgZrQRnDS17IWzWqhSWDks5sgCvbgaJpZM4PAc-t.
SusanBrown
commented
7 years ago jchartrand
commented
7 years ago This is what the gitWriter lookup (that Mihaela mentioned) looks like:
and when you click on any one result in the dropdown you get:
i.e. the VIAF web page for that single result is shown in an iframe within the popup.
But, now it sounds like you are suggesting a popover for each VIAF result, i.e., 10 popovers, all visible when the dialog opens?
Note that I’ve changed the lookup dialogs (but not yet on the ‘public’ DAIR version) so that the dialogs don’t use a lookahead drop down like above, but instead show the results in a collapsible panel, like the picture I showed earlier in the thread:
And so what I thought was that each result, in each collapsible panel, would, on mouseover, show a popover (like the ones you see at the bottom of this code snippet: https://codepen.io/zeasts/pen/mPLEQe)
I think we are just thrashing on this now - could you draw a sketch of what you want, and then if necessary we could Skype?
On Sep 7, 2017, at 2:05 PM, SusanBrown notifications@github.com wrote:
I understood from Mihaela that in the gitCWriter the lookups were rendering in a popover the full VIAF record info as accessible on the web. Such information for CWRC entities is rendered through the entity aggregation pages, which suffer from a bug that means they take minutes to load, therefore for CWRC entities it would be best for the moment to load the interim popover as indicated in Mihaela's sketch. However, it might be best for consistency then to go with option 1 in her sketch, providing that additional info right in the list, dates at least, and consistently providing the fuller view of info in the popover. In the immediate future this will be agonizingly slow for CWRC but hopefully the additional info will help make it less frequent and the overall user experience would be more consistent. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cwrc/CWRC-PublicEntityDialogs/issues/4#issuecomment-327878466, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhZXR8Q2FW_mnS7mXB-3PucHAc16DkVks5sgDBRgaJpZM4PAc-t.
jchartrand
commented
7 years ago I've reread this and I think I now understand what you mean by 'interim' - a popover that shows only information that was available in the initial search call, as opposed to a 'full' popover that shows the full web/html page for the individual result in an iframe.
So if there is to be an interim popover for the CWRC results (and possibly also for results from other entity sources if those sources are also slow) then 'interim' suggests (assuming interim means 'temporary') that there will be a 'full' (or 'final') popover available for those results? If so, how/when will the 'full' popover be shown? Or by 'interim' did you mean just that the popover would contain only pre-fetched information, i.e. only the information that comes back in the search result?
It's worth keeping in mind that for the CWRC entity results, the server side system will be rewritten, and so Jeff (or whoever rewrites it) can put whatever information you want directly into the search results, obviating any need for a subsequent call to show the 'full' record (which is I think why Jeff asked this question to begin with, i.e., what do you want in the search results).
I'll go ahead assuming that each result will show a popover (triggered by a mouseover with a delay of a second or two) that shows either an iframe with the full HTML page for the result if that can be fetched quickly, or if the full web page can't be fetched quickly, then shows whatever information is available in the search results.
I've checked quickly and it does seem that I can put an iframe into a bootstrap popover, but I've yet to fully confirm that. If it turns out not to be true, we'll have to revisit.
I will use Mihaela's entity layout result 2, assuming that you want the results to look consistent across entity sources. I can't show layout 1 for VIAF because there is limited info available in the VIAF initial search results. On the other hand, the CWRC results will already look different from other results since the CWRC results will show the project logo for each result. In any case, we can change what's shown in the CWRC results later (and I don't think the CWRC results will be ready for a few months anyhow?)
No need to answer this unless you disagree with anything I've said. I'll assume what I've said is fine, and continue working unless I hear otherwise.
SusanBrown
commented
7 years ago Sounds good. Mihaela, pls make a card in the project to decide who will rewrite the CWRC search results if it’s not clear.
On Sep 8, 2017, at 7:02 AM, James Chartrand notifications@github.com<mailto:notifications@github.com> wrote:
I've reread this and I think I now understand what you mean by 'interim' - a popover that shows only information that was available in the initial search call, as opposed to a 'full' popover that shows the full web/html page for the individual result in an iframe.
So if there is to be an interim popover for the CWRC results (and possibly also for results from other entity sources if those sources are also slow) then 'interim' suggests (assuming interim means 'temporary') that there will be a 'full' (or 'final') popover available for those results? If so, how/when will the 'full' popover be shown? Or by 'interim' did you mean just that the popover would contain only pre-fetched information, i.e. only the information that comes back in the search result?
It's worth keeping in mind that for the CWRC entity results, the server side system will be rewritten, and so Jeff (or whoever rewrites it) can put whatever information you want directly into the search results, obviating any need for a subsequent call to show the 'full' record (which is I think why Jeff asked this question to begin with, i.e., what do you want in the search results).
I'll go ahead assuming that each result will show a popover (triggered by a mouseover with a delay of a second or two) that shows either an iframe with the full HTML page for the result if that can be fetched quickly, or if the full web page can't be fetched quickly, then shows whatever information is available in the search results.
I've checked quickly and it does seem that I can put an iframe into a bootstrap popover, but I've yet to fully confirm that. If it turns out not to be true, we'll have to revisit.
I will use Mihaela's entity layout result 2, assuming that you want the results to look consistent across entity sources. I can't show layout 1 for VIAF because there is limited info available in the VIAF initial search results. On the other hand, the CWRC results will already look different from other results since the CWRC results will show the project logo for each result. In any case, we can change what's shown in the CWRC results later (and I don't think the CWRC results will be ready for a few months anyhow?)
No need to answer this unless you disagree with anything I've said. I'll assume what I've said is fine, and continue working unless I hear otherwise.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/cwrc/CWRC-PublicEntityDialogs/issues/4#issuecomment-328074390, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAhUoDepM47LMOW2-yEnHT3NTUKwyvS8ks5sgR7dgaJpZM4PAc-t.
Should allow saving entities by project.
Clearly define the API endpoints, arguments, results, and for authenticating.
NOTE: this is a blocker for the dialogs for finding/creating/editing CWRC entities from the CWRC-Writer.