Attributes don't display well when >15 attributes

[isteves]

The way attributes are currently displayed doesn't work well for data tables with a lot of attributes (>15ish) attributes. For example, https://arcticdata.io/catalog/#view/doi:10.18739/A2MV9S

I don't know what UI fixes would actually work, but the following might help:

• having attributes info move down the page as you click on different attributes
• use a drop-down menu for attributes rather than a listing all of them out
• when >15 attributes, enable an attributes window that can be scrolled through separately from the main window

[amoeba]

Hey @isteves I agree this could use some polish. Would something like this be a good improvement? The sky's the limit.

For any dev that wants to implement that, it's just overflow-y and max-height.

[isteves]

Yep, totally! Though I fear that if the scroll bar is invisible people might not realize that there are more variables to see. Is that also easily tweakable?

[isteves]

@maier-m you also have thoughts?

[amoeba]

@isteves a MacOS default, so the scroll bar will show up for users who've chosen to show scrollbars.

[mpsaloha]

Hi Irene and Bryce,

As someone who has been having to "really use" the ADC to examine datasets for an upcoming synthesis, I find the current attribute display somewhat inconvenient. For example, when provided with a list of cryptic variable names (v. Bryce's cool animated exampled)-- it is hard to know what is in the dataset without laboriously clicking over each attribute, one by one. There is no way to get a synoptic view of the dataset contents.

In the past we had more of a horizontal scroll view, that laid out a multiple row view of the "header" list-- with variable name, label, definition, etc. piled on top of one another, and arranged in order left-to-right. We felt that was too cumbersome however, as the horizontal scroll bar would get infinitesimally small on datasets with large tuples.

So... has there been consideration of a more "periodic table" view--- topLeft to bottomRight, table formatted view of all the variables, where, e.g. one could see at a glance AT LEAST see the variable name AND label, if not definition (Partial...?). Then selecting one of the attributes would show the other details-- type, unit, precision, etc. The dimensions of the table (#rows x #cols) could be scoped to accommodate the width of the browser window. It would give someone a much more informative synoptic view of the dataset contents for quick perusal, and be handy for drill-down inspection, requiring less scrolling than the current vertical arraying of attribute names.

Just a suggestion, and sorry if this has already been considered and rejected by some panel of experts...

cheers, Mark

On Mon, Mar 5, 2018 at 8:37 PM, Bryce Mecum notifications@github.com wrote:

Hey @isteves https://github.com/isteves I agree this could use some polish. Would something like this be a good improvement? The sky's the limit.

[image: kapture 2018-03-05 at 19 35 43] https://user-images.githubusercontent.com/563/37014345-753a5378-20ac-11e8-8b63-029f6b6c41be.gif

For any dev that wants to implement that, it's just overflow-y and max-height.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NCEAS/metacatui/issues/511#issuecomment-370659956, or mute the thread https://github.com/notifications/unsubscribe-auth/AE61-Z3-SBkMcuGhI7O-TI8kSR6XGokRks5tbhJzgaJpZM4Sdwsn .

[amoeba]

I think that's a really great suggestion. If I mock up an idea or two, maybe you could take a look and we could pass them around.

[isteves]

I like the overview idea, but with one small change: rather than the variable name and label, I think it's better to display the variable name and (partial) definition, since those are required fields in EML (versus the label, which is optional and may often be blank). Also probably useful to include units!

[mbjones]

Note that we used to display our attributes as a table. We had it in two formats, one with the each variable in a column, and each metadata property in a row. The other with each variable in a row, and each metadata property in a column. There is support for these layouts in the XSLT for EML, and a parameter to switch between them. We found that 1) laying it out one variable per column doesn't work for the common case where a table has hundreds of variables -- users complained a lot about the super wide format, and 2) laying it out with one variable per row was confusing to people -- people didn't understand the abstraction. We arrived at our current dynamic display after numerous iterations on these themes -- I'm still not satisfied with it, and it could certainly be more compact and expressive. I'm just not sure how these proposals differ from what we've had deployed in the past. Some mockups might help make this more concrete.

[amoeba]

@isteves: good point @mbjones: Thanks for the the background!

[mpsaloha]

Hopefully Matt can weigh in on this before much energy is expended, since it may be a rehash of an idea that was already rejected for reasons lost in the mists of time.

However, if there is merit, I'd be happy to look over any mockups, Bryce. Thanks! I'd also suggest that the attributes be labelled with their numeric ordering, that will make it easy to specify, e.g. that one is only interested in say, attributes[1, 4, 7-10, 22-46] for download (thinking about scripting ease here).

Irene-- agreed that definitions are nice, but these are typically natural language descriptions of the variable contents-- long and meandering without a concise statement of specific variable content "up front". So (often) presenting the first few words of a Definition will give little indication of the specific contents of the attribute. Just look at the ADC's Attribute Definitions vs Labels in the Coopman/Garrett dataset (currently second in a list on global search of ADC) called "output_geoschem.csv" to see what I mean. That is a single example, but I've been examining a lot of datasets lately and feel this is a common pattern. On the other hand, Labels often are concise but human interpretable NL bigrams or trigrams specifically indicative of an attribute's content. As Matt mentioned, often useful for labeling axes on a graph...

Thanks.

cheers, Mark

On Tue, Mar 6, 2018 at 9:27 AM, isteves notifications@github.com wrote:

I like the overview idea, but with one small change: rather than the variable name and label, I think it's better to display the variable name and (partial) definition, since those are required fields in EML (versus the label, which is optional and may often be blank). Also probably useful to include units!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/NCEAS/metacatui/issues/511#issuecomment-370860730, or mute the thread https://github.com/notifications/unsubscribe-auth/AE61-XI9URTNovdAy7jbOdT_QAHx2-pIks5tbscHgaJpZM4Sdwsn .

[csjx]

Yeah, we have gone back and forth on this a lot. Maybe we need both? Default to the stacked view, and provide a View all attributes button that provides the wide-table layout, column-by-column?

[mpsaloha]

Thanks for the recollection, Matt!

I hope it's clear I am suggesting neither the row-major nor column-major models we tried in the past, but riffing on Mendeleyev...depicting more critical metadata at a glance than our current UI, but less comprehensive than our earlier models and still requiring a drill-down for more detailed metadata. Mark

On Tue, Mar 6, 2018 at 9:47 AM, Matt Jones notifications@github.com wrote:

Note that we used to display our attributes as a table. We had it in two formats, one with the each variable in a column, and each metadata property in a row. The other with each variable in a row, and each metadata property in a column. There is support for these layouts in the XSLT for EML, and a parameter to switch between them. We found that 1) laying it out one variable per column doesn't work for the common case where a table has hundreds of variables -- users complained a lot about the super wide format, and 2) laying it out with one variable per row was confusing to people -- people didn't understand the abstraction. We arrived at our current dynamic display after numerous iterations on these themes -- I'm still not satisfied with it, and it could certainly be more compact and expressive. I'm just not sure how these proposals differ from what we've had deployed in the past. Some mockups might help make this more concrete.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/NCEAS/metacatui/issues/511#issuecomment-370867134, or mute the thread https://github.com/notifications/unsubscribe-auth/AE61-bVWb1DaR9KB1Hbtt5EzxLK252zhks5tbsuYgaJpZM4Sdwsn .

[isteves]

Mark- agreed that labels (when available) are much easier to use than definitions. Perhaps when no labels are provided, labels can be auto-populated with the definition.

In reviewing some attributeDescriptions (which I believe is equivalent to attributeDefinitions), it looks like many of them are pretty understandable from the first few words (granted, most are dates, since I think solr may only grab the first attribute's info for each metadata record):

#grab info about doi's that have attributeDescriptions
result <- query(mn, list(q = 'id:doi*+AND+attributeDescription:*',
                         fl = 'fileName,dateUploaded,id,attributeLabel,attributeDescription',
                         sort = 'dateUploaded+desc',
                         rows='10000'),
                as = "data.frame")

nrow(result) #1241 total
sum(!is.na(result$attributeLabel)) #79 with labels

At least for the first attribute of many packages, it looks like majority do not use labels.

[amoeba]

Hey all, @mpsaloha I mocked up a hybrid display that I think the basis for two modalities of use:

• A user wants to quickly scan the attributes present in the EML
• A user wants full details about every attribute

Here's a super simple demo, with minimal information that shows splitting the current display into two components:

1. A table at the top of the attributes section that shows some of the attribute information. What would go here would be what we'd decide is most useful for quick scanning
2. Clicking on entries in the table shows the full detail for the attribute metadata

I annotated a still from the above GIF to be clear about some of these points:

Interactive example here:

https://codepen.io/petridish/pen/YemqmM

[mpsaloha]

Hi Bryce,

Your mockup is an improvement, as it is a bit more revealing about the meaning of each of the attributes without having to go down the list and select each one to evaluate it. However, it still leaves the "vertical scrolling" challenge.

I was suggesting something more along the lines of this:

https://www.ptable.com/ https://www.ptable.com/

One can see (roughly) how concisely one can convey lots of information in limited screen-space, e.g. looking at the 6x5 table that starts with Boron-Neon, and ends Thallium-Radon. Each block would need a little enlarging to accommodate full attribute names, plus either label and/or truncated definitions, but I don't think unwieldy (will need testing).

Mouse click-on gives additional information, and (looking to the future with semantic lookups)-- a fuller and "standardized" description of that measurement might ultimately be found at the end of an http URI such as this one:

http://purl.obolibrary.org/obo/ENVO_01000770 from ENVO. Also note that I think providing consecutive numbering of attributes (atomic weights here) could be useful for scripting PROJECT-like "list" statements for subsetting after download (or in wilder dreams, subsetting prior to download!), especially if attributes are numerous and, as is often the case, are somewhat thematically clumped within the tuple. Thanks! Mark On Tue, Mar 6, 2018 at 12:39 PM, Bryce Mecum wrote: > Hey all, @mpsaloha I mocked up a hybrid > display that I think the basis for two modalities of use: > > - A user wants to quickly scan the attributes present in the EML > - A user wants full details about every attribute > > Here's a super simple demo, with minimal information that shows splitting > the current display into two components: > > 1. A table at the top of the attributes section that shows *some* of > the attribute information. What would go here would be what we'd decide is > most useful for quick scanning > 2. Clicking on entries in the table shows the full detail for the > attribute metadata > > [image: kapture 2018-03-06 at 11 32 37] > > > I annotated a still from the above GIF to be clear about some of these > points: > > [image: screen shot 2018-03-06 at 11 33 32 am] > > > Interactive example here: > > https://codepen.io/petridish/pen/YemqmM > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , > or mute the thread > > . >

[amoeba]

In the periodic table approach, how/where does the user find all the info about each attribute?

[mpsaloha]

Bryce-- not sure if this is what you are asking, but by "clicking" on the desired cell. The analogy here would be clicking on the cell for "Carbon", and seeing details about what that cell is about.

In our case, doing this would then display all the available metadata about that attribute. And (hopefully) increasingly refer in the future to a well-described "measurement type" from some ontology accessed via a derefenceable HTTP URI, like the one I included as an example for "carbon emissions process" from ENVO. But that was an example, and not a well-constructed measurement type.

We would still need local, specific attribute information as well, e.g. about units and precision and method etc. that were used for that measurement, and might vary from dataset to dataset. This is because I don't think ontologies will ever have instances or classes that cover each and every potential set of units that might be used in the actual measurement of some phenomena-- although it is possible if the disciplines start requiring some greater standardization in these regards.

Thanks.

cheers, Mark

On Tue, Mar 6, 2018 at 4:09 PM, Bryce Mecum notifications@github.com wrote:

In the periodic table approach, how/where does the user find all the info about each attribute?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NCEAS/metacatui/issues/511#issuecomment-370975097, or mute the thread https://github.com/notifications/unsubscribe-auth/AE61-VOK4gXy2qlBEQgdrQP4D_DmgpUvks5tbyUlgaJpZM4Sdwsn .

[amoeba]

That makes some sense. Do you think more of a tooltip, modal dialog, or something like this? https://codepen.io/petridish/pen/NyQgzv

[mpsaloha]

Yow, Bryce! You're showing 100 attributes in a limited space and this is nice!!! I LIKE. (but I also like uni, so...)

Interesting to see how this might look with some actual variable labels (e.g. often bigrams or trigrams) under the variable name (typically shorter unigrams). Also, a numeric identifier (1...N) on each (upper left corner) would be useful to know how these elements are ordered in EML, and hence index reference-able in an (R, py) array of attribute names.

Then, whether to use a tooltip or modal dialog is a tougher call (for me at least). I think the typical use case would be: rapid mouse-over to quickly get a "tooltip" like expansion of cell contents, e.g. A) showing attribute name/label/definition/units/etc; and B) could also include information gleaned from an ontology URI reference (semantic annotation), such values for "alternate labels" or "near synonyms". But would be useful, even if just stopping at "A", for now.

Then, we can anticipate ultimately needing an option to click into the semantic annotation URI, if wanted to learn more about how that term is related to/linked with other items-- basically expanding from "B" above (that is specific to the term), out to the full Knowledge graph that houses the term. This latter capability is more aspirational staging at this point, but you saw a bit of how it works if you dereferenced the ENVO PURL I sent earlier.

Whether the above features are more suited to tooltip or modal dialog is not clear to me, as I don't know the details about how these behave differently relative to cursor movement and select/dismiss. I'd hope for clarification from you, Lauren, others about this...?

thanks, Mark

On Tue, Mar 6, 2018 at 4:59 PM, Bryce Mecum notifications@github.com wrote:

That makes some sense. Do you think more of a tooltip, modal dialog, or something like this? https://codepen.io/petridish/pen/NyQgzv

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NCEAS/metacatui/issues/511#issuecomment-370984844, or mute the thread https://github.com/notifications/unsubscribe-auth/AE61-Srg5uEb2ZVdrFEtGES0WjGA7MVMks5tbzD-gaJpZM4Sdwsn .

[mpsaloha]

Hi again,

I might add that Julien and I were just looking at the table view of attributes, and noted that the bottom-half of my browser readily accommodated a view 14 cells wide and 6 cells deep, for 84 cells total in view! But to cram more information (label, partial definition, etc.) into each cell will require larger cell size (although Julien could clearly read all the 84 cell labels from >2 meters away from my 24" widescreen monitor). So even if you increase cell size by 4 (aggregating the current 2x2 into single cells, giving lots of room for text)-- you'd still have 84/4=21 detailed cell views on approx a half-screen. Julien agreed it provides a nice synoptic view of a table's contents.

cheers, Mark

On Tue, Mar 6, 2018 at 6:05 PM, Mark P. Schildhauer < mark.schildhauer@gmail.com> wrote:

Yow, Bryce! You're showing 100 attributes in a limited space and this is nice!!! I LIKE. (but I also like uni, so...)

Interesting to see how this might look with some actual variable labels (e.g. often bigrams or trigrams) under the variable name (typically shorter unigrams). Also, a numeric identifier (1...N) on each (upper left corner) would be useful to know how these elements are ordered in EML, and hence index reference-able in an (R, py) array of attribute names.

Then, whether to use a tooltip or modal dialog is a tougher call (for me at least). I think the typical use case would be: rapid mouse-over to quickly get a "tooltip" like expansion of cell contents, e.g. A) showing attribute name/label/definition/units/etc; and B) could also include information gleaned from an ontology URI reference (semantic annotation), such values for "alternate labels" or "near synonyms". But would be useful, even if just stopping at "A", for now.

Then, we can anticipate ultimately needing an option to click into the semantic annotation URI, if wanted to learn more about how that term is related to/linked with other items-- basically expanding from "B" above (that is specific to the term), out to the full Knowledge graph that houses the term. This latter capability is more aspirational staging at this point, but you saw a bit of how it works if you dereferenced the ENVO PURL I sent earlier.

Whether the above features are more suited to tooltip or modal dialog is not clear to me, as I don't know the details about how these behave differently relative to cursor movement and select/dismiss. I'd hope for clarification from you, Lauren, others about this...?

thanks, Mark

On Tue, Mar 6, 2018 at 4:59 PM, Bryce Mecum notifications@github.com wrote:

That makes some sense. Do you think more of a tooltip, modal dialog, or something like this? https://codepen.io/petridish/pen/NyQgzv

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NCEAS/metacatui/issues/511#issuecomment-370984844, or mute the thread https://github.com/notifications/unsubscribe-auth/AE61-Srg5uEb2ZVdrFEtGES0WjGA7MVMks5tbzD-gaJpZM4Sdwsn .

[maier-m]

I think a wide format with attributes as rows and metadata as columns seems the most straight forward solution. PIs often submit metadata to the data team in some sort of csv/pdf/docx with the following similar format:

Attribute_1 = "Attribute_1 info"
Attribute_2 = "Attribute_2 info"
Attribute_3 = "Attribute_3 info"
...

However, I do understand that because the fields vary quite a bit depending on the measurementScale, that it is confusing to have all attributes displayed in one manner. Perhaps this was one of the reasons to move from such a display?

If so, the first mock-up by @amoeba (https://codepen.io/petridish/pen/YemqmM) seems to be a great hybrid display giving an easy to understand interface that can offer a customized display based on the attribute type. As for the periodic-table approach, this may be a silly concern, but I wonder if arranging attributes in a matrix will cause some confusion. Generally when information is arranged in a matrix, moving left-right across the matrix means something different than moving up-down across the matrix. Furthermore, it may be difficult to search through all the attributes in a matrix form. One could add a simple search bar at the top of first mock-up by @amoeba to help users search through long attribute lists easily, this would be more complicated in a matrix approach.

However, there is still the problem that the user has to click through each and every attribute. Having to click through each attribute makes it very difficult for a PI not very savvy with EML to quality check his/her attributes with any sort of efficiency. Displaying the attributes in a table format (attributes as rows) has the advantage of all the metadata in one view so that users can quickly scan all the data (or with search/filter bars relevant data). Also, I think everyone is very familiar with tabular data displays (Excel, MATLAB, RStudio, ESRI, etc.). Additionally, if there is ever going to be a possibility that users could send attribute information to a node in a tabular (.csv) format (which might speed up the creation of attribute lists for users), it seems that having a uniform display on the UI may be beneficial for multiple reasons.

[mpsaloha]

Hi MItchell,

Thanks for your thoughts. Nicely articulated.

As Matt mentioned, we had mocked up this type of "row-major" attribute metadata display in the past. The concerns we had with this view included the need for both "longish" vertical AND horizontal scrolling to examine items. E.g. if there are 100 attributes in a dataset, you've got 100 rows to vertically scroll through to see all potential attributes. Second, many attributes can have detailed "definitions" that may go on for several sentences or more. This, along with columns for Units, Precision, etc. makes for a potentially very "wide" row-oriented display (horizontal scroll), or, if those long definitions are word-wrapped, an even longer vertical expansion ("vertical" scroll).

Regarding potential confusion in interpreting a "matrix" view (which I'd prefer to call a table or grid view, since matrices have special connotations that are not appropriate here)-- I don't think researchers would get confused by this, although it is a legitimate worry. It is why, however, I've suggested posting a "column number" associated with each element in the corner of each Grid cell. Expanding grid-cell size as I've suggested is then, something of a compromise between the horizontal vs vertical arraying of the attribute metadata. I pointed out how this enabled viewing a large number of attributes all out once, with potentially fairly rich descriptive metadata displaying, without the need to scroll nor "expand". I think we know how annoying it is when you have to scroll pertinent information off the screen to get to the stuff way at the bottom or the top. A mouse-over popup could, in my opinion, afford a very quick way to review full metadata contents of a number of attributes without having to scroll.

Your concern about: "Additionally, if there is ever going to be a possibility that users could send attribute information to a node in a tabular (.csv) format (which might speed up the creation of attribute lists for users), it seems that having a uniform display on the UI may be beneficial for multiple reasons."-- I don't see why a uniform UI display facilitates this, as opposed to some well-structured readily-usable download formats of attribute metadata information from the repository. This is something that Dom has been working on...although we've been approaching it from external scripts translating the XML (e.g using R, but other languages obviously also possible). Maybe I am missing some nuanced aspects of your concerns here...

But I agree it would be good to do some mock-ups. My feedback is based on some recent frustrations actually trying to assess data suitability for an upcoming working group, as well as for a semantic annotation task that is underway.

thanks for the feedback.

cheers, Mark

On Tue, Mar 6, 2018 at 6:59 PM, Mitchell Maier notifications@github.com wrote:

I think a wide format with attributes as rows and metadata as columns seems the most straight forward solution. PIs often submit metadata to the data team in some sort of csv/pdf/docx with the following similar format:

Attribute_1 = "Attribute_1 info" Attribute_2 = "Attribute_2 info" Attribute_3 = "Attribute_3 info" ...

However, I do understand that because the fields vary quite a bit depending on the measurementScale, that it is confusing to have all attributes displayed in one manner. Perhaps this was one of the reasons to move from such a display?

If so, the first mock-up by @amoeba https://github.com/amoeba ( https://codepen.io/petridish/pen/YemqmM) seems to be a great hybrid display giving an easy to understand interface that can offer a customized display based on the attribute type. As for the periodic-table approach, this may be a silly concern, but I wonder if arranging attributes in a matrix will cause some confusion. Generally when information is arranged in a matrix, moving left-right across the matrix means something different than moving up-down across the matrix. Furthermore, it may be difficult to search through all the attributes in a matrix form. One could add a simple search bar at the top of first mock-up by @amoeba https://github.com/amoeba to help users search through long attribute lists easily, this would be more complicated in a matrix approach.

However, there is still the problem that the user has to click through each and every attribute. Having to click through each attribute makes it very difficult for a PI not very savvy with EML to quality check his/her attributes with any sort of efficiency. Displaying the attributes in a table format (attributes as rows) has the advantage of all the metadata in one view so that users can quickly scan all the data (or with search/filter bars relevant data). Also, I think everyone is very familiar with tabular data displays (Excel, MATLAB, RStudio, ESRI, etc.). Additionally, if there is ever going to be a possibility that users could send attribute information to a node in a tabular (.csv) format (which might speed up the creation of attribute lists for users), it seems that having a uniform display on the UI may be beneficial for multiple reasons.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NCEAS/metacatui/issues/511#issuecomment-371006176, or mute the thread https://github.com/notifications/unsubscribe-auth/AE61-dVJh70MvxsI0qyOPS7y--M2ZMNNks5tb00dgaJpZM4Sdwsn .

[maier-m]

Hello Mark,

Thanks for the reply.

I completely agree that if you have an option to retrieve/download the attributes in a tabular form within the UI (e.g. the R command EML::get_attributes() does this in RStudio) then a more unique and tailored display UI would be very appropriate. It doesn't need to be the only or main option to view the attributes, but being able to quickly see the attributes in a tabular form seems like it would be very beneficial.

[amoeba]

Lots of great ideas here. Thanks both of you. I tweaked the periodic table mockup to make the cells twice as large: https://codepen.io/petridish/pen/QmLKGr but really it sounds like a more advanced mockup may be needed to prove this approach (one with real metadata, with more features).

What might be a good way forward here? More major types of mockups? More detailed/real mockups?

[laurenwalker]

I think we could definitely improve the way we display attributes and I like seeing the discussion on this.

Things we need to keep in mind - We don't want to divorce the Metadata View / dataset landing page attribute appearance from the Metadata Editor. Whatever new design we come up with should also make sense in an editor display, as well. I'm not sure how we could fit editor tools into the above table design. That would need some brainstorming.

We also have been wanting to change a lot of the dataset landing page displays, but have been putting that work on the backburner in order to get the new editor out. I don't want to put all this brainstorming to a halt, but I would like to hold off any major changes to the dataset landing pages until we can discuss that page as a whole. Partly because I want to be involved in the discussions but can't devote the time to it now due to the editor release, and partly because I think we need to zoom back a bit and decide on an overall plan for our metadata display.

For instance, we have talked about making the dataset landing page an in-place editor, where users can click "Edit" anywhere on the dataset landing page and instantly change the metadata without being directed to another page. So it would be most helpful in the long run to discuss all these ideas at the same time.

Anyway, keep the brainstorming train rolling, but I would suggest we not decide on anything until we can have a longer and broader discussion....

Lauren

On Wed, Mar 7, 2018 at 1:46 PM, Bryce Mecum notifications@github.com wrote:

Lots of great ideas here. Thanks both of you. I tweaked the periodic table mockup to make the cells twice as large: https://codepen.io/petridish/ pen/QmLKGr but really it sounds like a more advanced mockup may be needed to prove this approach (one with real metadata, with more features).

What might be a good way forward here? More major types of mockups? More detailed/real mockups?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NCEAS/metacatui/issues/511#issuecomment-371242068, or mute the thread https://github.com/notifications/unsubscribe-auth/AGVeFvjDjMyEQb0MyrUI_H4qxdA8ZMapks5tcCsTgaJpZM4Sdwsn .

-- National Center for Ecological Analysis and Synthesis (NCEAS) University of California Santa Barbara (UCSB)

[amoeba]

We don't want to divorce the Metadata View / dataset landing page attribute appearance from the Metadata Editor.

Great point.

And I take your other points happily as well. What do you think about making a small change now (say, adding max-height and overflow-y) to marginally improve display and ux and coming back to this deeper discussion at a later date?

[laurenwalker]

Absolutely, I think small changes like that are great.

On Wed, Mar 7, 2018 at 2:16 PM, Bryce Mecum notifications@github.com wrote:

We don't want to divorce the Metadata View / dataset landing page attribute appearance from the Metadata Editor.

Great point.

And I take your other points happily as well. What do you think about making a small change now (say, adding max-height and overflow-y) to marginally improve display and ux and coming back to this deeper discussion at a later date?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/NCEAS/metacatui/issues/511#issuecomment-371251915, or mute the thread https://github.com/notifications/unsubscribe-auth/AGVeFkrXLt3p9kFeDGzCdZSGw2EKtizjks5tcDIegaJpZM4Sdwsn .

-- National Center for Ecological Analysis and Synthesis (NCEAS) University of California Santa Barbara (UCSB)

[laurenwalker]

This was fixed with Bryce's (@amoeba) recent commit for #866.