Hi,
From what I understand there isn’t currently a strong vision on how the Metadata Viewer is going to be implemented for GeoNetwork 3.0.
As I see it there are two obvious options:
- Use the same framework as is used by the editor and have another configuration file which maps each widget to each metadata element (similar to how the editor works but simplified because the editing capabilities are not required. In this case all widgets would be read-only
- Use the Metadata formatters and provide an XSLT to display the metadata. The styling would use bootstrap to give a consistent visual experience.
The advantage of 2 is that javascript would not be required displaying the metadata which makes it easier to support older browsers and tools like screen readers.
A second advantage is that we have support for generating PDFs from formatter pages so we don’t need to do anything special for PDF creation.
What is the communities opinion of these options (and others you can think of)?
Jesse
On Wed, Mar 5, 2014 at 9:04 PM, Jesse Eichar <jesse.eichar@anonymised.com>wrote:
Hi,
From what I understand there isn't currently a strong vision on how the
Metadata Viewer is going to be implemented for GeoNetwork 3.0.
As I see it there are two obvious options:
1. Use the same framework as is used by the editor and have another
configuration file which maps each widget to each metadata element (similar
to how the editor works but simplified because the editing capabilities are
not required. In this case all widgets would be read-only
2. Use the Metadata formatters and provide an XSLT to display the
metadata. The styling would use bootstrap to give a consistent visual
experience.
The advantage of 2 is that javascript would not be required displaying the
metadata which makes it easier to support older browsers and tools like
screen readers.
A second advantage is that we have support for generating PDFs from
formatter pages so we don't need to do anything special for PDF creation.
What is the communities opinion of these options (and others you can think
of)?
Hi,
It is not an easy choice. As a developer I think I prefer option 1 because
it will be probably much easier to maintain.
On the other hand... are there really many users that can't run javascript?
http://a11yproject.com/posts/myth-screen-readers-dont-use-javascript/
http://webaim.org/projects/screenreadersurvey4/#javascript
As Windows is going to shut down Windows XP shortly, should we really worry
about old IE browsers?
I mean: is this really a strong requirement, this not having javascript
enabled?
On Thu, Mar 6, 2014 at 8:11 AM, María Arias de Reyna <delawen@anonymised.com> wrote:
On Wed, Mar 5, 2014 at 9:04 PM, Jesse Eichar <jesse.eichar@anonymised.com> wrote:
Hi,
From what I understand there isn't currently a strong vision on how the Metadata Viewer is going to be implemented for GeoNetwork 3.0.
As I see it there are two obvious options:
Use the same framework as is used by the editor and have another configuration file which maps each widget to each metadata element (similar to how the editor works but simplified because the editing capabilities are not required. In this case all widgets would be read-only
Use the Metadata formatters and provide an XSLT to display the metadata. The styling would use bootstrap to give a consistent visual experience.
The advantage of 2 is that javascript would not be required displaying the metadata which makes it easier to support older browsers and tools like screen readers.
A second advantage is that we have support for generating PDFs from formatter pages so we don't need to do anything special for PDF creation.
What is the communities opinion of these options (and others you can think of)?
Hi,
It is not an easy choice. As a developer I think I prefer option 1 because it will be probably much easier to maintain.
On the other hand... are there really many users that can't run javascript?
http://a11yproject.com/posts/myth-screen-readers-dont-use-javascript/
http://webaim.org/projects/screenreadersurvey4/#javascript
And on this webaim page there is specific info for javascript:
http://webaim.org/techniques/javascript/
However, JavaScript can also introduce accessibility issues. These
issues may include:
* Navigation. Inability or difficulty navigating using a keyboard or
assistive technology.
* Hidden content. Presentation of content or functionality that is
not accessible to assistive technologies.
* User control. Lack of user control over automated content changes.
* Confusion/Disorientation. Altering or disabling the normal
functionality of the user agent (browser) or triggering events that
the user may not be aware of.
Do you think we can modify (if not already being done) our editor so
we can avoid as much as possible this things? There are things that
can be done to avoid this kind of problems. I am not an expert on
accesibility, but on a quick search on the web I can see many
workarounds for screen readers (that have javascript enabled but may
be confused on position of elements, for example).