cosmetics on https://ref.gs1.org/epcis/

[VladimirAlexiev]

@mgh128 It's great that EPCIS terms like https://ref.gs1.org/epcis/AssociationEvent have individual pages and resolve!! Since https://github.com/gs1/EPCIS/ is not restored yet, I'll post here some cosmetic fixes that I think are needed:

1. I don't see much difference between the 3 "View modes" except a tab is renamed. Currently the "RDF" view is perfect but the other two need adjustment. Eg in JSON
   • I think there should be an id field (which is the URL in "RDF"),
   • fields should have no prefixes,
   • "Expected value type" should be string, uri, etc but not a class
2. Cosmetics on the table:
3. Change "Code URI" to "Property" or "Field"
4. It's great that both props and "expected value" classes are clickable. But maybe show them in blue to
5. Reduce the font. Here's the default font of EPCIS site (left) vs github (right):
6. IMHO: increase table width. There's a lot of unused horizontal space
7. IMHO: use vertical cell alignment=Top. You use Center, but it's hard to see where the Description of a field starts.

[TallTed]

re point 2, "Cosmetics on the table" — Space chars should not be inserted in string values of column 2 (as seen here); rather, the CSS should be set to permit auto-wrap within words. (I can dig further on the specifics of how to do this, if needed; I don't know it off the top of my head, but I know that webmasters I've worked with have built it into tables on our pages.)

re point 6, "IMHO: increase table width. There's a lot of unused horizontal space" — This is certainly true on most laptops and even desktop machines, but highly unlikely to be true on phones and even tablets, especially if being used in portrait rather than landscape orientation. Final decisions about this aspect of table design tend to come down to weighted priorities (e.g., if most users are on phones, optimal layout will be different than if most users are on large-screen laptops).

re point 7, "IMHO: use vertical cell alignment=Top. You use Center, but it's hard to see where the Description of a field starts." — Generally speaking, top alignment is best for cell values in tables like this. As with point 6, this will be influenced by where/how the table will most often be viewed/used. It will likely also be worth investigating a "floating" table header, such that the column titles are always visible, no matter how low you scroll in the table.

I would also suggest styling the first two (as shown here) columns (and any other CURIEs or URIs) as monospace font. You could try to force a specific preferred font, but this is typically less successful than just generic monospace (which should be the final fallback when specifying specific font(s) anyway).

[VladimirAlexiev]

I checked how it looks on mobile phone:

• in Portrait, prop tables fill the screen horizontally. Class descriptions have a lot of unused space on the right
• in Landscape, prop tables leave some unused space on the right, and the Description column uses too big font

In all cases, the first two cols (prop name and expected value) have too much empty space because no breaks are enabled there.

• can somehow break be enabled after : ?
• you could remove the epcis: prefix from the pro column (but it's needed in "expected value" because different prefixes are used tehre)

[nissimsan]

Should this not rather be debated on the EPCIS repo?

[OR13]

What part of this is related to changes requested in this repository? ... Seems hard to action in current form.

[mgh128]

Hi all,

@nissimsan is correct. This discussion really belongs in the GS1 EPCIS repository, for which a public version now exists, though it temporarily wasn't public when @VladimirAlexiev began writing this issue. We had an "administrative glitch" ;-) during the summer, now mostly resolved.

The feedback is helpful and appreciated and I'll add it to my to-do list for early 2023 but I have some higher priority items that need my focus before then.

I developed the web tool for the EPCIS / CBV ontology browsers at https://ref.gs1.org/epcis and https://ref.gs1.org/cbv - so it's probably my job to make the suggested improvements.

I think @VladimirAlexiev may have initially intended to alert you to the existence of those two tools but I don't think there is an action for this group to do anything other than to consider aligning well with EPCIS and CBV open standards if you feel that they're helpful - and do feel free to contact us if anything is unclear in those standards and their associated artefacts and examples, which can be found at https://ref.gs1.org/standards/

[nissimsan]

Closing.