Metadata Editor UX Improvements

Date	17/12/2014	Contacts	Max Martinez
Status	Documentation	Release	3.0
Resources	{If the resources are available or more are needed to finish work}	Ticket #	#709
Source code	{A link to the source code}
Funding	{Credit to the organization who is funding the development}

Overview

After a couple of days of researching and analysing several editors, forms and our own metadata implementations in several projects I come to a couple of conclusions that would probably affect GeoNetwork v.3 implementation:

• The Simple view needs to be simplified even more.
• The Full view need a clearer hierarchy visuals.
• The XML view needs to be easier to understand.
• General observations.

Proposal

Here are my proposals to be able to accomplish that.

The Simple View

Nesting

Currently it is still some nesting visible from the XML file:

Cleaning

The amount of lines separating the div fields is very distracting and unnecessary. the form.gn-editor fieldset > div.form-group.gn-field doesn’t need a line.:

Reorder fields

The reorder interaction of field sets should be similar to the fields interaction. Don’t float the controls to the right.

Label vs Value

It has been widely extended the use of black-bold-strong labels in forms. This probably comes from spreadsheet where the column titles needed to be clearly differentiated from the values and it didn’t make any sense to put values in bold. In a form like we we are showing the label must be clear but the value is most important. My suggestion is to use a single mid grey color in a normal font for labels and dark normal font for the values.

Change label color from #333333 and #858585 to #999999 Change label weight from Bold to Normal Change value color from #555555 to #333333

It would be ideal to prevent from having two lines of text in the label but considering the nature and flexibility of the tool, we have to optimize for two line visuals. In the above proposal you can see that the labels are top aligned to the input field. The line height has been set to 1em and the .form-horizontal .control-label padding-top was removed.

Required / mandatory fields

In the current implementation is not clear how a mandatory field looks like. I can imagine there are some required fields to be able to publish some meta data. I saw some red border fields in the c2cpc15.camptpcamp as well as in the dyfi.cobwebproject implementation. I don’t know if the intention is to communicate that those are mandatory but that visual communication should be used for validation errors in the form.

This is a good solution when only a few fields are mandatory. In the case of few optional field instead, place an “optional” text below the field instead of using the asterisk.

In this proposal I’m using a Font Awesome asterisk in #a94442 (fa-asterisk) At the beginning of the form it should be informed to the user that the items marked with this asterisk are required or mandatory.

Validation error

Running the validation feature is nice because you have a single place to check for all validation messages but unfortunately is not very useful when the field that had the error is not clearly marked. It would also be nice that, by clicking in the error message, you would be directed and focus to the value in question, especially when the error might be in something called gco:CharacterString which the user might not know where that is nor what it refers to.

To have a clear visual communication of the error fields this proposal includes:

• Containing DIV background color change to #f2dede (from .has-error class)
• Text color change to #a94442 (from .has-error class)
• Field #b94a48 color border included in the .has-error class
• 12px italic red text under the field indicating the error reason.

Validation on the fly would be nice.

Field sets grouping.

Right now the sets of fields are nicely distinguished by a 21px font size legend that has a border at the bottom. Unfortunately this is not good enough specially when deleting a complete set since is not very clear when it ends, so which are the fields to be removed.

Contextual actions.

Currently each deletable field or fieldset shows an “x” at the far right. My proposal is to clean this visualization by showing contextual actions on hover giving a clear indication over which element or groups of elements will the action be performed to.

This approach relies on changing the labels of the affected fields to red which is also the visualization of required values and/or validation error and is not very evident since the change occurs at the left of the screen when I’m looking at the right.

In this proposal hovering the whole fieldset will change the background color and show the deleting contextual icon.

The use of a tooltip is recommended when hovering the action icon.

<button type="button" class="btn btn-default" data-toggle="tooltip" data-placement="top" title="Tooltip on top">Tooltip on top</button>

Also the DIVs for the fields should have this type of interaction.

As an alternative from hovering, it would be nice to have interaction consistency when the field is on-focus. Also for small screen interaction it should be possible to touch the area to have it pre-selected and then perform the contextual action.

Deleting warning

It is a pretty serious action to delete a whole fieldset from a record. Lets warn with a dialog. Are you sure you would like to delete the record and all its contants? Cancel Delete

Full View

My proposal for the full view is basically applying all the Simple View improvements plus:

• Nesting visualization
• Expand / collapse toggle clicking on the icon or maybe the whole label.

fieldset { padding: 5px; border: 1px solid #ebebeb; border-radius: 3px; }

This icons are fa-caret-right and fa-caret-down I was able to mock the hovering areas up with stopPropagation:

` $(function() { $('fieldset').on('mouseover', function(e){ e.stopPropagation(); $(this).addClass('field-bg');

    }).on('mouseout', function(e){
        $(this).removeClass('field-bg');
    })
});`

hovering color: .field-bg { background-color: #f7f7f7; }

Section navigation

I would advocate to use the .nav-tabs class instead of the .nav-pills to make a clearer distinction from the toolbar buttons.

The XML View

Some syntax highlighting would be very nice to be able to better visualize the different parts of the structure. A possible tool for this could be highlight.js

This is the Visual Studio style from highlight.js

Expand / Collapse would be nice but I can imagine the technical difficulties in that approach

General observations

Columns

I see that the use of columns is not optimal for the labels nor for the contextual actions. Another layout should be considered with a fixed size for the labels and contextual action icons and adaptable for the fields.

Spacing

The toolbar needs space on the right. Some extra spacing on the sides of the page would be nice to give some air to the layout. Right now .gn-editor-container has a 10px padding. My proposal is to change that to padding: 0px 20px .navbar-default doesn’t have padding. I would add Padding: 0 20px The secondary .narbar has border-radius: 4px. This looks weird if it goes full width. I would remove it. The secondary .navbar could use a slightly darker color to denote some hierarchy like #F5F5F5 The secondary .navbar contents are a bit awkwardly placed in a container. This prevents this elements to float to the right.

Button colors

The use of the button styles are a bit random. The styling should have a meaning.

I don’t think we should abuse the use of them. For example there should be only one Primary. We should also question the order of the buttons. Save should be next to Save and close. Save & close could have a fa-save icon. The fa-sign-out icon is used below to Sign Out

Since I have just entered in the editing mode, the only way to go back to the catalog is to “Save & close”. What if I changed my mind and I would like to “Cancel” the edition? Maybe the “Cancel” button should be renamed to “Revert changes” I’m not positive on the need of a “Cancel” cancel button but there should probably be a way to exit the editing mode like a “Back” button at the left of the secondary toolbar.

Hitting the Back button having made changes, should prompt a dialog asking if to save changes or to leave reverting them.

Icon + text spacing

Many icons on the right pane are too close to the text and in a couple of places they have double spacing. Check for consistency with a single space. Add also a space between the + and the dropdown arrow from the adding associated resource action button as well as replacing the btn-link class with btn-default. Float action buttons to the right of the bar. Add a question mark to the unperformed Validation panel. Distance between the Resources panel and the Validation panel should be 20px. There is a <br/> after the resources panel.

Show non errors

The “Show only errors” button interaction is not clear since at first glance it seems just a darker button and not pressed. Besides, the result from clicking it can be far below visible area. Change this button with expand/collapse interaction with a toggle icon and by clicking the whole title. Errors will show expanded by default after the validation. Non-errors will show collapsed by default after validation.

Add button

Add container to the Add button with btn-default class. No need for duplicating the label.

Map visualization

I think the geographic bounding box needs some attention but I’ll create that as a separate document.

Navigation feature

I find this a very nice feature. specially for long content. My only comment would be to remove the underscore from the icons and to toggle the collapse icon with an expand when is collapsed. Instead of using the sorting ascending icon (fa-sort-amount-asc) use fa-caret-square-o-down when is extended and fa-caret-square-o-up when is collapsed.

Technical Details:

Proposal Type:

• Type:
• Module:

Voting History

• Vote Proposed: TBA

Participants

• All