Hello Siddhesh Le 28/07/2017 à 09:22, Siddhesh Rane a écrit :
> Are you pointing out to the non uniform widths of various spinners and > combo boxes? These can be fixed by setting their maximum width to max > value so they'll fill the entire width of the column. > I was thinking more about the diversity of layouts. One row may have 2 fields for a minimum and maximum values, another row 4 fields, etc. In tables, data in the same column are usually represented in an uniform way. This is not completely true for metadata so we are taking some liberties with specialized widgets, but I think that we should not go too far. I suggest to use in the tree-table only widgets representable on a single line, and move larger widgets outside the tree-table (more on it later). > Actually we do. I have put labels in the latest update. We can have as > much vertical space as we want. Earlier I was just using prompt text > but now we have both. > Yes, those labels help a lot. Thanks. > I'm not fully clear about what constitutes a simplified view. My view > was that a simplified view will group together certain nodes that are > related like min max, bounds, date and date type etc and show hide > empty nodes and certain user specified nodes. But I thought the > hierarchy had to be maintained because it has useful information, as > certain fields like Identifier and citation appear at many different > places, so I stuck to tree view. > My idea of simplified view is to get ride of the hierarchy. Indeed it is not possible to represent the full ISO 19115 metadata without hierarchy. As you point out, structures like Identifier and Citation appear in many different places. But the proposal is to pick only one Citation and only one Identifier, the ones which are generally of most interest to users. For example an ISO 19115 metadata can contain Citation for: * data * metadata (may or may not be same as data citation) * file format * algorithm of data processing * process for quality assessment * etc. But most of the time the user only wants to see the citation for the data, so we could show only that citation in the simplified view. If (s)he want to see other citations, then (s)he can switch to the tree-table view where all information are available. One of the first things that users will want to see is the title of the data and the geographic extent. In the tree-table view, users have to navigate into "Identification info" node, then "Citation", then "title" (and yet deeper if (s)he wants the author name). For the the geographic extent, users have to navigate to "Identification info", "Extents", "Geographic elements". This may not be obvious to users not familiar with ISO 19115. The proposal is to have a summary panel without hierarchy, showing only a pre-selected metadata (not all). > According to the the sample image that you sent me I have come up with > a similar summary view in tree table view instead using operations > like removing unwanted subtree, flattening subtrees and rearranging > nodes at > https://github.com/SiddheshRane/sis-client/blob/master/screenshots/Summary.png > This view was generated by user interface elements like shift+up/down > for rearranging nodes, and right clicking to flatten subtree or remove > nodes from the view. Do you want the simplified view to show only > titles, names, descriptions, keywords, strings? Like You said Citation > could be hidden but show only it's children, what other components are > less important. > I would suggest that the left column disappear for the simplified view; no tree at all. So the user would see "Title" directly, without "Identification info" node on top of it (but a button somewhere would hello him to switch to the tree-table view if (s)he wants). I would omit the online resources and contact information for now (we can revisit them later). For a first draft, I would suggest to use only the following: * Title on one line * Abstract on many lines * Geographic extent * Spatial reference system (only the name, not the full description) * Spatial representation type * Axis dimensions in a table Nothing more for now (we can revisit later for more info). Above can be read-only (I think it is okay to ask users to switch to tree-table view if they want to edit). > Oh I didn't know about the linear relationship. I will switch to > Plate-Carré projection image. > Alternatively, we could also omit the range sliders. They are not linearly related to the selection unless we restrict to Plate-Carrée, which is not the preferred projection. Even in Plate-carrée those sliders are not aligned with the selection unless the user zoom at a very specific level. All this come at the cost of an extra dependency. Wouldn't it be preferable to remove them for now? If we want range sliders for geographic extent, we will need to develop our own, but this would be more work than what we can do in the GSoC. > Can you tell me the requirements of the CRS editor, like how do you > wish to interact with it and what are the operations you need to > perform. Whether you only need to edit certain values, or add new > components like axes, parameters or change the types entirely like > switching from geodeticCRS to projectedCRS. I need your requirements > clearly, even if certain questions might sound senseless, because I'm > not an expert at these. > I suggest to begin with a dialog box like below (for easier start, I'm omitting some important elements like base CRS, ellipsoid name, etc.): * The CRS name as a text field * The datum name as a text field o Prime meridian as a combo box (not editable for now) o Semi-major axis length o Semi-minor axis length (later, we should add a button for switching to inverse flattening factor) * Coordinate system type (for now only Ellipsoidal or Cartesian) * A table on two or three rows containing the following columns: o Axis name as a text field o Axis units of measurement o Axis direction (north, south, east, west) as a combo-box > If you can give me a detailed scenario of how you'll use the > functionality you are expecting in terms of user interface components > then I can judge how much work it will require. But I think that the > tree table view can fit our needs with the preferences functionality > offering not only summaries but different views. My proposal is: * In the tree-table, limit the specialized widgets to those that fit on a single line. * Create a separated panel with no hierarchy and only the above-cited metadata elements. More complex widgets appear there. Of course it can be questioned, and it is okay to try alternatives. Martin
