Landing Page

[figueroadjuan]

In Reference to:
#https://github.com/earthchem/sesar/issues/73

Description
Create a stand-alone Single Page Application (SPA) that pulls from the current SESAR: sample dev API.

Current samples pages on SESAR:
Example without image
Example with image

Project Notes
Notes

Examples:

• DataOne
• 
Example landing page created by student
• GFZ landing page
• Geoscience Australia

[ramdeensarah]

During the meeting we highlight 4 areas of the landing page

• has image
• has parent/child samples
• has links/documents
• has a location

Here is an example sample with everything except the image https://test-sesar.geosamples.org/sample/igsn/ODP0111O1
ODP cores have lots of details.

I can create a series of related examples if needed.

[figueroadjuan]

#earthchem/sesar#73

@earthchem/sesar-team, please provide feedback on mock-up version 1.0:
Landing Page Mock-Up V.1.0

[figueroadjuan]

Questions for next version:

• Should map and hierarchy of sample/parent be visible right away?
• Do the icons determine what the sample has?
• Does the IGSN QR code belong to the "images" category or are images separate?

Thanks!

[ramdeensarah]

Replies to questions

• Should map and hierarchy of sample/parent be visible right away?

Yes. We liked the version created by GFZ which has a side bar with the map, and the sample hierarchy. The map should be top/first though (unlike GFZ). See this discussion in the notes

• Do the icons determine what the sample has?

The icons are present if specific metadata is present in the record. They may not be necessary on the landing page (see comment linked above on too much information on the page). If they are used, the image icon and the map icon are not necessary as the images and the map will be displayed. The others are listed below (more information in this issue)

• Geolocation icon: lat/lon
• Classification: classification_id
• Collection Method icon: collection_method
• Age icon: for geological_age
• Locality: locality and primary_location_name
• Photo icon: primary_image

• Does the IGSN QR code belong to the "images" category or are images separate?

I would say separate from images. EVERY sample will have a QR code assigned to it (automatically added by SESAR), not every sample will have an image (added by users)

[klehnert55]

I had placed comments in the GUI Google doc that are relevant here. Please check.

[klehnert55]

Just to explain the icons: My intention had been to have these icons displayed in a list of samples (search result) so that users can easily see an overview of metadata availability. I don't think that the icons are very helpful on the landing page.

[figueroadjuan]

V2.0:

Should I remove icons now as per both responses?

Just to explain the icons: My intention had been to have these icons displayed in a list of samples (search result) so that users can easily see an overview of metadata availability. I don't think that the icons are very helpful on the landing page.
Replies to questions

• Should map and hierarchy of sample/parent be visible right away?

Yes. We liked the version created by GFZ which has a side bar with the map, and the sample hierarchy. The map should be top/first though (unlike GFZ). See this discussion in the notes

• Do the icons determine what the sample has?

The icons are present if specific metadata is present in the record. They may not be necessary on the landing page (see comment linked above on too much information on the page). If they are used, the image icon and the map icon are not necessary as the images and the map will be displayed. The others are listed below (more information in this issue)

• Geolocation icon: lat/lon
• Classification: classification_id
• Collection Method icon: collection_method
• Age icon: for geological_age
• Locality: locality and primary_location_name
• Photo icon: primary_image

• Does the IGSN QR code belong to the "images" category or are images separate?

I would say separate from images. EVERY sample will have a QR code assigned to it (automatically added by SESAR), not every sample will have an image (added by users)

[ramdeensarah]

Yes, please do remove them.

I am not sure about listing the IGSN in the banner. People might not see it/realize it is part of the metadata for the sample? Also that example looks like it is incomplete (it should have a user code typically beginning with IE).

I like having the search bar at the top right. Is it a dropdown? What other searches would it support besides IGSN? (I think we want the straight IGSN search similar to what is currently supported on the geosamples.org site, but would love to hear what else you envisioned).

[klehnert55]

I actually like the IGSN in the banner, but it needs to say IGSN: IEDRA0089 (name space plus name string).
I don't think we should show the 'parent IGSN', that would be part of the sample hierarchy display. All IGSNs in the hierarchy will need to link to the landing pages.

[klehnert55]

I don't see the 'object type' that should be really visible

[klehnert55]

Question to Sarah: Should we display the sample owner on the landing pages? Should we ask users if it is okay to display their name?

[figueroadjuan]

[Note: not replying to specific messages to avoid longer thread]

Yes, the search on top would reload the page by fetching a new sample by ID from the API. There is a dropdown to the left of this search, which will have all the "names available", but it would not predetermine if the name space + name string exists unless this is available in the API.

Ok, here is the next version:

• Left the IGSN banner with the name space plus name string;
• Removed parent IGSN from top;
• Added object type (prominent);

[ramdeensarah]

Initial observations

1. I do not think the placement of the IGSN in the center above the QR code makes it clear it is the title/name of the entity on the page.
2. Object type is not easily found on the page. It is one of the most important pieces of information when evaluating a record. Suggest moving to the right where the icons are located, and making it more prominent (i.e. large heading level text).
3. Did we make a final decision on how the indicators would be used/function? They are prominently placed, I assume will be grayed out if content is not present. Would they be clickable items? Would they open the accordion for the appropriate section where the information it represents is contain?
4. The features in the banner (completeness icons, QR code, annotation, wish list, etc.) seem more prominent than the actual sample information. Reconsider the scale.
5. Will any accordion sections be open by default? (i.e Description)
6. How will associated files (images, docx, etc.) be displayed? (I see the 'No Image text; not all associated files are images). In our current system, users can select a primary image/thumbnail, where would that go? (would that be placed here it says 'no images'.
7. How will we handle information not provided by users? Currently, the system will display 'Not Provided', would it be better to only display fields which have been completed? If we do, we need to consider if there are fields that should always be displayed regardless.
8. Could the text boxes for data be larger? The collection method description currently is cramped, and includes a 'read more' link. What does that look like when opened?
9. Per email on Friday, Kerstin suggested considering the layout of HydroShare, e.g. https://www.hydroshare.org/resource/cd0bc6f5a2e54247927128a85bc10c8a/ I do like how the page on HydroShare is divided up, yet I like having the map be spread out in the background on the mockup.
10. What I do not like are the accordions when closed. How dynamic do we expect the page to be? Do we want users to have to click every section to open for additional information instead of being able to scan the page? Our information is not rich, if restructured, may work better.

[klehnert55]

Great observations, thanks, Sarah. And great design, JD!
My feedback:

• I disagree with Sarah about Landing Page #1, I think that the placement of IGSN above the QR code is fine and prominent.
• I agree that Object type should be more visible. But if the object type is so relevant, we should review our vocabulary. My feeling is that our list of object types needs some clean-up.
• Regarding indicators: I agree that they do not need this prominent location. Indeed, I never envisioned them to be on the page, my idea had been that these icons should show up in a list of samples so provide an easy overview of metadata completeness. Once a user is on the landing page, s/he can easily see what's available. I now see the benefit of having them, when the actually metadata are only visible after extending the accordion. Do I understand it correctly that the explanations do show up when hovering over the icon? I would place a small heading above the icons yo make it clear what they are for ("Metadata Availability" or "Metadata Indictors")
• #4: I agree with Sarah.
• #5: I would not have any accordion open by default, but maybe we should at least move 'material' up to the banner under object type.
• #6: I would separate images and other attached documents (this may have some implications for the image and doc upload process). There could be a narrow banner under the big banner that shows thumbnails of images (similar to the USPRR display, but maybe even smaller). Maybe documents can be listed in the accordion "Relevant Links" which we could name "More resources" or "More information". I hope that in the future we can display a list of data links to external systems that would be dynamically generated by harvesting external systems. That has been a plan since 2007! Maybe iSamples will provide the hub for relating IGSN with data DOI and publication DOI.
• #7: We had made the decision long ago (Before your arrival, Sarah) that we would display all metadata fields and show 'not provided' to make users aware of the rich metadata we can accommodate, and that it is not SESAR's fault that these metadata are not provided.
• #8: agree
• #9: I like the map background as well. I just don't see what happens if the sample location is behind any of the accordion boxes.
• #10: I thought that the purpose of the boxes was not to have a long list of metadata fields, but a much cleaner page. I think that JD did that. But maybe the approach that HydroShare took is something to consider: Display the 'core IGSN metadata' in one block with the map as background (again there would be the problem of the block possibly covering the sample location), and to have the accordions that give access to more detailed information below the map.

[figueroadjuan]

Before addressing these concerns into our existing mock-up, should I instead do a different mock-up that integrates the hydroShare view along with the points that have been discussed in this thread?

[klehnert55]

Yes, that's a good idea

[figueroadjuan]

Added a new version to adobe cloud space, please feel free to make comments on it here: https://documentcloud.adobe.com/link/review?uri=urn:aaid:scds:US:a10770fa-8c92-421c-9837-0589cc7bce18

[ramdeensarah]

Checking in on this task. I reviewed the example last week and had no comments. I felt I would want to see some of these points in action before I could properly evaluate the features. Thinking about it this week -- @figueroadjuan were there particular elements that you want input on before you took any action? What do you need in order to take next steps? Are there any features that might be labor intensive to create, and therefore need additional review before implementing? etc.

[figueroadjuan]

Checking in on this task. I reviewed the example last week and had no comments. I felt I would want to see some of these points in action before I could properly evaluate the features. Thinking about it this week -- @figueroadjuan were there particular elements that you want input on before you took any action? What do you need in order to take next steps? Are there any features that might be labor intensive to create, and therefore need additional review before implementing? etc.

Great! If you both feel like this is a good starting point then I can go ahead and get started. The labor intensive piece will be the mapping feature(s) (if we choose to add them). We can move away from this issue and create a GitHub "project" for issues after the first version is released. Should I move forward with development then and we can continue to edit the app iteratively?

[klehnert55]

One issue about the mapping feature is that we need the GMRT base layer to show seafloor bathymetry on the map, which matters for all our marine samples.

On 8/25/20 11:27, Juan David Figueroa wrote: Checking in on this task. I reviewed the example last week and had no comments. I felt I would want to see some of these points in action before I could properly evaluate the features. Thinking about it this week -- @figueroadjuan <https://github.com/figueroadjuan> were there particular elements that you want input on before you took any action? What do you need in order to take next steps? Are there any features that might be labor intensive to create, and therefore need additional review before implementing? etc. Great! If you both feel like this is a good starting point then I can go ahead and get started. The labor intensive piece will be the mapping feature(s) (if we choose to add them). We can move away from this issue and create a GitHub "project" for issues after the first version is released. Should I move forward with development then and we can continue to edit the app iteratively? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXUWCWXTLAXG7C4WQACPILSCPJ6ZANCNFSM4PEZQBUQ>.

-- Dr. Kerstin A. Lehnert Doherty Senior Research Scientist Director, Geoinformatics Research Group Director, Interdisciplinary Earth Data Alliance Lamont-Doherty Earth Observatory of Columbia University 61 Route 9W, Palisades, NY, 10964, USA +1 (845) 365-8506

[ramdeensarah]

Checking in -- @klehnert55 do you have an opinion on if @figueroadjuan should move forward with development? I would recommend working on sesardev or test-sesar of course.

Additional question/comment
In regards to the question about 'Not Provide' metadata (see quote below). Is it possible to add a toggle to the page where all metadata fields are shown if toggled on, but they can toggle it off to only show those fields which are completed by the user? (or other way around as to how the toggle works).

#7: We had made the decision long ago (Before your arrival, Sarah) that we would display all metadata fields and show 'not provided' to make users aware of the rich metadata we can accommodate, and that it is not SESAR's fault that these metadata are not provided.

[klehnert55]

I would not go with the toggle. I think we will have to figure out a different way to display metadata in the future when SESAR will need to accommodate different metadata profiles for different sample types. We will likely display 'IGSN Core Metadata' and 'Community specific metadata'.
For now, JD can move forward with the development. Did you all see my comment about the GMRT base map?

[ramdeensarah]

I did, not sure if @figueroadjuan did, and if he has any suggestions/concerns about implementing the GMRT base map.

That is a good point (about different metadata profiles in the future). Definitely something we need to consider and perhaps discuss with the user community.

[klehnert55]

I guess there will need to be 'community approved' profiles that iSamples manages and we will label the community specific metadata profile with the ID of the profile.