Hello Siddhesh
To summarize my view on the various points in our email exchange, I'm
not sure that current direction is achieving our goal of providing
simplified views of metadata to users. The approach taken so far was to
insert the specialized widgets directly in the tree. It was nice to
experiment, but we can now see the resulting heterogeneity (variations
in the fields layout) in the "value" column. Another complication is
that we do not have a lot of room for putting labels telling to users
what the fields mean. Continuing this approach leads us to questionable
actions, like tables in tree-table - you rightly point out that this is
not a recommended practice. Recent developments allow the users to hide
columns or rows, or change row order, but it does not make the metadata
fundamentally easier for users.
My original idea was to create simplified views completely separated
from the tree table, as proposed in my email one month ago [1]. That
email contained a link to a screenshot of a competing software
(Geonetwork) for inspiration. I proposed a few fields we could select
for starting with something simpler. Some elements of the summary form
would regroup many tree nodes (for example showing all
AxisDimensionProperties in a table). If we implement such forms, some
specialized widgets developed for the tree table could move to that
form. I realize that designing a "metadata summary" form requires some
familiarity with the semantic of ISO 19115 metadata, but we would be
glad to help if we can have a prototype or a drawing somewhere.
In the part of my previous email talking about "straightforward tree",
indeed I mean the tree shown by ValueExistencePolicy.COMPACT (or
ValueExistencePolicy.ALL in edition mode). But we could have links
between the tree view and the summary form. Some nodes could have a
"summary" link which bring the focus to the corresponding element of the
summary form, and conversely some elements of the form could have a
"details" link that bring the focus to the corresponding node of the
tree table.
The other widgets (the map pane, the extent pane, the list of CRS) are
interesting starts, but some changes are needed (e.g. there is no linear
relationship between a latitude slider and a Mercator projection - maybe
you wanted to use a Plate-Carré projection?) and we may not have the
time to connect those widgets to actual actions (e.g. open a CRS editor
when a CRS is selected). Should we focus on the metadata form only?
Martin
[1]
https://lists.apache.org/thread.html/97f8b80284797a7347655c3bac870abf5c1d48c21d5aed3494d981f7@%3Cdev.sis.apache.org%3E
Le 25/07/2017 à 16:56, Siddhesh Rane a écrit :
>> * In the tree view of current application, what is the meaning of the
>> eyes and arrows on the right side of each property name?
> The tree view will have an "profile edit" mode in which all possible metadata
> identifiers will be shown, the user can then click on the the "eye" to
> show/hide it by default in the read mode , and then user can drag the entire
> node to rearrange it for sorting. Once the user is finished he can capture
> this state and save it under a new profile. The eye and arrows won't be shown
> until the user hovers the mouse over the row. Css is yet to be added to it.
>
>> * The Extent pane does not seem to be currently connected to something
>> else, but I suppose that you have a plan for it. What would be the plan?
> The NSEW widget for geographic extent has a button in the center which upon
> clicking will open this bigger extent pane. Since we are planning to use this
> widget for searching in CRS and there its more convenient to draw the extent.
>
>> * I presume you noticed that the range sliders in the Extent pane are
>> not currently aligned with the bounding box. Is it something that
>> you plan to fix? (I realize that it may require that you write your
>> own range slider).
> You can scroll the map, but if you CTRL+scroll then the map will zoom. So you
> ctrl+scroll down to zoom out the map to the same width as the scroll pane. In
> this case the bounding box will align with the sliders. It's intentional. The
> sliders are not necessarily supposed to align though.
>
>> * Where the background map come from? I would be curious to know what
>> are the meaning of circles and the lines connecting them in the ocean.
> I searched for mercator projection of the earth and came across this image
> from Wikimedia commons. I wanted to consult with you about the accuracy of
> this map, which I presume is accurate. If you can point me to a more accurate
> image I'll use that.
>
>> * In the metadata tree view, the identifier and type columns may be
>> convenient for development, but shouldn't they be hidden by default
>> for the users?
> There is a plus shaped button at the top right corner which allows you to
> selectively hide unwanted columns.
> Right now JavaFX TreeTableView doesn't provide a programmatic way of keeping
> certain columns hidden by default, yet visible in the menu for a user to show
> extra columns.
> So what I'll do is place toggle buttons at the top to enable/disable these
> columns. These columns will be by default not added to the tree table. In the
> release version we are simply going to remove them, but keeping them hidden
> by default right now is going to make it more inconvenient for me during
> development.
>
>> The specialized widgets are compact, but I'm unsure about whether
>> inserting them in the tree is always helpful. Would it be possible to
>> allow switching between the 2 modes? (straightforward tree, or tree with
>> some specialized widgets)?
> By straightforward tree do you mean the one we get with
> ValueExistencePolicy.COMPACT or do you want to selectively disable certain
> widgets? Can you please elaborate this more?
>
> Another thing that may help is that some
>> specialized widgets could be made more high-level:
>>
>> * In Metadata/SpatialRepresentationInfo/AxisDimensionProperties,
>> instead of a (size, name) pair for each AxisDimensionProperties
>> node, we could do a single table for all properties under a single
>> AxisDimensionProperties node. The name column could be first, then
>> the size and the resolution. The column headers would also help user
>> to know what the properties are (currently we have to guess). I
>> realize that the result is a table inside a tree-table and I'm not
>> sure it is a great idea; an alternative could be to put such table
>> in a completely separated "summary" widget, as I proposed in earlier
>> emails.
>> * A similar approach could be done for descriptive keywords (one table
>> row for each keyword type).
> Well a table inside a table cell is generally not recommended practice, but
> I'll think of something. Too soon to tell.
>
>> In metadata identifiers (or any other identifier), the specialized
>> widget have 4 fields, but it is difficult to guess their meaning. Would
>> it be possible to put label, or tooltip?
> Yes I'll add labels and tooltips. Currently there is prompt text which shows
> when the field is empty
>
> Regards
> Siddhesh Rane
