Approach:

• first try on BM RForms (Fully Hierarchical mockup, and/or AP reduction, and/or new styling)
• then if it works ok, redo the RKD forms

Current Display (Compact)

RS currently uses RForms to display object data.

• This was created by Jana in Jan-12, then refined in May-12 (without a mockup).
• BM RForms Mockup is a simple mockup of RForms for BM data. It's a data mapping (data access through property chains, data order and grouping), not a graphic design

Part of the data (login, select Tools> Data Annotation> BadendeSusanna):
Note: the ugly up-down arrows at AP were a cosmetic bug related to AP box sizing on Chrome, fixed now

Examples of deep nesting (2 collapsible levels, plus 1-2 visual levels above them):

• Has other part: Frame: Production
• Is documented in: 34. Document: Has representation
  • Document 34 (a 35mm slide) has scalar fields (e.g. document type, created when, current keeper)
  • It also has 8 digital renditions (JPG) that are themselves collapsible subsections.
    They can show embedded images (but in this case they have red text "Missing file: *.jpg" becase a lot of the images were not provided by RKD).

RForms Extensions, Compactness

Although the data is hierarchical (actually it is a graph) it is not always a good idea to list it as it is.
We avoided hierarchical presentation in some cases. We often use compact forms, eg

• Single line. We added this functionality to RForms specifically for RS
  • Dimension: instead of

    Dimension
      Type
        height
      Number
        3
      Unit
        cm
    

    we use

    Height 3 cm

  • Thesaurus terms: we show the value, and then add its additional properties in the same line. Instead of

       Museum Louvre
         Name
           Louvre
         Type
           Institution
           Museum
    

    We have

    Louvre, Institution, Museum
    

    or

    Louvre (Institution, Museum)
    

  • Acquisition (example I did for BM RForms): instead of

      Acquisition
        transferred title from
          Type
             bequeathed by
          <person>
    

    we'd use

      Acquisition
        transferred title from (bequeathed by)   <person>
    

• Tabular Display
  Tables are useful UI elements that help present data in more compact and understandable way.
  Eg for all dimensions (columns are type, value and unit):

  Dimension
  height	3	cm
  width	2	cm
  depth	1	cm

  Tables are also useful when we have type + short data, eg for Title (columns are type and value):

  Title
  primary	Badende Suzana	nl
  	Bathing Susanna	en
  old/wrong	Batsheba at her Bath	en

• Some data looks better in lists. Lists are custom elements that we created in RForms especially for RS:

  Material: gold, silver, wood.

• RForms does not support Images out of the box. We added images.

Crowding Problems

There are several problems related to compactness (displaying several fields on the same line):

• several AP buttons (indicators) don't look good (and may confuse the user), so Dominic wanted to reduce the number.
  On the BM RForms mockup I'll be putting to suggest where to put APs (a reduced set)
• for Databasket we need to add Action menu "Add to basket" next to the AP, which will make it uglier (issue raised by Kostadinov)
• Joiner: if the user selects the left field, the joiner crosses the other fields

Consideratins/Solutions:

• Settle that if there are several fields in a line, there should be only one AP, Action and joiner (for the node as a whole). Eg for Dimension:

  Height 30 cm        [AP][Act] ---(joiner)---

  • This means the user can comment only on the Dimension as a whole, and cannot propose a new structured value.
  • It's not very likely the user would want to change Height or "cm".
  • But it's a loss if he cannot propose a new structured value for the number.
• Alternatively, we can switch to Fully Hierarchical Display but it has its own problems

Potentially Involving RForms Authors

Dominic: it is a possibility to purchase some commercial support from the RForms people: http://code.google.com/p/rforms/wiki/Contact. We would get a day from them to sort out the issues we have styling the rforms output and some general advise for going forward and saving Ontotext programmers time.

Vlado: let's first have a mockup that is commensurate with the data, and decide what we want.
Then we'll figure out if we need the help. As you see above, we've extended RForms with custom components, so I guess we can style them. It's all a question of effort and priorities.
If you decide to engage them, we'll cooperate fully, eg give them our source for review.

Mockup V1

https://svn.ontotext.com/svn/researchspace/trunk/researchspacetemplates-head/export/annotative-area.html
Vlado: it has various problems, see red pencil:

Jana: If you look at Hollie's notes from Sofia, you will see BVA were not happy to try and style the RForms markup. They started HTML from scratch as they considered it too complex to work over the RForms HTML (produced by dojo).

• The RForms layout is largely produced programatically and I wouldn't say changing it is really part of GUI design tasks.
• (The situation is very similar with Exhibit).
  Please keep in mind that current BVA design has also number of open issues that we have never picked up as we all acknowledged it as more of a guidance. For example:
• data fields there are inputs which does not reflect the functionality we have.
• Lack of hierarchy (indent) - as our data is actually hierarchical

Mockup V2 (Fully Hierarchical)

Hollie: amended the design based on the example you provided.
Data is set out hierarchically, shown are 7 levels (more levels can be achieved if needed), with data example towards the middle:

http://mocku.ps/iixhly : new mockup with notes

Vlado notes:

• What's the best browser to use for mocku.ps? The numbers obscure the elements underneath (but the data example is understandable)
• I like the look, BUT
• As depicted, every relation and value is on a separate line. That will make for veeery long and hard to comprehend displays, see examples in RForms Extensions, Compactness above
• with the nesting, I wonder how quickly we'll eat up the horizontal space. E.g. if there's a long text at level 5, what happens?
• With so many collapse/expand arrows, we should get some advice from Outliner software (there are many such)
  Shouldn't we have some global collapse/expand commands?
  My favorite outliner/organization software has visibility commands that operate on one tree, or all data.http://orgmode.org/guide/Visibility-cycling.html#Visibility-cycling
• We need to rethink Quick Nav.
  • Currently the one made for RKD is nearly useless for many BM objects. Many of the drop-downs just say "There's no such data"
  • In order to use it, you need to first jump up, which makes it harder to use
  • If you look at the top right corner of the above page, you'll see a TOC popup that I find very useful

Jana notes:

• In general, I would suggest that a full mockup is created with real data for one object so that all cases that need special handling are seen.
  Vlado: I've said the same 11m ago, see RS-38
  • Having each value on a separate line is not always appropriate.
  • Some data looks better in lists
  • Tables are useful UI element that help present data in more compact and understandable way
  • We have avoided hierarchical presentation in some cases.
• Although data is hierarchical (actually it is a graph) it is not always a good idea to list it as it is. Sometimes certain levels need to be skipped or artificial levels are added so that UI presentation is more comprehensible. This makes counting levels somewhat a challenge.
• The new annotation dialog - is it removed now? It is replaced with fixed area on the screen now on the mockup? How does this area hide and show.
• Dominic raised again the question how user sees the relevant annotations if they clicked on data that is somewhere very low on screen (and having each value on a new row, this is the most of the data). How is this concern reflected in the mockup?

Fully Hierarchical Display Using XSL

If we decide on a Fully Hierarchical, regular display (without optimizations), I think we could produce it with XSL instead of RForms.
This is quite a heretical thought, since we've spent effort mastering RForms and developed extensions.
But it would have some benefits, eg most of the processing can be server-side, and the JS can be much lighter.

http://www.cidoc-crm.org/crm_mappings.html bottom of page describes such approach

• Examples are based on a representation of CIDOC CRM instances encoded by a simple DTD (CIDOC5.0.2-FRBR1.0.1-CRMdig2.4.dtd).
• All properties are allowed for all entities recursively, such that a CRM instance can be transported as an unlimitidly nested file.
• It does not enforce correct use of the CICOD CRM classes and properties. Consistent use of properties for the respective classes is up to the user or the program generating the XML DTD instance.
• This DTD only implements the CIDOC CRM properties, whereas classes are represented as data.
• A simple XSL (cidoc_crm.xsl) converts this to HTML for viewing
• We'd need to implement conversion RDF->XML: similar to the GetCompleteMO algorithm, but with specific property ordering
• (Note: there is a utility that converts in the other direction: XML instances -> RDF)

Here's an example from Epitaphios HTML, I leave it to you to decide whether you like it:

Mockup V3 (Compacted)

A new mockup is at http://mocku.ps/txnvqi

• It shows tabular set up and also lists as requested by Jana and Vladimir.
• I use Chrome to view it, you can switch annotations on and off using a button at the top right corner